Secure at every step: What is software supply chain security and why does it matter?

What counts as your software supply chain?

A supply chain isn't just the final product — it's every ingredient and every condition that affects how that product gets made. For software, that means everything that feeds into your code from the first commit through CI/CD and into production. That includes the code itself, binaries, third-party components, and where they come from — repositories, package managers, registries. It also includes the people: who wrote the code, when it was contributed, how it was reviewed, what known vulnerabilities and licenses exist for it.

The scope extends beyond your application. Build scripts, packaging configurations, and the software running the infrastructure your app lives on are part of the chain too. So is the metadata you rely on to assess risk — version history, maintainer information, supported release lines. Anything that touches your code at any point, even indirectly, belongs in the picture.

Your real exposure: inherited vulnerabilities

Most modern projects are assembled from code you didn't write. The average repository pulls in around 203 open source dependencies, and industry data indicates that roughly 99 percent of codebases contain open source components — with some estimates putting enterprise open source usage as high as 85 to 97 percent of the codebase. That means the majority of your application's code is outside your direct control.

When a dependency carries a vulnerability, so do you. The exposure is compounded by the fact that dependencies evolve without your knowledge. A vulnerability that isn't exploitable in your application today could become exploitable tomorrow if something changes in your code or in the dependency's maintenance. Effectively, thousands of strangers have commit access to your production code — whether through maintained upstream projects or abandoned ones with known flaws.

Direct supply chain attacks: real but uncommon

A software supply chain attack inserts malicious code into a component and then rides the component's normal distribution channels to reach targets. The attack vectors are varied: inserting malicious code as a new committer, compromising an existing committer's account to do it invisibly, or stealing a signing key to push software that isn't officially part of a release.

These attacks are rarely the end goal. They're typically a launching point for something else — cryptomining malware, a backdoor for botnet access, or other payloads. And while attacks are real, they remain relatively rare: fewer than tens of publicly known compromises per year. When they do happen, they tend to be highly targeted, such as nation-state campaigns against energy sector companies. Broad attacks on open source maintainers and consumers are still uncommon.

The canonical example is event-stream, a widely used Node.js library on npm. In late 2018, a new volunteer took over maintenance of the project. The new maintainer initially added a dependency called flatmap-stream, then later rewrote the code to remove it — but that removal never made it to the npm registry. Malware was subsequently inserted into flatmap-stream, affecting anyone pulling the latest version of event-stream. The original author deserves no blame: the takeover looked like normal open source maintenance, which is exactly why it worked.

Most risk is from unpatched software, not attacks

Direct attacks on the supply chain are headline-grabbing but not the main practical threat. The far more common problem is unpatched software. Roughly 85 percent of disclosed open source vulnerabilities already have a patch available when the advisory goes public — the risk comes from not applying it.

Patching is necessary but not sufficient. A mature dependency security practice means building three capabilities:

• Know what's in your environment: Discover all dependencies, including transitive dependencies, and understand their risk profile — not just vulnerabilities but also licensing constraints.
• Manage dependencies actively: When a new advisory drops, determine if you're affected and update to the fixed version. Review changes that pull in new dependencies and prune ones you no longer need.
• Monitor the supply chain continuously: Audit the controls you've set up, and eventually move from audit to enforcement so your dependency set doesn't drift back into risky territory.

The industry is also reaching toward stronger guarantees. Supply chain integrity aims to prove a component is exactly what it claims to be — achievable through reproducible builds. Provenance goes a step further, letting you verify where a component originated, via signed builds or transparency logs. Both concepts feed into the software bill of materials (SBOM), a list of every component in your software that resembles a verified ingredient list from a manufacturer.

Native tooling for dependency security

Software composition analysis (SCA) is the practical set of tools that turn these principles into workflow. SCA answers three questions: what dependencies do you use, which of them have known vulnerabilities, and how do you patch them?

GitHub's SCA features target those questions directly:

• Dependency graph: Maps all upstream dependencies and public downstream dependents for a repository or package, and surfaces detected vulnerabilities in that context.
• Dependabot alerts: Uses the dependency graph and GitHub Advisory Database to notify you when a newly disclosed vulnerability affects your repositories.
• Dependabot security updates: Automatically opens pull requests that bump a dependency to the minimum version that resolves a known vulnerability. Dependabot version updates run on a schedule you set, checking for new releases and opening update proposals.

The takeaway is straightforward. Supply chain compromises deserve attention, but the greater immediate need is vulnerability hygiene: know every dependency in your stack, track disclosed vulnerabilities affecting them, and patch fast. That combination — awareness, notifications, and automated update PRs — is what closes the gap between an open source ecosystem with known flaws and an application that stays safe in practice.