By David Tesar, Principal Product Manager at Microsoft
There is an overwhelming amount of software secure supply chain requirements and frameworks combined with an explosion of tooling to try and address these concerns. As soon as container images are added into the mix, they bring another layer of security concerns and even more tooling options. Is there a way to jump in and quickly accelerate software secure supply chain maturity and if so, where to start?
The heart of where the work gets done with software secure supply chain is – no surprise – the build orchestration system. This is where external software sources such as packages and container images will get pulled in and then various actions can be automated to secure the supply chain in a build pipeline. Naturally then, having a starting pipeline workflow with numerous tools is a major way to accelerate maturity.
What do we need to accomplish in the pipeline, which tools should we use for this purpose, and in what order should they be invoked? Let’s break this down into categories of things to accomplish along with supporting free open-source tools. By no means is this list comprehensive, but it covers some of the major items where there are numerous tooling choices.
Static code analysis
Static code analysis has been around for a long time and is still a very relevant and evolving space today. Some of the static code analysis tools detect security vulnerabilities in the source code itself or other general issues. In some cases, static code analysis security tools can even help secure the build orchestrator pipeline code. Even though static code analysis tools primarily focus on general security of the code, not the supply-chain itself, it is an important area to help secure the root of the value you’re trying to deliver and needs to be mentioned.
What free OSS tools can help in this space?
CodeQL and a list from OWASP. OpenSSF Scorecard does numerous checks, but also does static analysis of the build orchestrator pipeline code.
Software Bill of Materials (SBOM)
The SBOM is an essential fundamental because it provides information about what software components, vulnerabilities, and associated licenses were contained inside at the time it was built. This is essential for consumers to assess legal and security risks before deciding to utilize the software. For producers it’s also useful to be aware of what dependency relationships and vulnerabilities may exist in the packages and adjust accordingly. There are three major standards: SPDX, SWID, and CycloneDX.
What free OSS tools can help in this space?
Software Bill Of Materials generation tools
Scan for known security vulnerabilities
There are numerous angles to what constitutes a vulnerability in running software, but most commonly available tools detect known software vulnerabilities from the CVE data source. These vulnerabilities can be found in the base container images, source code itself, or in consumed software packages. It is important to know not only what vulnerabilities exist at the time of build but also to rescan published software for vulnerabilities over time and update the vulnerability reports. This enables consumers to be aware if they are running or decide to run older versions and for software producers to consider patching the source code. The tools which do the scans in some cases can operate on the produced SBOM.
What free OSS tools can help in this space?
Signing
After generating artifacts such as a packaged build of code, SBOM, and vulnerability scan – how can one be sure it hasn’t been tampered with after its original creation? One important element to solving this problem is by signing those artifacts. At a high-level, typically some form of private key generates a unique signature using a cryptographic algorithm based on the artifact which can be verified by whomever has the associated public key. If the contents are modified, then the hash is no longer valid, and you could consider the contents tampered since its original creation.
How can you know who the artifact was created by? And that it matches what was built originally? This is where provenance, attestations, claims, and ledgers come into play. Unfortunately, this is beyond the scope of this article. That said – artifact signing is an essential foundation. For instance – if you have an idea of who created the artifacts and know it appears to be what it says was built at that time but have no idea if someone hacked the contents afterwards, it doesn’t help. Supply Chain Integrity, Transparency, and Trust (SCITT) is also an upcoming IETF standard to help address the additional challenges in this space.
What free OSS tools can help in this space?
Pipeline invocation flow
What order should these steps be executed in the pipeline?
Generally, tasks in a build pipeline should be executed closest to the code and quickest feedback to failure. Therefore, static code analysis tools should be considered for execution after builds. If the static code analysis tool chosen is long-running, then it might be run in addition or alternatively on regular intervals and as a gate for passing with a minimum bar before releases.
If the software’s final delivery mechanism is inside a container image, this needs to be built next adding in the application build files from the previous step because it introduces additional security vulnerabilities and software for what is being delivered.
After generating the SBOM, there should be a full list of software available ready to be scanned for vulnerabilities and a report generated and potentially attached/associated with the SBOM.
Next all the artifacts would be signed and finally pushed to the OCI artifact registry or other artifact storage location. Ideally policies would be put into place so if any of the steps do not meet the criteria the artifacts do not get pushed to the final step of pushing to the artifact registry. For instance, if there are high vulnerabilities you wouldn’t want it as a candidate to deploy.
What can or should you do after the build/push artifact pipeline steps above?
After the artifacts are in their storage location, they then ideally be scanned occasionally for vulnerabilities if they are consumed by others and then at that time have the corresponding vulnerability artifact metadata updated, signed, and pushed as an addition.
There are also ways to enforce or utilize this data to make decisions before deployment which are beyond the scope of this article. For instance, if the artifact is a container image targeted to run on Kubernetes cluster there are admission controller mechanisms to only allow verified signed images you trust. See ratify, kyverno, and connaisseur.
What can I do next?
Join the conversation at sig working group – secure supply chain maturity. We’re working on sample pipeline templates you can start with which implement many of the elements of the OSS Secure Supply Chain Framework.
##
To hear more about cloud native topics, join the Cloud Native Computing Foundation and the cloud native community at KubeCon + CloudNativeCon North America 2022 in Detroit (and virtual) from October 24-28.
ABOUT THE AUTHOR
David Tesar, Principal Product Manager
David is a Principal Product Manager at Microsoft with a passion to help people and organizations achieve more via cloud native technologies. David was the manager of a software development team who consulted, provided feedback, and implemented solutions for customers and Microsoft software engineering teams around DevOps, MLOps, GitOps, and observability. David is experienced with many technologies but is most focused and energized these days on software secure supply chain, Kubernetes, Golang, Node.JS, React.JS, Linux, and GitOps. David has created and delivered a vast amount of technical content including hundreds of videos, numerous online courses, and spoken at various public events.
