It’s the beginning of a brand new year, and time to start getting serious about those New Year’s resolutions we all promised ourselves. If one of your resolutions wasn’t securing your software supply chain you might want to add it ASAP, especially if any of your customers happen to interact with the US government.   

The due date for software suppliers to US government agencies to provide attestations and SBOMs is coming up quickly. The deadline should not be a surprise to anyone following the struggles the US government has had in limiting hackers exploiting weaknesses in the software supply chain. For example, in May of 2021 there was a U.S. Presidential Executive Order on Improving the Nation’s Cybersecurity (EO 14028), which was later clarified in September by Memorandum M-22-18. Both documents set a number of important dates for government agencies and their software suppliers, including:

• June 11, 2023 which is less than 6 months away: “Agencies shall collect attestation letters for “critical software” subject to the requirements of this memorandum – Within 270 days”
• September 13, 2023 which is less than 9 months away: “Agencies shall collect attestation letters for all software subject to the requirements of this memorandum – Within 365 days”

These requirements to secure software supply chains are a direct result of the exponential growth in the number of attacks on the software ecosystem. Although the requirements are specifically directed at vendors who supply US government agencies and departments with software that touches government systems/data in any way, standards tend to spread across the entire software ecosystem, so we expect these requirements to become a standard software practice over the next few years. For example, secure software supply chain initiatives have come up in both Japan and the EU.

Secure Supply Chain – What Does It Mean?

At a high level the guidance boils down to the need to generate a Software Bill of Materials (SBOM) and software attestations, as well as the need to follow secure software development practices as outlined by NIST for any vendor that produces software for or supplies software to government agencies:

• SBOMs are hopefully not new to you since SPDX, one of the current ISO standards for SBOM, has been around since at least 2013. Other common SBOM formats include CycloneDX and SWID, which DevOps vendors can help you generate when you use their build processes for your own code. 
• Software Attestations got a lot of attention in 2022. The most popular framework for generating software attestations to date has been Supply chain Levels for Software Artifacts (SLSA), which commonly uses the in-toto format. Many DevOps providers and software companies are working to enable SLSA software attestations for your proprietary code (specifically provenance attestations) as part of their build process, such as GitHub Actions. 
• Secure Software Development is not a new concept, however the memorandum has specifically indicated agencies must follow the current NIST guidance, which consists of both the Secure Software Development Framework (SSDF) Special Publication 800-218 and the NIST Software Supply Chain Security Guidance. This guidance should not be surprising for any security-conscious organization that has been in the software industry for a while. There’s quite a lot of overlapping requirements with existing certifications and standards such as SOC2, PCI DSS / PCI SSC, ISO 27001, etc. so you may already have a good amount of the requirements covered.

The SSDF practices are organized into four general areas:

• Prepare the Organization (PO): an organization’s people, processes, and technology must be prepared to perform secure software development at both the organization level and, in some cases, at the individual development group or project level.
• Protect the Software (PS): Protect all components of the software from tampering and unauthorized access.
• Produce Well-Secured Software (PW): Produce well-secured software that features minimal security vulnerabilities in its releases.
• Respond to Vulnerabilities (RV): Identify and address vulnerabilities in software releases in a timely manner, and implement processes to prevent similar vulnerabilities from occurring in the future.

NIST has published an online matrix of SSDF requirements. As you can see, many DevOps and software development platforms already provide most requirements by default, because they have long been required by other regulated industries.

Secure Supply Chain Requirements Are Due Soon, What Do I Do?

Don’t Panic! And follow the process:

1. Start with reviewing the matrix of SSDF requirements against the rules you currently have in place as part of your software development platform. If you have been through FEDRAMP or SOC2 this should be quick!

2. See if your development platform offers plug-n-play SBOM – many do! For example: 

1. • Microsoft’s SPDX sbom-tool
   • GitLab’s CycloneDX generator
   • Anchore’s SBOM GitHub Action

ActiveState, of course, also has you covered by generating an SBOM for all of the open source packages you use. 

3. If you do not already produce one, check if your development platform can generate a software attestation for your proprietary code. Not every software vendor does yet, but many companies are focused on this so expect to see more options available soon. For example: 

1. • TestifySec Witness
   • Google Cloud Build
   • GitHub Actions
   • GitLab Runner Attestations 

While these solutions simplify the generation of attestations for your proprietary code, they will not generate attestations for prebuilt open source packages. As a next step, you will want to enable checks to make sure any open source libraries you are using are built securely and generate attestations. You can do this by building the dependencies yourself, or else rely on the ActiveState Platform to automatically build open source binaries from source code and generate attestations for you in the first quarter of 2023.

4. Finally, do a review of the SLSA framework level requirements. Again, if you are already following the SSDF FEDRAMP or SOC2, you should be able to get through the list quickly and decide which level you are (Level 1, 2, 3 or 4).

You don’t need to panic about the pending June 11, 2023 deadline, but you should make sure you are actively working towards it as it is less than six months away. . 

Read Similar Stories