[UPDATE 12/4/2022 The US State Department issued an RFP on December 2, 2022 with the following SBOM requirement:
Commitment to Cybersecurity Compliance Statement
The Offeror, in submitting its proposal for the Evolve solicitation, agrees to provide a self-attestation in the format provided by the Department of State (once it is available) within the timeframe required by the Government after receipt of the form.
The Offeror also agrees to submit to third-party testing and/or provide a Software Bill of Materials (SBOM) upon request that conforms to the requirements of OMB Memo M-22-18 and Executive Order (E.O.) 14028.
As part of its proposal submission, the Offeror attests that it understands it may not be eligible to compete for certain task orders under Evolve until required SBOM information has been provided to, evaluated by, and accepted by the Government.
The November 21, 2022 letter from ITI to OMB Director Shalanda Young contains some useful insights and recommendations, but it also contains some misinformation that needs to be addressed. Here, I list the items I agree with and follow-up by highlighting some of the misinformation to watch for:
I agree with the following statements made by ITI:
Currently, there is no standard FAR clause or contract requirement that directs industry to comply
with OMB M-22-18. The memo directs individual agencies to request information from suppliers,
but we are concerned that these requests will be applied differently across the government, and
even within agencies.
the federal government should adopt a harmonized approach across all agencies,
provide clear pathways for the reuse of existing artifacts, processes, and certifications, and also
define appropriate timelines for stakeholder implementation of attestation requirements.
Clarify the mandate to leverage one standardized form for all agencies
Leverage the overlap with existing processes to the greatest extent possible to avoid the introduction of additional complexity.
The reuse of artifacts should be encouraged to the greatest extent possible. The [NIST] SSDF already maps controls to some existing standards like NIST SP 800-53 and SP 800-161. This mapping should serve as a basis for the reuse of supporting artifacts across cybersecurity schemes.
To facilitate the reuse of attestations and artifacts within and across agencies, it would be helpful for OMB to issue additional guidance on the federal information sharing efforts
We believe the SSDF and the NIST Software Supply Chain Security Guidance offer sound best practices for securing the software development lifecycle regardless of the systemic context in which any specific software was developed.
The following ITI statements are unsubstantiated and/or misleading:
This is further evident in a series of practical challenges related to implementation, including naming, identification, scalability, delivery and access, the linking to vulnerability information, as well as the applicability to cloud services, platforms and legacy software. These challenges make it difficult to effectively deploy and utilize SBOMs as a tool to foster transparency.
[SBOMs are being used in software supply chain risk assessments today in production environments with no issues regarding naming, identification, scalability, delivery and access and the linking to vulnerability information, i.e. NIST Vulnerability Disclosure Reports (VDR) across multiple on-premise and cloud platforms]
For example, static analysis results may contain information about as-yet unfixed. and therefore exploitable, security bugs.
[NIST addressed this concern by describing a Vulnerability Disclosure Report (VDR) within SP 800-161 RA-5, which you can lean about here
Discourage agencies from requiring artifacts until SBOMs are scalable and consumable. We recognize and appreciate the value of flexibility built into the OMB process. Given the current level of (im-)maturity, we believe that SBOMs are not suitable contract requirements yet. The SBOM conversation needs more time to move towards a place where standardized SBOMs are scalable for all software categories and can be consumed by agencies. At this time, it is premature and of limited utility for software producers to provide an SBOM. We ask that OMB discourage agencies from requiring artifacts until there is a greater understanding of how they ought to be provided and until agencies are ready to consume the artifacts that they request.
[Minimal NTIA SBOM artifacts are simple to create for those software vendors following best practices in the SDLC and build environments. There are ample tools available to federal agencies to acquire and process SBOM's that follow NTIA minimal requirements identified within NIST Guidance for OMB M-22-18 and EO 14028. This statement from ITI is blatantly misleading and inaccurate. Any software vendor that cannot produce an SBOM should be disqualified for not following baseline, foundational NIST SDLC practices; i.e., PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).]
[UPDATE 12/10/2022: The Department of State Evolve RFP issued on December 2, 2022 makes the whole SBOM debate moot with this statement "As part of its proposal submission, the Offeror attests that it understands it may not be eligible to compete for certain task orders under Evolve until required SBOM information has been provided to, evaluated by, and accepted by the Government."]
Now, can we all get to work meeting government requirements for SBOM, please.