Software Supply Chain Security Basics

Map the delivery chain

Inventory source hosts, review rules, package registries, dependency sources, build runners, container bases, artifact stores, signing services, deployment controllers, and update channels. Record owners, trust boundaries, administrative roles, network access, secrets, and what evidence each stage produces. Include scripts downloaded during builds and third-party actions.

Identify the assets an unauthorized change could affect: source integrity, customer packages, production credentials, developer machines, and update trust. Separate systems the organization owns from external services. Testing or scanning third-party infrastructure requires permission; evaluate external providers through contracts, attestations, published guidance, and supported controls instead of probing them.

Protect source and dependencies

Require individual strong authentication, reviewed changes, protected branches or equivalent rules, and limited repository administration. Separate code approval from changes to those approval rules. Monitor new maintainers, workflow edits, secret access, and release-tag changes. Keep recovery contacts and repository backups appropriate to business needs.

Use lockfiles or resolved manifests, approved registries, and an inventory of direct and transitive components. Review new dependencies for maintenance, source, privilege, license, and necessity. Automated alerts help identify known issues, but they do not prove a package is trustworthy or that an application reaches the affected behavior.

Harden builds and artifacts

Use isolated, short-lived build workers with minimal network and secret access. Separate untrusted contribution checks from release jobs. Pin build tools and external workflow components to reviewed versions where supported. Prevent ordinary build scripts from reading production credentials, modifying delivery policy, or publishing directly without approval.

Store artifacts in a controlled registry, protect them from replacement, and attach verifiable build and source information. Signing can support authenticity only when keys, identities, and verification policy are protected. Consumers should verify the expected producer and artifact before deployment rather than merely checking that some signature exists.

Release and recover deliberately

Promote the same tested artifact through environments rather than rebuilding from changing inputs. Require approval based on test, vulnerability, provenance, and policy evidence. Limit deployment identities to intended services and environments. Preserve previous trusted artifacts and configuration so rollback is possible without granting broad emergency access.

Prepare to stop publication, revoke credentials or signing authority, identify affected versions, rebuild from a trusted point, and communicate verified impact. Exercise this process with synthetic packages in owned systems. Review delivery identities, external actions, dependencies, provenance, backups, exceptions, and current OWASP guidance quarterly and after significant incidents.

Secure a container release pipeline

A team builds an owned web service from a protected repository and deploys container images to production.

1. Map repository, dependency registry, build runner, base image, artifact registry, signer, and deployment controller identities.
2. Require reviewed source and workflow changes, resolved dependencies, and an isolated release worker without production shell access.
3. Publish one immutable artifact with source and build provenance to a protected registry through a narrow identity.
4. Verify policy, tests, provenance, and expected producer before a separate deployment identity promotes that artifact.
5. Retain the prior trusted image, test rollback and credential revocation in staging, and document escalation.

Supply-chain control map

Use this map for each release path from source to production.

• Stage inventory: source, dependency, build, artifact, signing, deployment, update, owner, and boundary.
• Identity controls: authentication, administration, least privilege, secret access, separation, and emergency use.
• Integrity evidence: review, resolved inputs, tests, scan results, provenance, signature policy, and immutable artifact.
• Release gate: expected producer, approved environment, deployment scope, authorization, and retained rollback version.
• Response: publication stop, revocation, affected-version search, clean rebuild, backup, communication, and quarterly drill.

Common mistakes

• Protecting application source while allowing one unreviewed workflow file to read secrets and publish releases.
• Assuming a lockfile or signature alone establishes that dependencies and artifacts are safe.
• Rebuilding during rollback from current external inputs instead of retaining the exact previously trusted artifact.

Try one

Sources

• OWASP Software Supply Chain Security Cheat SheetOWASP controls for source, build, dependency, and release integrity.
• CISA Secure by DesignCISA guidance for making customer security a core product requirement.