Cybersecurity Executive Order 14028: Updates for SBOMs & FedRAMP

On May 12, 2021, President Biden signed the highly anticipated Executive Order on Improving the Nation’s Cybersecurity (EO 14028). This executive order (EO) includes a major element outlining new guidelines for how US federal government programs will interact with industry software suppliers and partners moving forward.

SBOMs & The Executive Order

There are many notable improvements throughout the EO, but one area our team at Anchore found particularly interesting was around emerging requirements for sharing software bill of materials (SBOM) information when software is being delivered across organizational boundaries.

Following the Executive Order’s initial publication in May 2021, the NTIA and Department of Commerce released a secondary document with more information on SBOM requirements: The Minimum Elements for a Software Bill of Materials. This document goes into more detail on three categories of minimum required elements: data fields, automation support, and practices and processes.

Why it Matters

The cybersecurity experts her at Anchore believe that this is an important step toward defending against security incidents that use a software supply chain attack method – where an attacker infiltrates a software supplier ‘somewhere in the chain’ to either introduce or uncover an exploitable flaw, and then implements the attack against the end consumer of the software, who has deployed the compromised supplier software element in production.

Presently, one area of weakness that can lead to a successful supply chain attack stems from the reality that there is often very little transparency between suppliers and consumers on exactly what software is included within a deliverable, and what software development/security practices are being performed by the supplier in the process of generating the deliverable. If this weakness were to be addressed between all participants of a given supply chain, it becomes possible for each organization to perform more comprehensive security checking and evaluation at each organizational boundary, increasing the overall security coverage of the supply chain.

The foundational element that can be used for this purpose of sharing adequate information when delivering software between organization boundaries is the software bill of materials (SBOM).

Understanding the SBOM

An SBOM, referenced as such directly within the EO, is a document attached to a software deliverable that includes rich information about the software itself, and also importantly contains information about the software’s bundled dependencies. One thing the EO didn’t cover explicitly pertains to containers specifically, where an SBOM generated from a container image deliverable also contains additional information about the system packages inside the container itself, included in support of the application but not necessarily explicitly defined as a dependency of the application code, itself.

Besides just software names and versions, each software element has important metadata that may become an SBOM requirement:

• The software origin/maintainers
• Commercial and/or open source licenses
• Digital signatures/hashes of executable software and/or data/configuration files

Security vulnerability scanning tools and security engineering teams use SBOM data to:

• Perform vulnerability scans, matching SBOM elements against known/emerging software vulnerabilities
• Perform quality assurance checks using SBOM element versions to determine version status and other health characteristics
• Perform license compliance and conformance checks for OSS and commercial licenses (and combinations) for included SBOM elements 

Next Steps for Integrating SBOMs into DevSecOps Pipelines

Following the release of the EO, the federal government published minimum elements for an SBOM. Our recommendation is to take this time to consider where in your DevOps or DevSecOps pipelines you’ll be consuming SBOMs and using them for vulnerability, license, and compliance checks. In addition, this is the time to be considering the tools and processes that you need to put in place to produce SBOMs and how you’ll provide SBOMs to your compliance auditors and other consumers.

Also important for any organization taking part in a supply chain are that some larger organizations today require suppliers to provide elements when defining contracts around software purchasing. For example, OSS licenses and the requirement for communicating security practices guidelines from supplier to consumers. We at Anchore believe it’s becoming more commonplace practice to transmit detailed information between all organizations within a given supply chain from small/medium/large OSS project maintainers and distribution vendors, to companies providing proprietary software.

Bolstering software supply chain information quality requires all actors to participate, by taking these first necessary steps to integrate SBOM generation into existing development and publication practices. 

FedRAMP Updates from the Executive Order 14028

Security Principles for Cloud Service Providers

Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) are increasingly providing secure platforms for the next generation of federal government applications. Case in point, federal government agencies spent $6.6 billion on cloud computing in fiscal 2020. That figure was up from $6.1 billion in fiscal 2019, according to a government spending analysis by Bloomberg Government, as reported by NextGov. Section 3 Modernizing Federal Government Cybersecurity, states:

“The Secretary of Homeland Security acting through the Director of CISA, in consultation with the Administrator of General Services acting through the Federal Risk and Authorization Management Program (FedRAMP) within the General Services Administration, shall develop security principles governing Cloud Service Providers (CSPs) for incorporation into agency modernization efforts.”

Federal Cloud Security Strategy in 90 Days

The EO also positions FedRAMP — as part of the General Services Administration — as part of a task force to create a federal cloud security strategy in 90 days and then provide guidance to federal agencies. Here’s the quote from the EO:

“Within 90 days of the date of this order, the Director of OMB, in consultation with the Secretary of Homeland Security acting through the Director of CISA, and the Administrator of General Services acting through FedRAMP, shall develop a Federal cloud-security strategy and provide guidance to agencies accordingly. Such guidance shall seek to ensure that risks to the FCEB from using cloud-based services are broadly understood and effectively addressed, and that FCEB Agencies move closer to Zero Trust Architecture”

90 Days to a Cloud Technical Reference Architecture

With large government cloud initiatives such as the United States Air Force’s Platform One gaining mindshare, other parts of the Department of Defense (DoD) and civilian agencies are certain to follow suit with large scale secure cloud initiatives. The EO also mandates the creation of a cloud security technical reference architecture:

“Within 90 days of the date of this order, the Secretary of Homeland Security acting through the Director of CISA, in consultation with the Director of OMB and the Administrator of General Services acting through FedRAMP, shall develop and issue, for the FCEB, cloud-security technical reference architecture documentation that illustrates recommended approaches to cloud migration and data protection for agency data collection and reporting.”

Other Key Takeaways

• The EO mandates establishing a training program to provide agencies with training and the tools to manage FedRAMP requests. There’s no mention of training for the SI and government contractor community
• The EO mandates establishing a training program to provide agencies training and the tools to manage FedRAMP requests. There’s no mention for training for the SI and government contractor community

Learn how Anchore helps automate FedRAMP vulnerability scans.