The global software supply chain is always under threat from cyber criminals who threaten to steal sensitive information or intellectual property and compromise system integrity. These issues may impact commercial companies as well as the government’s ability to securely and reliably deliver services to the public.
The United States Office of Management and Budget (OMB) published in July 2022 a memo on the matter, which we covered here in detail. In September 2022, a new memo was released, this time focusing on the security and integrity of the software supply chain, underlining the significant role of SBOMs. It presents a list of precise requirements and—for the first time—shares an actual binding timeline for implementing changes.
The memo contains two main points related to the Executive Order (EO) 14028, Improving the Nation’s Cybersecurity:
- The EO directs the National Institute of Standards and Technology (NIST) to share guidance for developing practices aimed at boosting the security of the software supply chain. To help achieve this, NIST released two documents: the Secure Software Development Framework (SSDF), SP 800-218, and Software Supply Chain Security Guidance. Together, they’re called NIST Guidance and outline a set of practices that make up the foundation for creating secure software.
- The EO also directs the Office of Management and Budget to start requiring agencies to fall in line with the NIST Guidance and any other updates.
Self-attestation is a prerequisite, but is it everything?
Software producers are now required to give agencies self-attestation before they start using their software. There are actually three categories that require self-attestation: new software purchases, major version upgrades, and software renewals. The goal is to equip agencies with secure and resilient software products that protect them against threats such as what SolarWinds experienced, which compromised several agencies.
Let’s start with the basics: What exactly is self-attestation?
Self-attestation is a document that works like a conformance statement, attesting that the software producer complies with practices from the NIST Guidelines. The idea is for agencies to get self-attestation for every third-party software product or service that falls under the requirements of the memo. This includes software renewals and major version updates.
Another important point in the memo is for agencies to encourage software companies to be product-inclusive. This would enable them to provide the same attestation to all purchasing agencies.
The agency may retain the self-attestation document unless the software company posts it publicly and offers a link to the posting within its proposal.
Note: While all other memos or guidelines to date claim that self-attestation is good enough to start with, this one sets trust and transparency as the key goals. It focuses on the software supply chain specifically, not only cybersecurity or the SSDF (even if they’re part of it).
What happens if the software company can’t provide self-attestation in the standard format?
A software producer might not be able to attest to one or more practices from the NIST Guidance as identified in the standard self-attestation form. In this case, the agency requesting the software will require the company to:
- Identify those practices to which they can’t attest
- Document all the practices in use to mitigate those risks
- Develop a Plan of Action & Milestones (POA&M)
Naturally, the agency must ensure that the documentation isn’t posted publicly (by either the vendor or the agency itself).
Suppose the vendor supplies all of the documentation and it’s satisfactory to the agency. In that case, the latter may use the software products or services despite the producer’s lack of a complete self-attestation.
What does an acceptable self-attestation need to include?
A self-attestation document must include the following minimum requirements:
- The software company’s name
- A description of software products to which the statement refers to (ideally, this point describes the software company or product line level, including all the unclassified products offered to agencies)
- A statement confirming that the vendor operates in line with secure development practices and tasks (itemized in the self-attestation form)
This type of self-attestation is the minimum required level. Still, if agencies wish to procure software without it—for example, due to its criticality—they may carry out risk-based determinations with the help of a third-party assessment (defined in M-21-30).
Still, the directive encourages agencies to use a standard self-attestation form. The Federal Acquisition Regulatory (FAR) Council will propose rulemaking around the use of such a standard and uniform self-attestation form.
Self-attestation for open-source software
Suppose the agency wishes to acquire open-source software or a software product that includes open-source components. In that case, it can turn to a third-party assessment provided by a certified FedRAMP Third Party Assessor Organization (3PAO) or one approved by the agency itself.
Such an assessment is acceptable in place of a vendor’s self-attestation as long as the 3PAO uses the NIST Guidance as its baseline.
SBOMs are becoming an industry standard. Are you ready for it?
While self-attestation is the minimum level required, agencies may not need it if the product or service they’re looking to get is critical and cannot provide self-attestation in a standard form.
What’s important is that the memo encourages agencies to obtain artifacts from vendors that demonstrate their conformance to secure software development practices. One such practice includes having an SBOM.
What is an SBOM and how does it work?
SBOM refers to a Software Bill of Materials, an inventory of all components and dependencies that are part of the development and delivery of a software product.
An agency may require an SBOM as part of solicitation requirements, depending on the criticality of the software to the agency.
The memo includes the following guidelines for the procurement and use of SBOM by agencies:
- The agency can retain the SBOM unless the software producer publishes it and shares a link to it with the agency.
- SBOMs need to be generated using one of the data formats defined in the NTIA report “The Minimum Elements for a Software Bill of Materials (SBOM)” or successor guidance published by the Cybersecurity and Infrastructure Security Agency.
- When considering SBOMs, agencies are to take the reciprocity of SBOM and other artifacts from software producers maintained by other agencies into account. This is based on the direct artifact applicability and currency.
- The agency may require artifacts other than SBOM if necessary—for example, ones related to automated tools and processes for validating the source code integrity or performing checks for vulnerabilities.
- The agency may also require the software company to show proof that they participate in a Vulnerability Disclosure Program.
The memo also suggests agencies let vendors know about these requirements as early as possible in the acquisition process. To comply with the Order and NIST guidance, agencies need to plan appropriately and include all requirements in their software evaluation process. Note that this should also be in line with the timeline specified by the memo (this will be covered in the next section).
Agencies must specify requirements in the Request for Proposal (RFP) or in other solicitation documents. The idea here is for the agency to ensure that the vendor implements and uses secure software development practices in line with NIST Guidance throughout the entire software development lifecycle.
SBOM is clearly an industry best practice on the path to wide usage, particularly for mitigating software supply chain risks.
To help companies build trust in their software products, we recently launched an easy-to-use platform that helps to generate SBOMs and share them within and across organizations. Give it a try free of charge to see how easy it can be to generate, manage and share SBOMs.
It’s no longer just a recommendation; now there’s an obligating timeline to follow
Agencies need to comply with the memo requirements in line with this timeline:
- Agencies have 90 days to inventory all their third-party software, including a separate inventory for “critical software.”
- Within 120 days, they need to create “a consistent process to communicate relevant requirements in this memorandum to vendors and ensure attestation letters not posted publicly by software providers are collected in one central agency system.”
- They also have 270 days to collect attestation letters that haven’t been posted publicly for “critical software.” Within one year, agencies should have collected the letters for all third-party software.
- Finally, within 180 days of the memo’s date (September 14, 2022), agency CIOs need to have assessed any training needs and develop training plans for reviewing and validating the attestation documents and artifacts.
Agencies can ask for an extension at least 30 days before any relevant deadline stated in the memo, together with a plan for meeting the outstanding requirements. It’s also possible to request a waiver, but only in exceptional circumstances and for a limited time frame.
Summary
The OMB will share specific instructions for submitting requests for waivers or extensions within 90 days from the memo date (until mid-December 2022). Moreover, in consultation with CISA and the General Services Administration, it will determine the requirements for a “centralized repository for software attestations and artifacts” with the right mechanisms for protection and sharing among agencies.
Such a central place might someday become a central location for a variety of security evidence and attestations beyond the self-attestation form or SBOM. Placing all the evidence in a single, shareable place helps organizations deal with shared problems, such as emerging new exploits or CVEs.
This is exactly what Scribe is all about. Take a look at this page to learn more about our comprehensive platform for generating, managing, and sharing SBOMs within and across organizations.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
