NIST, Google chart course towards more secure software supply chains

Momentum building for effective, ecosystem-wide standards and guidelines

Google and the US National Institute of Standards and Technology (NIST) have unveiled separate proposals to consolidate industry best practices for tackling the burgeoning threat of software supply chain attacks.

Earlier this week, Google announced 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”.

NIST, meanwhile, has collated recommendations from various sources with the objective of creating standards and guidelines that will guide federal agencies’ approach to software procurement and security.

The announcements 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.

READ MORE Open source ecosystem ripe for dependency confusion attacks, research finds

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, Synopsys, and The Linux Foundation.

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).

Less is more

On the theme of securing the development lifecycle, the institute said 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.

Read more about the software supply chain attack news and analysis

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.

SALSA

Google, meanwhile, 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).

The proposals from Google and NIST are complementary, 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,” he tells The Daily Swig. “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,” continues Fox. “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’.”

RELATED GitLab fixes serious SSRF flaw that exposed orgs’ internal servers