Modern software is rarely written from scratch. A typical application combines open-source libraries, container images, build plugins, cloud services and packages assembled by different teams. That reuse makes development faster, but it also means a defect or compromise in one component can affect many downstream products. Software supply chain security is the practice of understanding those dependencies, protecting the development process and keeping trustworthy evidence of what actually shipped.
Why a dependency list is not enough
Imagine a small company building an online booking platform. Its developers use a framework, an authentication library and a payment SDK. The production container also contains operating-system packages and monitoring tools. Even if the company writes secure application code, a vulnerable dependency or compromised build environment may still expose customers. An inventory helps, but the company must also know which components run in production, who maintains them and how quickly they can be replaced.
Supply-chain risks take several forms. A legitimate package may have an exploitable vulnerability. A malicious package may imitate a trusted name. A maintainer account may be taken over, or a CI pipeline may be modified to include unexpected files. These situations require different responses. Scanning for known vulnerabilities will not automatically detect a stolen signing key or an unauthorized build step.
Establish an inventory of what ships
A software bill of materials, or SBOM, records components used to create a product. It can include package names, versions, identifiers and dependency relationships. SBOMs help answer operational questions during a security incident: Does the affected library appear in our application? Which services include it? Which release first introduced it?
Generate the inventory as part of the build process, not as a manual spreadsheet updated after release. Retain the inventory with the build artifact so investigators can match a specific production version to its dependencies. Keep in mind that an SBOM is evidence of composition, not proof that components are trustworthy. It also may not capture every runtime service, external API or hidden dependency.
Be deliberate about package selection
Before adding a dependency, ask whether its functionality is necessary and whether a maintained alternative already exists in the codebase. Review its maintenance activity, release history, documentation and security reporting process. A library with many downloads is not automatically safe; popularity is just one signal. Consider whether the package executes installation scripts, uses broad permissions or brings in a large tree of secondary dependencies.
Lock dependency versions so developers and build servers resolve predictable artifacts. Review updates in manageable groups rather than allowing uncontrolled upgrades directly into production. Automated dependency pull requests can be useful, but they should still pass tests and risk review. When replacing a library, remove unused packages instead of leaving them installed indefinitely.
Protect the build pipeline
Build infrastructure is a high-value target because it can change the final artifact without modifying the code developers review. Protect source control with strong authentication, limited repository permissions and required reviews for sensitive workflow files. Restrict who can change release settings, signing credentials and deployment environments.
Use short-lived credentials where supported, isolate build jobs and avoid giving untrusted pull-request workflows access to production secrets. Pin third-party CI actions to trusted versions or immutable references according to your platform’s guidance. Store artifacts in controlled registries and audit changes to release pipelines. A clean local test is not enough if the server that packages the release can be altered.
Understand provenance and signatures
Provenance tells you where an artifact came from and how it was built. A signature can help verify that an artifact has not changed since a trusted signing operation, provided the signing identity and keys are protected. These mechanisms are complementary. A malicious build can still be correctly signed if an attacker controls the authorized build system.
A useful release record connects a source commit, approved workflow, build environment, dependency inventory and produced artifact. Teams can then verify that the file deployed in production matches the one reviewed and tested. Start with one critical service rather than expecting every legacy system to adopt advanced attestation immediately.
Make vulnerability handling practical
When a security advisory appears, prioritize affected software based on actual exposure and exploitability, not only the severity score. A vulnerable library used in a public-facing authentication flow deserves different urgency from a development-only utility that never reaches production. Still, do not assume a package is harmless merely because no exploit has been publicly demonstrated.
Keep an owner for every critical application and a clear path for emergency updates. Test security patches in staging, deploy with rollback capability and monitor for regressions. For components that cannot be replaced quickly, document compensating controls and a removal deadline. Revisit those exceptions rather than allowing them to become permanent.
Practice an incident before it happens
Run a tabletop exercise: a widely used dependency is discovered to be compromised, and executives need to know whether the company shipped it. Can the team identify affected builds within an hour? Can it revoke deployment credentials, block a package version and rebuild from a trusted environment? Can it communicate clearly to customers without making unsupported claims?
Exercises expose gaps that dashboards do not. Teams often discover that dependency inventories are outdated, container base images are poorly tracked or no one knows which build is currently deployed. Address those gaps while the situation is calm.
What smaller teams should do first
Begin with a dependency inventory for the most important application, reproducible or well-controlled builds, protected source control and an update process with named owners. Add automated vulnerability alerts and review the permissions of release workflows. Then improve artifact signing, provenance and continuous policy checks as the organization matures.
The central lesson is that software supply chain security is not a product you buy once. It is a series of decisions about trust: which code you accept, who may change it, how you package it and what evidence follows it into production. Better visibility and controlled releases make those decisions defensible when the next vulnerability or compromise appears.
Further reading: CISA Secure by Design resources.
