It’s SBOM time!

A new memo (PDF) from the Office of Management and Budget (OMB) — M-22-18, published last month — is clear in setting expectations for federal agencies when it comes to using software that’s potentially hiding buggy libraries or other threats:

“Federal agencies must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance.” —OMB M-22-18 

Wondering what it means? What the implications are? What to do now? Whether Contrast can help get your organization compliant? 

Read on for answers, including a big “Yes”: Contrast can help. 

Lots of timelines

The memo is eight pages, four of which are timelines for what you have to do and when. Beyond those timelines, there are two big deals worth calling out: namely, two assets that federal agencies will need to work with a software producer to get. Namely:

1. Self-attestation from all software producers about their software security profiles and practices. Producers are being encouraged to use NIST’s “self-attestation letter.” NIST is planning to provide a format description for the letter in 2023. 

Even though NIST will provide these self-attestation forms, now is the time for software organizations selling to the government to start preparing their internal teams to respond to these requests. 

Note too that the memo has a caveat: If a third-party software producer has a third-party assessment that’s certified by a FedRAMP Third-Party Assessor Organization (3PAO), or one approved by the agency, it can serve in lieu of a software producer's self-attestation, “including in the case of open-source software or products incorporating open-source software, provided the 3PAO uses the NIST Guidance as the assessment baseline.”

 What’s still not clear: whether that will include things such as System and Organization Control (SOC) Type II or perhaps ISO certifications. 

The self-attestation part of this shouldn’t be a big deal, given that government entities are already collecting similar materials. For example, Contrast fills out the Consensus Assessments Initiative Questionnaire (CAIQ): a type of Standardized Information Gathering (SIG) questionnaire for cloud service providers requested by many customers in the financial sector. 

In short, the self-attestation part of this memo isn’t really moving the needle. 

The bombshell

The same can’t be said for the second type of asset that OMB 22-18 requires: namely, the Software Bill of Materials (SBOM). 

1. An SBOM will be required from each software producer. An SBOM is a complete list of all open-source and third-party components present in a codebase. It should also list the licenses that govern those components, component versions used in the codebase and their patch status, so that security teams can quickly zero in on any associated security or license risks.

Bear in mind that as of yet, there’s no default format yet for SBOMs. Rather, there are several format versions. 

It’s impossible to say how far down the rabbit hole organizations will go with SBOMs, and that has to do with the fact that there’s no clear definition of what comprises “critical” software. Is  Microsoft Office “critical?” Or Lacework: automated security and compliance software for multi-cloud environments, workloads, containers and Kubernetes systems for handling containerized applications? If a software provider has built something like Lacework or SumoLogic into their software system, will an SBOM include those vendors, as well?

How can Contrast help?

Contrast, for its part, already allows users to generate a downloadable SBOM through a simple application programming interface (API) or via a command in the Contrast command line interface (CLI). As far as formats go, the Contrast SBOM meets the specifications of the OWASP's CycloneDX SBOM standard and the international open Software Package Data Exchange (SPDX) standard. Our SBOM contains information about the software that your application uses, including:

• Libraries — Open source and third-party components present in a codebase,
• Licenses that govern the software components, and
• Versions of software components used in the codebase.

Contrast generates and provides SBOMs in real-time. 

With regards to following secure development practices and tasks, Contrast helps with the following, which correspond to E 14028 Subsections: 

4e(i)(F) - operational monitoring and incident detection and response

4e(ii) - Artifacts from 4e(i)

4e(iv) - Check software for vulnerabilities and remediate them

4e(v) - Artifacts from 4e(iv)

4e(vii) - SBOM for each product

4e(viii) - participate in vulnerability discovery program

4e(ix) - Attest to conformity with secure software development practices (testing) — SEE NIST 800-218 SSDF

4e(x) - Attest to integrity and provenance of open-source components — check hash on all libraries (unknowns)

But as far as attestation goes, providers should just hang tight for now, given that the self-attestation form is still coming. 

Let the sun shine in

We suggest that providers get ready to start publicizing their SBOMs — something that’s in the works and due in coming months at Contrast Security. As well, providers should publicly post their vulnerability disclosure process. You can find Contrast Security’s vulnerability disclosure process here. 

In sum, Contrast applauds OMB 22-18. As a provider of cutting-edge security software and research, we take security issues very seriously and recognize the importance of privacy, security and community involvement. As such, we are committed to addressing and reporting security issues through a coordinated and constructive approach designed to drive the greatest protection for technology users. 

OMB 22-18 is part of that constructive approach: It is, in fact, a call for transparency. Contrast has that kind of transparency baked into its very DNA. 

Click here to sign up for a demo or to contact Contrast to get started creating your own SBOMs today.