Secure Software Supply Chain - Standards and Observations
Many secure coding standards lack detail on the secure software supply chain. The good news is that there are useful guides and standards out there, they’re just not the ones most people reach for.
I recently delivered a secure software supply chain strategy for a large Australian company, which meant reviewing a lot of existing secure development standards and guides. The usual bodies were all in scope: NIST, DSD, ASD, and OWASP. Most of them had only a few bullet points referencing supply chain, open source, and SBOMs (Software Bill of Materials), and were light on the detail you’d need to actually do anything.
My lens was primarily open source usage: maintenance, vulnerabilities, the ability to upgrade, and malware.
The standards worth your time
These are the frameworks that seem genuinely helpful and actionable. They also don’t appear to have much awareness within the industry.
Secure Supply Chain Consumption Framework (S2C2F)
OWASP Secure Component Verification Standard (SCVS)
SLSA (Supply-chain Levels for Software Artifacts) has some good material, but it’s less actionable than the two above and is primarily focused on artefacts rather than a wholistic approach within an organisation or team.
Also worth mentioning is the OpenSSF (Open Source Security Foundation), which has focus areas across many facets of open source.
Observations
A few themes come up repeatedly, both in the standards and in what I see inside organisations.
Do you have an open source inventory?
You need one to handle incidents when a popular library has a critical vulnerability, and to do predictive maintenance when libraries have breaking compatibility challenges, or are simply unsupported or orphaned.
Are your open source libraries actually being maintained, and how far behind latest are you?
SBOMs are useful for knowing what you’re using. They don’t tell you whether you’ll have maintenance challenges upgrading when you need to. Is the library years old? Is there a risk of no upgrade path or no fixes when something breaks?
The supply chain is complex, and you have no commercial or social relationship with the libraries you depend on.
Many libraries carry a limited liability license like MIT. Are you comfortable running a production application on libraries with clauses like this?
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
Source: opensource.org/license/mit
Many open source libraries are a hobby for someone who isn’t getting paid to build or maintain what you’re using.
Do you know what security testing the developers are using on their libraries?
Many libraries also depend on other libraries. ts-lint, a developer code checking library, has 30+ direct and transitive dependencies. That’s part of your supply chain too.
ts-lint’s dependency tree, via npmgraph. Eight direct dependencies, ~30 packages once you follow them down.
Keep in mind there can be hundreds or thousands of developers who have contributed to a library. They haven’t done your compliance training, or used your security testing tools, or met your security team. ExpressJS, a popular JavaScript microservice framework, has 300+ contributors, with the original authors not contributing in years.
Malware
Open source libraries are an emerging target for threat actors. It shows up in various forms: typo squatting package names, account takeover, malicious contributors. The target can be the developer, the pipeline, the running server, or even your customer, depending on the library.
Thankfully the guides above suggest controls that help. But many software composition analysis (SCA) tools focus more on accidental vulnerabilities than malicious intent, and may not cover this risk well. I tested this on a real case — a package with known malware — and wrote up what the tools did and didn’t catch in Does SCA detect malware?
In summary
We need visibility into what open source libraries, packages and images are being used, as well as the controls and practices from the guides above, to manage both operational and security risk.
What visibility and controls do you have in place? What standards and frameworks did you find useful?