Most of the code in a modern application was written by someone else. Open-source packages, base images, build plugins and CI actions make up the bulk of what actually runs in production. Yet in many design reviews, dependencies get a single line: "uses well-known libraries".
That line hides a large part of the attack surface. A dependency is a trust decision, and trust decisions belong in the architecture.
Treat a dependency like a service you call
When a team adds a third-party API, it usually asks sensible questions: who operates it, what data does it see, what happens if it fails or turns hostile? The same questions apply to a package pulled in at build time, and often with higher stakes, because that code runs with the full privileges of your application.
A useful habit in threat modeling is to draw the build and the dependency graph as part of the system, with their own trust boundaries. Suddenly the questions become concrete: who can publish a new version of this package, and would we notice?
Know what you ship
You cannot defend what you cannot list. A software bill of materials (SBOM), generated automatically on every build, turns "are we affected?" from a week of searching into a query. It is also increasingly what regulators and customers ask for.
The SBOM only helps if it is produced by the pipeline itself and stored with the release, so that it describes what actually shipped rather than what someone believes shipped.
Make the build trustworthy
Attacks on the supply chain often target the path between source code and artifact rather than the code itself. A few practices close most of that gap:
- Pin and lock. Lockfiles and pinned versions, including for CI actions and base images, so that a build is reproducible and an upstream change is a deliberate decision.
- Isolate the build. Ephemeral, least-privilege build environments with no long-lived secrets lying around.
- Sign and attest. Sign artifacts and record provenance, so that what is deployed can be traced back to a specific commit and build. Frameworks such as SLSA give a useful maturity ladder here.
- Verify on deploy. Only accept artifacts whose signature and provenance check out.
Decide how you take updates
Never updating is a risk; updating everything blindly is another. Agree on a policy: how quickly security fixes are adopted, who reviews major version changes, and which packages are critical enough to warrant a closer look. Automated update tooling works best when the review rules are explicit.
Start small
Pick one critical service. Generate its SBOM, pin its build inputs, and sign its artifacts. Then write down what you learned and turn it into a paved road for the next team. Supply chain security scales the same way everything else in security does: as a default, not as an audit.