The National Institute of Standards and Technology (NIST) has published a draft document outlining strategies for applying software supply chain security (S3C) measures into your CICD pipelines. This comes as an extension of the Secure Software Development Framework (SSDF) also published by NIST.
This new document will be useful for organisations looking to improve their supply chain security posture—much needed, as we’ve seen a number of sophisticated attempts at compromising supply chains the last few years. We shouldn’t forget that 82% of CIOs say that their software supply chain is vulnerable to attacks. So, if you’re worried about your supply chain, know that you’re not alone.
Get the insights and advice you need to find and fix vulnerabilities in your software supply chains.
Some interesting concepts that are being discussed in the NIST document
Zero trust architectures, role-based access control, permissions
A lot of the document discusses various ways to control who is allowed to do what. These are two critical components to consider within your supply chain: who are the actors present and what actions are they trying to perform. You will have machines pulling from repositories, you’ll have developers pushing to repositories, you’ll have third-party libraries being included (both local and remote). As an organisation, you need to decide on how you’re going to solve the identification problem that your domain presents.
Policy as code
As a follow-up from organisations adopting infrastructure-as-code (IaC), we are seeing more and more organisations adopt policy-as-code as well. This means that you’re declaring your policies as code, usually with YAML, and pushing them to your repositories.
There’s a few alternatives that can be used for this, e.g. Open Policy Agent (OPA) by Styra, Sentinel by Hashicorp
Attestations
An attestation is an authenticated collection of metadata, generated by a process, and verifiable by a consumer. When you’re beginning to secure your software supply chain, you have to start collecting metadata around your build process and how your applications are created.
Integrity of evidence
Even with all the attestations and evidence that you may collect both from your internal and external processes, you need to be able to verify the integrity of those. You need to figure out a way of ensuring that the evidence can be trusted.
GitOps
It’s nice to see GitOps being given some spotlight here. We at Venafi Jetstack Consult have always been strong proponents of using GitOps for managing your applications.
Using a single source of truth with your repository and then having a mechanism that makes sure that what is being deployed is also what’s being represented in your version control system. This is an extension of the continuous deployment, in that it’s constantly “deploying” but through reconciliation rather than pushing.
This is also one of the few areas where the document mentions specific products: Argo CD and Flux.
Key takeaways
This initial draft will hopefully result in a collection of requirements that the industry can agree upon and implement solutions for. But for now, the document doesn’t offer any recommendations around specific artefacts or frameworks that could be used, i.e. SBOM’s, attestations etc. NIST argues that the field is still growing and standards are still evolving. Which is true, but not that helpful. We have discussed a few of the tools you can use in the past.
If you want to know more about tools that can help your organisation improve their software supply chain, let us know! And remember, we have our Software Supply Chain Toolkit that you can have a look at.