Software supply chains can seem like security nightmares. Their distributed nature and naturally wide attack surfaces make them tough to keep safe — and it doesn't help that they typically represent mission-critical assets.
But keep your chin up! Infrared Security Managing Member Eric Sheridan shared a more positive outlook, demonstrating how reframing the problem from a platform engineering perspective could make supply chain security more doable.
What is the software supply chain?
Eric started by helping us get a handle on the concept, which is critical to understanding the security realities. According to him, a software supply chain entails all the people, processes, and technologies used to write, build, deploy, and consume software.
Now this may be a broad definition, but Eric said it’s the plain reality. There’s no shortage of moving parts, and from a security perspective, blind spots are a bad thing.
Speaking of the security lens, a good way to approach this idea is to break it down. The logical flow and sequence of steps in the typical software development process offer a handy framework for doing so.
Implementation-specific distinctions aside, Eric advised breaking software lifecycles into a few common stages. He then took us through the risks of each and offered some helpful tips for improving your security posture.
The writing phase
The typical software lifecycle starts in the planning phase: when someone has an idea and they begin writing code. Eric said this was the ideal place to start thinking about supply chain security.
Going back to the original definition of supply chain security, this stage is about the people aspect. Who's contributing to your software, and how do you confirm their identities? Zero trust — the idea that you should verify everything — should also apply to contributors and stakeholders.
Malicious insiders are prime examples of the risk. If someone spoofs the identity of a trusted contributor, they can socially engineer access to your repos and assets. There have been numerous state-sponsored attacks involving this kind of threat, and platforms like GitHub have even banned impersonation.
Eric gave the infamous example of the "hypocrite commits" research project. University of Minnesota researchers introduced vulnerabilities into the Linux kernel to test the feasibility of doing so via minor patches. In this case, the patches seemed to fix legitimate bugs, but they contained subtle vulnerabilities. While the Linux community eventually banned pull requests from the university, the incident shows that bad actors can weaponize the confidence you place in developers.
Fortunately, there are ways to improve trust. For example, you can:
- Use strong identity management with multi-factor authentication as per NIST or similar guidelines,
- Implement strict access controls, and
- Conduct regular peer reviews to avoid complacency.
The sharing phase
Your trusted contributors have written some great software. Now they want to share it by committing to your repos. At this point, you ought to build on the people-oriented security frameworks discussed above: authentication, repository access configuration, and peer review processes.
It's important not to overlook the minor details along the way. Eric said that many of the companies he's worked with tried to encourage open collaboration by letting anyone in the organization see any code they wanted to explore. Sadly, this strategy had inadvertent side effects, like exposing secrets and credentials to unauthorized actors. It's great to be transparent, but you can't give up the keys to the kingdom in the process!
The build phase
This stage exemplifies the "supply chain" perspective on software development. Your build pipelines pull from internal source code, third-party package registries, and independent open-source repositories. They access artifacts from identity systems, databases, and other services to create cohesive software units for distribution. In short, there's a lot that can go wrong here.
Where should you focus your attention? Eric said a few rules of thumb stand out.
Manage your credentials
Avoid keeping hard-coded secrets in your source code at all costs.
Secure your build environments
Harden your build environment (and servers) just as diligently as you fortify your production environment. The SolarWinds attack proved that build process tampering can effectively introduce malware into code.
Rethink your approach to third-party assets
Audit your third-party components under the assumption that they have inherent risks. Think of massive incidents like the Log4j vulnerability. If that doesn't light a fire under you, there are also open-source protest ware, typo-squatting, and other risks to think about.
Document your bill of materials
Create a software bill of materials (SBOM) describing the components, dependencies, compiler tools, third-party services, and everything else that goes into your software. Eric likened an SBOM to a list of all the ingredients in a food product. They're helpful for internal vetting, but they also ensure your customers can easily assess your products for safety.
This is particularly important if you want to satisfy the minimum elements defined by nation-level security initiatives like Executive Order 14028. There are multiple SBOM frameworks to choose from, such as the widely used CycloneDX, and Eric recommended picking whichever works best for your stack and tooling.
The testing phase
The build phase typically results in an artifact that requires testing. Depending on your organizational structure, testing could happen during the build process or separately. As far as supply chain security goes, however, this stage deserves special consideration.
And just what should that special consideration look like in practice? Eric advised it might be a good idea to consider working with a few open-source tools that focus on security. Specifically, he pointed to:
Syft
Syft is a CLI-based scanner that reviews container images and file systems to discover artifacts and generate SBOMs. Syft also lets you digitally sign SBOM attestations according to the in-toto Attestation Framework.
Syft is a good solution for getting started if you haven’t been generating SBOMs already. It also supports a wide range of publishing ecosystems and programming languages.
Grype
The Grype CLI tool scans container images and file systems for high-risk artifacts, consuming previously generated SBOMs. It then alerts you if it finds evidence of an associated CVE or other known exploitable vulnerability.
If you use both tools, you can feed Grype your Syft-generated SBOMs and use the results to determine whether builds should pass or fail.
LicenseFinder
LicenseFinder recursively scans directories to find licenses and then lets you enforce policies in kind. For instance, you might want to forbid certain projects from using AGPL or GPL software — license scanning can make that task easier.
Although licensing might not seem like a security issue, Eric maintained that it's a helpful conversation sparker. Also, most organizations need to worry about licensing risks, and this is the perfect stage for that.
The deployment phase
One of the most important security considerations around deployment is ensuring you're deploying what you meant to. Don't take this for granted. Going back to the SolarWinds attack example, bad actors may attempt to inject vulnerabilities into your deployment process and catch you off guard.
One remedy for deployment vulnerabilities is to harden the repos and environments that contain your software. Another, according to Eric, is to concentrate on integrity. Do you have justifiable confidence that what you're deploying is the same as what you've built?
For many cloud-native platform projects, integrity checks will occur at the container level. Eric recommended a tool called cosign, which lets you sign your container images using a key pair for subsequent validation.
Reject the notion that you should skip these extra steps because they're too much work — you can automate them with your build pipeline. For instance, you might configure your repo to verify signed images and check for CVEs using tools like GCP’s binary authorization policies, or similar alternatives.
The consumption phase
Many engineers overlook this essential step, assuming their job is complete after they deploy. That's incorrect!
Your consumers must be able to confirm that the software they receive from you is actually what you intended to give them. In other words, you need to make it easy to verify the artifacts you ship and your authenticity as their author. As you might expect, this gets back to practices like digital signature enforcement and cryptographically secure identity management.
Providing consumers with ways to verify your identity and your products isn't just a professional courtesy. It can also help you avoid serious high-profile issues, like WordPress installations plagued by malicious updates, smart cars being unlocked remotely, or hackers using TV remotes to eavesdrop on consumers. In many of these cases, the problem boiled down to subpar authentication — the devices or systems in question lacked the means to verify the messages they were listening for.
If you’re running K8s clusters, Eric recommended the open-source admission controller connaisseur. This controller intercepts resource creation and update requests sent to a cluster, verifying their signatures against the public keys you supply before accepting them. It's also easy to set up using tools like Helm.
Jump starting your supply chain security efforts
The software supply chain security concept is still young, and it's also complicated. Eric ended on a positive note, however. The emergent nature of this domain means there are plenty of maturity models popping up to help you get started, with options like the Linux Foundation-led SLSA receiving backing from major players like CNCF, Google, and VMWare.
Want to find out more? If you care about supply chain security, you should definitely sit down for the whole webinar. You'll get to see how Eric integrated Grype, Syft, and LicenseFinder into a demo project using Azure pipelines and hear his take on audience questions. You can also find Eric in the Platform Engineering Slack channel, so why not join the community?