The software supply chain refers to all of the components and processes involved in the entire software delivery lifecycle, from writing software programs using third-party, open source, and proprietary code to merging that code in a source repo to building your artifact through a CI/CD pipeline and packaging it for consumption on an internal or external registry.
Software supply chain security, then, is the process of making sure that each of these components and processes are secure and hardened against supply chain risks and potential vulnerabilities.
In light of recent major software supply chain attacks like SolarWinds, President Biden issued Executive Order 14028, calling for improvements to the nation's cybersecurity, and the security and integrity of the supply chain. This order, in addition to the European Cybersecurity Act, has led to increased global attention on software supply chain security risks, and how open source maintainers and organizations can help guard against them.
What are some security risks to the software supply chain?
Each component and part of the software supply chain can introduce risks that could provide bad actors with opportunities to inject malware or malicious code into your software.
Common supply chain risks include:
Unsecured repos: Code repositories—like GitHub or Gitlab repos—need to be secured to guard against risks like single-factor authentication, leaked secrets, outdated versions of dependencies, and vulnerabilities in your code, all of which can make you more vulnerable to supply chain attacks.
Exploitable vulnerabilities: Vulnerabilities, or CVEs, are essentially bugs in code that create entry points for hostile actors to exploit your software and inject malicious code. While a software program could have many vulnerabilities, they may not always be reachable or exploitable in deployed code.
Unknown or unmaintained open source software: When you take a dependency on open source software that can't be traced back to its source code and to a reputable author, you introduce a number of risks.
First, you can't verify the quality of that software, because you can't inspect the code.
Second, if you don't know who authored the code and how they authored it, you could risk taking a dependency on code written by a bad actor, with the intention to cause harm.
Third, unmaintained code is dangerous, because no one will be able to fix issues or vulnerabilities that arise, which could be exploited. Additionally, unmaintained repos can be compromised and taken over by hostile actors.
Unsafe build processes: Not properly securing your CI/CD pipelines and signing your build artifacts using technologies like sigstore can create opportunities for supply chain attacks.
Licensing misuse: When you're using open source software, make sure you check to see which license that software uses and that you know what open source licenses have been vetted for us by your organization, to avoid facing misuse, misinterpretation, and legal risk.
How does the use of AI coding assistants impact software supply chain security?
The rise of AI coding assistants like GitHub Copilot can help increase developer productivity, but it's important to understand the risks involved.
Outdated or unsafe dependencies: Depending on how often they refresh dependency information, AI coding assistants could be suggested dependencies that are no longer being maintained; known to be malicious; or could contain known vulnerabilities.
Code quality risks: It's always important to review and inspect the code generated by AI coding assistants, to make sure it will do what you expect when deployed.
Indexing confidential information: Some repos may contain confidential or sensitive information that you don't want the AI coding assistant to index.
What is an SBOM (Software Bill of Materials)?
An SBOM is an inventory of the open source and third-party components in a codebase. It's a key part of software supply chain security. President Biden, in his executive order, required organizations doing business with the government to generate SBOMs for their software, which is leading to broader awareness of this practice.
In addition to helping you track all of the components in your codebase, SBOMs can help you understand whether vulnerabilities in your code are reachable. The Vulnerability Exploitability Exchange (VEX) is a statement or attestation that indicates whether a product is affected by a known vulnerability. Software authors can generate VEX statements that you can use in combination with an SBOM to understand whether any components in your software have exploitable vulnerabilities that need to be addressed. Tools like OpenVEX aim to make it easier for software authors to handle VEX metadata.
What is artifact signing?
Artifact signing refers to the practice of producing build artifacts—like container images—with attestation statements that clearly indicate how the artifact was build, and by whom. The open source project sigstore has made artifact signing much easier for developers, enabling "keyless" signing using the developer's identity tokens. Sigstore also stores attestations in a transparency log (Rekor) to allow for crytographic verification of an artifact's signature.
Signing your artifacts provides assurance to your consumers about your build practices and identity, and can help prevent supply chain attacks. Being able to verify those signatures in a public log means that consumers can see that your artifacts haven't been tampered with. It also provides consumers with a way to inspect your source code for quality.
How to secure your development practices to prevent supply chain attacks
There are a number of methods you can take to harden your software projects and prevent supply chain attacks, including:
Securing your code repositories. Enabling 2FA, secret scanning, and code scanning in your repos can help prevent attackers from getting into your code, and sensitive information from getting out.
Keeping dependencies updated. Using tools like Dependabot for GitHub can help you make sure that you get notifications when dependencies are outdated, and take action to update them. This can help keep vulnerabilities out of your code and protect you from quality issues.
Choosing safe open source software. When you're evaluating open source libraries or frameworks, it's not enough to just check to make sure they don't have any known CVEs. It's also important to make sure they aren't known to be malicious or deprecated, and that there's a strong community surrounding those projects, based on factors like stars, followers, recent commits, author reputation, and contributor numbers.
Securing third-party CI/CD workflows. For GitHub Actions users, limiting access to what actions you use, and what those actions can do in your repos (for example, submitting approving pull requests) can help make sure hostile actors can't inject malicious code. You should also always make sure you're pinning your actions to commit SHAs, and not floating tags. Additionally, putting in place policies to limit which branches and users can produce artifacts can help with security.
Signing your software artifacts. Signing your artifacts using sigstore provides a public, transparent log of how your software was built and by whom. This helps your consumers make sure they're installing your authentic software, and not a hostile actor's manipulated version of it.
Generating an SBOM. This can help you understand what components are being used in your software—both your dependencies, and your dependencies' dependencies (e.g., transitive dependencies). It can also help you better understand which vulnerabilities are reachable in your code (as mentioned above).
Configure Github Copilot content exclusions.Content exclusion is a new feature that you can use to prevent Copilot from directly accessing the content of excluded files.
How Stacklok can help
Stacklok's open source supply chain security platform, Minder, can help you apply and continuously enforce policies to harden the security of your repos, build process, and software artifacts. You can set Minder to alert you when a part of your supply chain is out of compliance, or autoremediate to take corrective actions like re-enabling secret scanning if it's been disabled, or creating a pull request to replace GitHub Actions that are pinned to floating tags to pin to commit SHAs instead.
