NIST charts course towards more secure supply chains for government software

Preliminary ideas emerge for more effective, ecosystem-wide standards and guidelines

UPDATED The US National Institute of Standards and Technology (NIST) has shared a raft of recommendations, submitted by the infosec industry, for bolstering federal agencies’ defenses against the burgeoning threat of software supply chain attacks.

NIST is collating suggestions from various tech and infosec organizations with the objective of creating standards and guidelines that will guide the federal government’s approach to software procurement and security.

As directed by a recent executive order from President Biden, NIST held a virtual workshop with 1,400 attendees earlier this month, and published 150 papers of recommendations submitted from the likes of Microsoft, Google, and The Linux Foundation.

The announcement comes in the wake of a string of high profile supply chain attacks, such as those against SolarWinds and Codecov applications, and a deluge of malicious packages that infiltrated open source repositories through ‘dependency confusion’ in March.

Defining ‘critical’

As part of the cybersecurity-focused May directive focused on supply chains, the Biden administration called for “more rigorous and predictable mechanisms” for securing “critical” software, in particular.

However, industry feedback suggests that even defining ‘critical’ will be challenging.

In its response to NIST’s call for papers, for instance, the Software Engineering Institute (SEI) said “software and its context of use are inseparable for the purposes of determining the ‘critical’ designation”.

Citing use cases for OpenSSH, it added: “A hobbyist web server hosting cat pictures and a nuclear power plant have different ‘...potential for harm if compromised’.”

The SEI also warned against adopting a “static” definition for critical software, instead recommending a designation “mechanism” supported by an adapted Stakeholder-Specific Vulnerability Categorization (SSVC).

SALSA

Part of Google's contribution, meanwhile, was an end-to-end framework, called Supply chain Levels for Software Artifacts (SLSA), designed to protect “the integrity of software artifacts throughout the software supply chain”.

The tech giant has pitched SLSA as the first framework of its kind to encompass the full development workflow: source-build-publish.

Pronounced ‘Salsa’, the framework comprises “incrementally adoptable security guidelines” across four levels – ranging from an automated, provenance-generating build process (SLSA 1) through to a two-person review of changes and “a hermetic, reproducible build process” (SLSA 4).

Less is more

The SEI also suggested that federal agencies should expect to see vulnerability disclosure programs (VDP) and software bills of materials (SBOM) on offer from prospective suppliers.

They should also heed the axiom that ‘less is sometimes more’, suggested the SEI: “operating less software and enabling fewer features reduces attack surface”, it said.

Vendors were advised to give appropriate notice of end-of-support dates and “proactively mitigate the risk associated with a single, centralized secure [software] update mechanism” – the attack vector at play in both the SolarWinds and NotPetya attacks.

Existing guidance on these and other areas, added the SEI, was too profuse and ought to be consolidated.

On the subject of testing source code, NIST’s workshop summary put forward a recommendation that at least one developer per project “should have security training: specifically, a course where they had to break into a program”.

As for choosing tools and technologies, it was suggested that developers use fuzzing as a cost-effective means to pick up elusive, “bizarre cases” of potential vulnerabilities.

According to Brian Fox, co-founder and CTO at DevOps automation platform Sonatype, “the NIST proposal is focused on defining minimum requirements for software sold to the government. These requirements will inevitably influence the rest of the industry given the wide scope of software sold to the US government.

“The Google proposal, on the other hand, goes beyond minimum requirements and proposes a specific model for scoring the supply chain posture that produced a given component,” Fox tells The Daily Swig. “Those scores will drive people to focus on many key elements that are often ignored such as ‘is the system that built this binary secure?’.

“In summary, NIST is currently focused on ‘what’ and Google along with other industry proposals are grappling with ‘how’.”

Correction: This article was updated on June 21 to reflect the fact that Google’s proposals were submitted in response to NIST’s call for papers rather than being an entirely separate initiative.