Home » Security Bloggers Network » SBOM Executive Order: Ready for the June 11th deadline?

SBOM Executive Order: Ready for the June 11th deadline?

by Deepfactor on June 8, 2023

In preparation for the June 11th deadline of President Biden’s Executive Order (EO) on Improving the Nation’s Cybersecurity, Deepfactor has focused on educating customers about the importance of accurately and systematically documenting software production, consumption, and operation using Software Bill of Materials (SBOMs). They represent a critical first step in discovering vulnerabilities and weaknesses within your products and the devices you procure from your software supply chain.

Though your software may not be “in-scope” for the rapidly-approaching deadline, organizations merely at or below current regulatory requirements are at a competitive disadvantage, particularly as companies plan for the strategic use of SBOMs, leveraging them for readiness and as a value-added benefit in the software procurement process. Regardless, for many, the race against time has begun to adhere to these mandates.

For those interested in learning more—or just looking for a good recap—continue reading to better understand these requirements, and to learn what Deepfactor has done to help customers prepare!

What SBOM Executive Order mandate?

In September 2022, The White House Office of Management and Budget (OMB) issued a memorandum requiring every Federal agency to comply with NIST Guidance, “when using third-party software on the agency’s information systems or otherwise affecting the agency’s information.” In other words, if your software is sold to, or used by, the US Federal government then you will be expected, for each major version of each software product you supply, to provide the following:

A self-attestation that the product was built in conformance with NIST’s Secure Software Development Framework (SSDF).
On request, a Software Bill of Materials (SBOM) for the product. The NTIA report “Minimum Elements of an SBOM” is a useful starting point for understanding what’s required.
On request, other artifacts substantiating SSDF conformance, e.g., output of vulnerability scanners, software provenance metadata, etc.
On request, evidence of participation in a Vulnerability Disclosure Program.

Why SBOMs?

By improving the visibility, transparency, security, and integrity of proprietary and open-source code in software supply chains, this mandate is part of a broader initiative to bolster cybersecurity practices nationwide, emphasizing the importance of understanding and managing software components, recognizing the potential for code compromise, and proactively mitigating risks. For anyone not living inside a log(4j), these requirements shouldn’t be a surprise—they are a direct response to an escalating number of attacks on the software ecosystem.

Sponsorships Available

Example supply chain attacks:

SolarWinds	Due to a breach in December 2020, roughly 18,000 customers of SolarWinds downloaded trojanized versions of its Orion IT monitoring and management software. The supply chain attack led to the breach of government and high-profile companies after attackers deployed a backdoor dubbed SUNBURST or Solorigate.
Octopus Scanner Malware	Octopus Scanner is a type of malware that finds and backdoors open-source NetBeans projects hosted on the GitHub web-based code hosting platform to spread to Windows, Linux, and macOS systems and deploy a Remote Administration Tool (RAT). The malware compromises developers’ computers by infecting NetBeans repositories with malicious payloads within various dependencies, later spreading to downstream development systems.
Codecov	Codecov provides tools that help developers measure how much of the source code executes during testing, which can help identify undetected bugs. In April 2021, a threat actor had modified the Codecov Bash Uploader script, exposing sensitive information in customers’ continuous integration (CI) environments. This includes Rapid7, who revealed that some of their source code repositories and credentials were accessed by Codecov attackers.

By having a comprehensive understanding of the software components that make up an application, organizations can identify, address and/or mitigate potential security risks more effectively. This can include identifying and patching vulnerabilities, replacing insecure components with more secure alternatives, or removing unnecessary components that increase the attack surface of an application unnecessarily.

In other words, if you don’t know what software was used to build your software, can you really hope to address critical software vulnerabilities that are finding their way into major projects?

What are SBOMs?

Included in this initiative, the Commerce Department and NTIA were directed to publish the minimum elements necessary to prevent, detect, assess, and remediate cyber incidents with SBOMs. They published a report to identify and define “the essential pieces that support basic SBOM functionality and will serve as the foundation for an evolving approach to software transparency.”

Though the report highlighted (3) minimum elements, automation support remains a leading consideration for organizations evaluating SBOMs products. As we covered in a previous webinar, integrating SBOMs into your SDLC can be challenging, particularly because pipelines require predictable machine and human-readable data formats. Thankfully, multiple interoperable data formats exist in the ecosystem and are being used to generate and consume SBOMs—each one offers a unique set of strengths, weaknesses and target use cases:

CycloneDX	CycloneDX is a lightweight SBOM standard designed for use in application security contexts and supply chain component analysis. CycloneDX started in the Open Web Application Security Project (OWASP) community, which manages the strategic direction and maintenance of the specification. The CycloneDX GitHub repository includes tools to create and consume SBOMs in various programming languages.
Software Package Data Exchange (SPDX)	The SPDX specification was developed by the open source software development community and is supported by a rich ecosystem of open-source tools and commercial providers. SPDX became the internationally recognized standard (ISO/IEC 5962:2021) for SBOMs in September 2021.
Software Identification (SWID)	SWID tags were designed to provide a transparent way for organizations to track their software inventory on managed devices. SWID tags contain descriptive information about a specific software release such as the product and version. NIST recommends adoption of the SWID Tag standard by software producers, and multiple standards bodies (e.g. IETF), and is working to incorporate SWID tag data into the National Vulnerability Database (NVD).

Why does Deepfactor care?

Regardless of the aforementioned standards and guidelines—implementing an organization-wide program to generate, review, and operationalize SBOMs remains challenging. This is particularly true when you consider “7 in 10 DevOps teams (70%) release code continuously” (defined as once a day, or every few days) and, on average, 57% of enterprises are using 11 or more containers per application. Given this pace of releases, SBOMs can have several shortcomings which may limit usefulness for an organization:

Limited Visibility	SBOMs do not provide a comprehensive view of every component in a software system—such as open ports, running processes, network connections, and privilege escalations.
Inaccurate	SBOMs are highly-dependent on the source and the process (i.e. when, where, and how) by which the report is generated. This can lead to missing data and quality issues.
Noisy	SBOMs (and SCAs) generate large amounts of data—including a number of false positives—which can overwhelm the developers and security teams responsible for triaging.
Inconsistent and Incompatible	SBOMs can produce inconsistent and incompatible reports, particularly when the previously mentioned standards and data formats aren’t strictly observed.
Difficult to Integrate	SBOMs are challenging to integrate, particularly in modern pipelines where development and operations are completely automated and happening at-scale.

What’s next?

To manage these challenges, Deepfactor wants leaders across engineering, security, and operations to have the information necessary to evaluate SBOM platforms for the right combination of features, code coverage, and even instrumentation to ensure developers have the contextual security information necessary to prioritize the resolution of critical security risks. In order to learn more about SBOMs, consider reviewing some the valuable content we’ve authored on the subject, including in-depth conversations with customers and industry-leaders tackling the same problem: