A plan for software supply chain security: 8 controls beyond scanning

A practical approach to software supply chain security protects the path from source code and third-party components to the software a business runs. It covers who can change code, which dependencies enter a build, how the build works, and whether deployment uses the intended artifact. A vulnerability scanner covers only part of that path.

A team can fix known package flaws and still leave weak build credentials or an unverified release process. Therefore, controls need to connect across development, building, distribution, and deployment.

This article explains eight practical controls, what evidence to ask suppliers for, and how to introduce the work without blocking every release. It also separates inventories, signatures, and provenance so teams can use each for the right purpose.

Map the path your software takes

Start with one important application. List its source repositories, package registries, build workers, artifact stores, deployment systems, and external services. Include the people and service accounts that can change each stage.

Next, identify trust boundaries. Downloading a package from a registry, accepting a pull request, and promoting an image to production all cross boundaries. Each needs a rule for what the receiving system will trust.

The NIST Secure Software Development Framework, version 1.1 provides high-level secure development practices that teams can integrate into their delivery process. Use it to organize responsibilities rather than treating security as one final scan.

Keep the first map small enough to verify. A real view of one production path gives the team more useful evidence than a broad diagram based on assumptions.

1. Protect source changes and privileged identities

Code repositories are a starting point for many supply chain risks. Control who can merge changes, alter repository settings, and modify the pipeline that produces releases.

Use individual identities and suitable authentication. Then review access when people change roles or leave. Shared administrator accounts make both prevention and investigation harder.

Protect important branches with review and required checks that fit the project. Also review pipeline definition changes. A small edit to a build workflow can change what code runs or where credentials go.

Pay special attention to automation accounts. A bot that updates dependencies may need to open a change request but not approve and merge its own work. Keep permissions tied to the task.

Finally, preserve useful audit records. Staff should be able to trace a release back to the source revision, review, and workflow configuration involved. This creates a basis for later verification.

2. Control dependencies before they enter the build

Third-party packages save development time, but they add code and maintainers to your trust model. Track direct dependencies and the indirect packages they bring with them.

Use lockfiles or an equivalent mechanism where the ecosystem supports them. They help keep builds consistent by recording resolved versions. However, a locked version can still contain a flaw or malicious behavior.

Next, define where packages may come from. Private package names and public registries need clear resolution rules. Otherwise, a build may fetch an unintended package with a matching or similar name.

Review unusual changes in package ownership, install behavior, and dependency structure. A scanner’s lack of findings is not proof that a package is safe. New malicious behavior may not yet have a known advisory.

Updates still matter. Avoid freezing dependencies indefinitely out of fear of change. Use a controlled update process with tests, review, and a clear route to handle urgent fixes.

3. Generate a useful software inventory

A software bill of materials, or SBOM, records components in an application or artifact. It can help teams answer whether a vulnerable component appears in a release.

However, an SBOM needs context. Link it to the exact artifact version, generation method, and relevant identifiers. An inventory of a developer’s working directory may not describe what the production build actually contains.

Also consider completeness. Different tools can detect different component types. Ask what the generator includes, what it misses, and how the team validates the output.

Oxen’s SBOM practices guide explores inventory work in more detail. In the wider security program, treat the SBOM as evidence that supports investigation and policy, rather than a guarantee of safety.

Store inventories where incident responders can find them. A detailed SBOM has limited value if staff cannot match it to the release currently running in a customer environment.

4. Harden and isolate the build environment

A build system turns source and dependencies into a release artifact. If an attacker changes that system, they may affect the result without making an obvious change to application code.

Limit what build jobs can access. Separate untrusted contribution checks from jobs that receive release credentials. A test triggered by an external change should not automatically gain the ability to publish a production artifact.

Use clean, controlled environments where practical. Long-lived workers can accumulate files, credentials, or configuration that make builds harder to explain. Record the toolchain and inputs needed to reproduce the process.

Also restrict unnecessary network access during sensitive build stages where feasible. This reduces unexpected dependencies and makes the process easier to observe. Apply controls based on the workflow rather than assuming one policy fits every job.

Finally, protect build settings as carefully as source code. Changes to base images, runner permissions, and release scripts can alter the trustworthiness of the output.

5. Create and verify build provenance

Provenance describes where an artifact came from and how a build produced it. It can connect the output to source inputs and the build process. That differs from an SBOM, which describes components.

The SLSA version 1.2 specification describes tracks, levels, and attestation formats for improving supply chain security. It gives teams a structured way to discuss the properties of source and build systems.

Start with a verification question: What must the deployment system know before it accepts this artifact? The answer may include the trusted builder, source repository, revision, and expected workflow.

Then test the policy. Submit an artifact with missing or mismatched provenance and confirm the response. Producing evidence without checking it leaves a gap between the build and deployment stages.

Keep claims precise. A supplier saying “we use SLSA” is less useful than a clear statement of the version, track, level, scope, and evidence that applies to a particular release path.

6. Verify artifacts at the point of use

A signature can help establish that an artifact has not changed and that a trusted identity signed it, subject to the verification model. It does not prove that the software lacks vulnerabilities or harmful behavior.

Therefore, define trust rules around the signature. The receiving system needs to know which identity it accepts, what artifact the signature covers, and what to do if verification fails.

Prefer immutable identifiers for release selection where practical. A mutable tag can later point to a different image. A digest identifies specific content, which makes promotion and incident investigation clearer.

Protect artifact stores and publishing credentials. Restrict overwrite and deletion rights, record promotion events, and separate test output from approved releases. A secure build loses value if someone can replace its result afterward.

Also test a validly signed but unapproved artifact. The system should check both integrity and release policy. These are related questions, but they are not the same question.

7. Keep release access narrow and observable

Deployment systems often hold powerful access. Limit the environments each identity can reach and use short-lived credentials where the platform supports them.

Separate building an artifact from approving its production use. The exact workflow depends on the team, but the record should make responsibility and the selected version clear.

Next, include security tests at suitable points in delivery. Oxen’s application security testing guide explains how checks can fit into the release process. Supply chain controls complement those tests by protecting the path that produces and ships the software.

Record deployment targets and versions. When a component issue appears, responders need to know where affected artifacts run, not only which builds contain them.

Keep emergency release routes controlled too. A break-glass process should record its use and receive review afterward. Otherwise, the exception path can become the normal way to bypass safeguards.

8. Prepare for component and build incidents

Incident response should cover more than patching a library. A compromised publisher, stolen build credential, or altered artifact may require different containment steps.

Define who can pause releases, revoke credentials, block an artifact, and contact affected customers. Keep the plan accessible even if a normal development service becomes unavailable.

Practice with a bounded scenario. For example, assume one package version is unsafe. Ask the team to identify affected artifacts, locate deployments, choose a replacement, and verify the fix.

Then try a build-system scenario. If the builder itself was untrusted for a period, an inventory of known vulnerable packages may not answer which releases are safe. The team may need to rebuild from trusted inputs and investigate the wider path.

Preserve evidence during recovery. Deleting suspicious workers immediately can remove useful context. Coordinate containment, logging, and investigation so the team restores service while retaining what it needs to understand the incident.

How to assess a software supply chain security platform

Map each product capability to a control and an owner. Dependency scanning, SBOM management, provenance verification, and policy enforcement solve different problems. A single platform may cover several, but test them separately.

Ask for evidence from your own sample application. Include a transitive dependency, a pipeline change, an unsigned artifact, and a policy exception. Review how the product explains a failure and routes repair work.

Also assess developer effort. If results are hard to interpret or exceptions take too long, people may work around the system. Give teams clear failure messages and a documented review path.

For the underlying delivery structure, Oxen’s software configuration management controls can help connect source, versions, and release records.

Introduce controls in a workable order

Start by identifying critical release paths and closing obvious access gaps. Then establish component inventories and reliable artifact identities. Add build evidence and verification policies as the process becomes clearer.

Use an initial observation period for new policies where appropriate. Review what they would block, fix incorrect assumptions, and assign owners. However, keep a defined date and criteria for moving useful policies into enforcement.

Track outcomes such as covered release paths, unresolved exceptions, and time to locate affected deployments. Avoid treating the number of scans as the main measure of security.

Ask suppliers for specific release evidence

For purchased software, connect questions to the version you use. Ask how the supplier identifies components, protects its build path, handles vulnerability reports, and notifies customers of affected releases.

Also ask what evidence the supplier can provide and how you can verify it. A policy statement and an artifact-linked attestation serve different purposes. Choose the evidence that supports your risk review.

Finally, assign an internal owner for receiving advisories and locating affected deployments. Supplier information helps only when someone can turn it into a timely decision within your environment.

Protect the path, not just the package list

Effective software supply chain security connects code, components, builds, artifacts, and deployments. Start with a verified map of your delivery process, then prove that each control changes what the next stage will trust.