Despite setting an impressively high bar and aggressive timeline for third-party vendors to implement software supply chain security for any application deemed critical to US agencies and departments, the US government has inexplicably decided not to hold internally developed applications to the same standard.

If the software supply chain is only as strong as its weakest link, the US government has just undermined it by exempting internally developed software from key security requirements, namely attestations.

Attestations are nothing more than metadata about how software artifacts are sourced and built. But in the context of a software supply chain, attestations become a key way to:

• Readily identify weak links in the chain
• Set minimal source and build criteria for any artifact incorporated into software
• Create programmatic verification of source/build criteria in order to enforce compliance

Without attestations to accompany the software developed within the US government, the systems and solutions they deploy, which often involve combining software from multiple vendors as well as internal sources, will not meet the security goals first laid out in Executive Order 14028, “Improving the Nation’s Cybersecurity.”

To put things in perspective, some context is required.

US Government Use of Open Source Software

The majority of the US government departments and agencies were wary of adopting open source software (OSS) throughout the 1990’s and 2000’s. Although certain agencies, notably NASA and DARPA, were early adopters and even producers of OSS, the rest of the US government was late to the table.

It wasn’t really until the tail end of the Obama administration’s release of the “Federal Source Code Policy” in 2016 that use and support of OSS by the US government became standardized. Crucially, the policy included “a pilot program that requires agencies, when commissioning new custom software, to release at least 20% of new custom-developed code as open source for three years.”

Pandora’s box had been opened. Five years later, the Biden administration would finally try to bring the chaos it unleashed back under control by releasing Executive Order 14028in May 2021. EO 14028 reiterated the need for software producers to follow a Secure Software Development Framework (SSDF) such as that created by the National Institute of Standards and Technology (NIST), but also recognized the gaps that allowed US government vendors like Solarwinds and vital infrastructure providers like the Colonial Pipeline to be compromised. Proposed was the addition of:

• A Software Bill Of Materials (SBOM) associated with any software purchased by the government.
  • While essential for allowing the quick identification of compromised software components, I’ve argued elsewhere that its benefits are minimal without an accompanying attestation for each component.
• A way to check for and automate vulnerability remediation.
  • While the average speed of vulnerability remediation has improved over the years, it’s still measured in weeks or months rather than days. Worse, the focus on vulnerabilities tends to focus time and resources on what is essentially only the tip of the software-supply-chain-threat iceberg.
• Provenance, or the ability to be able to identify the origin for all software components
  • This is where Provenance Attestations come in, which provide a way to understand how each component incorporated in the software was sourced and built.

The EO imposed dates for both government agencies and their software suppliers, including:

• June 11, 2023: “Agencies shall collect attestation letters for “critical software””
• September 13, 2023: “Agencies shall collect attestation letters for all software”

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, the requirements were also supposed to apply to software created by the US government itself.

However, with the latest directionfrom the Department of Homeland Security (DHS) and Cybersecurity and Infrastructure Security Agency (CISA), the following will no longer require attestations:

• Software developed by Federal agencies; and
• Software that is freely obtained (e.g. freeware, open source) directly by a federal agency

In other words, even if the US government succeeds in closing Pandora’s box on third-party developers, it will still have a hole large enough to allow hackers in through government agency -developed software.

Conclusions – Ensuring Security & Integrity with Attestations

Government software initiatives tend to be highly security-conscious, especially if developers are working on FedRamp which has been proactive about introducing NIST security and privacy controlsaimed at curbing software supply chain threats since 2020. This date correlates strongly to an uptick in supply chain attacks that began with the Solarwinds hack in December 2020.

Since then, however, there has been an explosion in attacks, some of which are well known and can be controlled for, as well as others that have never been seen before. Given the economies of scale bad actors can realize by compromising a single, popular piece of software that then gets propagated across multiple systems, agencies and departments, it seems likely that bad actors will be highly tempted to target government-created software by continuing to compromise open source components. In other words, without an attestation requirement for all the components that go into a piece of software created by government development teams, it will be “business as usual” for hackers.

At time of writing, the US government is still collecting feedback on their Secure Software Development Attestation Common Form and the exemption for government developers.

For government vendors that are NOT exempt from attestations (or any development team that wants to ensure the security and integrity of the software they produce), there are a number of options that can create attestations today, including:

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

However, unless you plan to vendor all the dependencies your project requires and build them from source, these solutions can only provide an attestation for your proprietary code. Consider using the ActiveState Platform to automatically build all your open source language components (including binaries) from source code. Software attestations are also automatically generated for each component, and can be programmatically retrieved via our GraphQL API.

Read Similar Stories