Supply chain security is a system, not a scanner
A modern application is assembled from authored source, open-source packages, package indexes, build tools, CI actions, runner images, compiler and container inputs, registries, deployment systems, and identities. A team can scan its source and still ship a substituted artifact. It can sign an image and still trust the wrong signer. It can publish an SBOM that describes source manifests while omitting packages installed in the final image. It can use OIDC and still grant every workflow the same cloud role.
The practical goal is therefore not “turn on supply chain security.” The goal is a chain of independently testable decisions. Which source revision was approved? Which dependencies and sources were resolved? What executed the build? Which identity authorized publication? What exact digest was produced? What components are in those bytes? Which provenance claims are trusted? Did the deployment verify the same digest? Who can identify consumers if a package, builder, or signing identity is compromised?
The five-phase software supply chain roadmap organizes those decisions into threat and dependency trust, SBOM and vulnerability intelligence, signing and provenance, hardened CI and deployment, and governance and response. There is no passing score. Competence is demonstrated by building the controls, injecting safe failures, explaining what each signal proves, and retaining evidence another engineer can verify.
Start with threats and trust boundaries
SLSA provides a structured way to think about supply chain threats and increasing guarantees. Begin by drawing the full path: contributor and source control, dependency manifests and lock files, package sources, workflow definitions, reusable actions, runner or builder, OIDC provider, artifact registry, attestation store, deployment gate, runtime environment, and downstream consumer. Then ask how an attacker could modify content or obtain authority at every boundary.
Source compromise includes stolen contributor access, bypassed review, dangerous workflow patterns, or a changed release configuration. Dependency compromise includes typosquatting, dependency confusion, a malicious maintainer, a compromised maintainer account, a vulnerable transitive package, or a package whose ownership changed. Build compromise includes persistent runners, mutable tools, undeclared network downloads, excessive tokens, or one tenant influencing another. Distribution compromise includes overwritten tags, stolen registry credentials, altered metadata, or deploying an unverified digest.
A threat model should identify the security property and evidence for each mitigation. Branch protection supplies a review boundary, not package provenance. A lock file constrains resolution, not maintainer behavior. A signature authenticates content under a trust policy, not vulnerability absence. Provenance describes a build, but a consumer must verify the exact subject and authorize its builder and source claims. Clear semantics prevent teams from expecting one control to answer every question.
Make dependency intake and renovation routine
OpenSSF Scorecard assesses open-source projects with automated checks that span maintenance, source risk, dependencies, testing, and build practices. Relevant checks include dangerous workflows, branch protection, code review, token permissions, pinned dependencies, dependency update tools, vulnerabilities, packaging, and signed releases. The aggregate score is a useful orientation signal, but it is not a certificate of safety. Review individual check results, remediation guidance, requested privileges, project criticality, and the organization's use case.
Dependency identity includes its source. Configure approved registries, explicit namespaces or source mappings, authentication, integrity records, and fail-closed behavior for unexpected sources. This reduces dependency-confusion risk, where a public package can win resolution over an intended internal component. Pin resolved versions through the package ecosystem's supported lock or integrity mechanism. Review lock-file changes because one direct update may alter several transitive packages.
Pinning must be paired with renovation. Dependabot version updates can propose newer releases, while security updates address known vulnerable dependencies. Small, frequent pull requests are easier to inspect than an annual upgrade wave. Require tests, dependency review, license policy, release-note review, and relevant security checks. Record why a dependency exists, who owns it, what privileges it receives, and how it can be replaced or removed if maintenance stops.
GitHub dependency review shows added, removed, and updated direct and transitive dependencies in a pull request and can fail a required check when policy conditions are met. This is preventive evidence. Alerts on the existing graph are detective evidence. Use both: prevent known risky additions while continuously discovering new advisories for components already shipped.
Build SBOMs that support real response
An SBOM is a structured inventory of components and relationships for a defined software subject. SPDX is an international open standard, ISO/IEC 5962, with current and earlier specification versions. CycloneDX provides a modular object model for components, services, dependencies, compositions, vulnerabilities, formulation, declarations, and other transparency use cases. Format selection should follow consumer interoperability, ecosystem tooling, policy needs, and supported validation—not a claim that one format eliminates every supply chain problem.
Generation point matters. A source-manifest SBOM can describe intended application dependencies but miss packages introduced by the build, base image, operating-system package manager, or packaging step. Generate from the final artifact or reconcile trustworthy source, build, and artifact inventories. Record the specification version, generator, root subject, component identifiers such as package URLs where available, versions, hashes, dependency relationships, and completeness status.
An SBOM file beside an image is not automatically about that image. Bind it to the immutable artifact digest through an authenticated attestation or equivalent trusted association. Validate syntax and schema, then perform semantic checks: expected root component, plausible identifiers, direct and transitive relationships, generation time, freshness, and known limitations. Missing or stale evidence should be an explicit policy state rather than silently treated as pass.
SBOMs accelerate vulnerability response when connected to deployments and consumers. A vulnerability match still requires triage: confirm component and version, assess exposure and exploitability, identify fixed versions or compensating controls, assign an owner and deadline, and document any temporary exception. Because exploit information changes, suppressions must be reviewable and expiring.
Understand signing and keyless identity
A digest such as SHA-256 identifies exact content. A tag such as stable or latest is a mutable pointer. Release systems can offer friendly tags for discovery, but security decisions should resolve the candidate to a digest and keep that digest through verification and deployment.
Cosign supports signing container images and blobs. With keyless signing, an ephemeral key is associated with an identity from an OpenID Connect provider. This avoids asking the release team to store and rotate a long-lived private signing key. It does not remove trust policy. Verification must constrain the expected certificate identity or identity pattern and OIDC issuer, validate the signature and subject digest, and apply any required transparency-log or bundle checks.
Accepting any valid keyless certificate is a serious policy error. An unrelated developer could obtain a legitimate certificate for an unrelated identity. The gate must express which protected workflow, repository, ref, environment, or organization is authorized. Identity authentication and artifact authorization are distinct steps.
Signatures also have limited semantics. A successful verification can establish that accepted identity signed the content and that the content has not changed. It does not establish that the artifact is vulnerability-free, that every dependency is licensed for the use, that the build was isolated, or that the source revision was reviewed. Those properties require separate evidence and policy.
Use attestations and SLSA provenance correctly
An attestation is an authenticated statement with a predicate about a subject. The subject should identify the artifact digest. The predicate may carry build provenance, an SBOM, a vulnerability result, or another defined claim. Cryptographic verification establishes statement integrity and signer authentication. Authorization then checks whether the predicate type and values satisfy policy.
SLSA organizes supply chain security into tracks and increasing levels. Build provenance can describe the artifact subject, builder, source repository and revision, build process, and relevant inputs. A consumer should validate the trust chain or signature, confirm that the provenance subject equals the candidate digest, require an approved builder and source, and evaluate any expected workflow or parameter claims. A valid attestation about the wrong digest, from an unapproved builder, or using an irrelevant predicate must fail.
GitHub artifact attestations can establish build provenance for binaries and container images. Its documentation requires appropriate workflow permissions and supports subject paths for files or fully qualified image names with SHA-256 subject digests for containers. GitHub CLI can verify binary and OCI attestations against a repository. Feature availability varies by repository visibility and plan, so validate current eligibility rather than assuming every private repository has the same capability.
Reproducible builds provide complementary evidence. Independent builds from equivalent declared inputs should produce identical output. A mismatch can expose timestamps, locale, file ordering, network content, tool versions, or other hidden inputs. Reproducibility can improve confidence and auditability, but it does not prove that the source is trustworthy or that the original builder was authorized. Preserve both reproducibility results and provenance.
Harden CI identity and the build environment
CI workflows execute code with credentials, network access, and publication authority. Set default workflow permissions to read-only or none and grant job-level permissions only where required. A release job may need source read, package write, attestation write, and OIDC token issuance. A pull-request test job usually needs far less. Keep untrusted fork code out of release, signing, and protected environment contexts.
OIDC federation replaces a stored cloud key with short-lived credentials, but the relying party must validate claims. Constrain issuer, audience, repository or organization, protected branch or environment, and other stable claims appropriate to the platform. The resulting cloud or registry role should be least privilege. An OIDC token that can assume an administrator role from any workflow is not a secure improvement.
Review third-party actions and pin them to full commit SHAs. Keep the human-readable version in a comment and use automated updates to propose reviewed pin changes. Pin compilers, package inputs, base images, and build tools through supported immutable identifiers. Broad mutable references weaken the connection between reviewed configuration and executed code.
Use clean ephemeral build environments. They should begin from controlled images, receive declared inputs, have only necessary credentials, limit network access where feasible, and be destroyed after the build. Long-lived shared runners can retain workspaces, processes, credentials, or modifications between jobs. A cleanup script on a mutable host is a weaker boundary than replacing the environment.
Verify before deployment, not only after publication
Production-like admission should be independent from release production. Resolve the candidate tag to a digest. Verify the signature against the expected identity and issuer. Verify provenance authenticity, subject digest, builder, source repository, revision, and predicate type. Verify required SBOM and vulnerability policy. Evaluate any exception by exact scope and expiration. Then deploy the exact verified digest with a separate least-privilege identity.
This sequence resists time-of-check/time-of-use substitution. If a tag moves after verification, the deployment remains bound to the verified digest. If an attacker signs different content with another valid identity, identity policy rejects it. If provenance describes an unapproved repository or build path, claim policy rejects it. If evidence is missing or stale, the gate follows the documented fail-closed or explicitly governed behavior.
Registry controls support this design. Separate pull, publish, promote, quarantine, and delete roles. Restrict tag mutation in release channels where the registry permits it. Retain audit logs and evidence according to policy. Discover orphan artifacts that have no owner or source link. A publishing workflow should not automatically have power to delete audit evidence, promote to every environment, and change registry administration.
Scale with policy, exceptions, and useful metrics
NIST SP 800-218, the Secure Software Development Framework, organizes practices around preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. It is a strong structure for mapping outcomes, owners, and evidence without requiring one specific tool. CISA secure software guidance reinforces secure-by-design responsibility and attestation expectations in relevant contexts.
Policy should be explicit and tested. Each rule needs an identifier, scope, criticality tier, required evidence, data-quality behavior, result, remediation, and owner. Create fixtures for pass, fail, missing, stale, malformed, contradictory, and temporarily unavailable inputs. Start in report mode, measure impact and false positives, communicate changes, then move high-confidence controls through warning to enforcement.
Exceptions are part of governance, not an embarrassment to hide. A sound exception records the exact rule and artifact or dependency scope, business justification, risk assessment, compensating controls, accountable owner, approver, evidence, remediation plan, expiration, and earlier review triggers. A change in digest, version, exposure, exploit status, or owner may invalidate it before the date. Expired exceptions should fail closed or return to review.
Measure outcomes rather than dashboard volume. Useful measures include the percentage of deployed artifacts verified by digest with accepted signature and provenance; SBOM coverage, completeness, and freshness; median dependency and vulnerability remediation age; overdue and expiring exceptions; unknown owners or sources; orphan artifacts; and incident time to detect, scope, contain, notify, rebuild, and verify recovery. Segment by criticality and use metrics to direct help, not to encourage teams to game one score.
Prepare for dependency and builder incidents
When a dependency is compromised, responders need more than a repository search. Query component identifiers and versions across SBOMs, map affected artifact digests to registries and deployments, identify owners and consumers, and distinguish built, published, deployed, and retired states. Quarantine or block affected digests, assess exploitability, identify safe versions, rebuild, re-sign, re-attest, and communicate verification instructions.
A signing or builder compromise requires identity-centered scoping. Preserve workflow logs, OIDC and registry audit events, attestations, bundles, source revisions, and policy decisions. Contain publication before deleting evidence. Identify affected identities, time range, runs, artifact digests, environments, and consumers. Revoke or restrict credentials and trust policies, block suspect artifacts, and rebuild through a known-good source and trusted builder.
Secret response starts with invalidation, not with editing the latest commit. Assess whether the secret entered history, logs, caches, artifacts, forks, or package output. Rotate affected credentials, remove exposure where appropriate, preserve the response timeline, and add prevention such as push protection, least privilege, short-lived identity, and secret-free fixtures. In the project, the seeded token must be visibly documented as nonfunctional while the response procedure remains realistic.
Recovery is complete only after consumers can verify the replacement. Publish new digests and evidence, document which artifacts are untrusted, explain removal or quarantine actions, and confirm deployment systems enforce the corrected policy. Capture lessons about inventory gaps, slow approvals, missing logs, and unclear ownership, then update controls and exercises.
Two projects that produce credible evidence
Project 1: hardened CI release with verifiable deployment
The first software supply chain project begins with an invented CLI package and container. The repository protects source, lock, workflow, and policy changes. Dependency review and Scorecard checks expose risk. An ephemeral release job uses minimal permissions and constrained OIDC, builds once, calculates the digest, generates and validates an SPDX or CycloneDX SBOM, produces SLSA-compatible provenance or a supported GitHub attestation, and signs keylessly with Cosign.
A separate verifier resolves the image to a digest, checks signer identity and issuer, verifies provenance subject and claims, evaluates SBOM and vulnerability policy, and deploys only that digest. Failure injection covers a moved tag, altered artifact, wrong signer, wrong issuer, unapproved builder, missing SBOM, malformed provenance, seeded vulnerability, and expired exception. The final evidence packet includes architecture, permission diff, dependency review, Scorecard remediation, digest, SBOM validation, verification output, failure matrix, cost estimate, and cleanup proof.
Project 2: organization supply chain governance baseline
The second project creates twelve synthetic repositories owned by four invented teams. A central inventory maps criticality, dependencies, workflows, registries, artifacts, deployments, consumers, and owners. Scorecard supplies check-level signals. Dependency policy covers approved sources, locks, review, updates, vulnerabilities, licenses, abandoned projects, and removal. Registry policy separates publish, promote, quarantine, and delete responsibilities and requires digest-linked evidence for critical artifacts.
Policy fixtures test missing and malformed evidence before staged enforcement. The exception register requires exact scope and expiry. Four exercises simulate a malicious transitive package advisory, nonfunctional leaked token, moved tag, and compromised builder identity. The team measures time to identify affected consumers, contain release authority, quarantine digests, rebuild trusted replacements, and verify recovery. Cleanup removes every synthetic repository, role, token, package, image, webhook, and retained raw artifact beyond policy.
A ten-week implementation plan
- Week 1: Draw artifact lifecycles and SLSA-inspired threat models. Define trust boundaries, assets, attackers, evidence, and fail-closed decisions.
- Week 2: Evaluate dependencies with Scorecard check details, approved sources, lock files, dependency review, and automated renovation.
- Week 3: Generate SPDX and CycloneDX documents from a synthetic source and final artifact. Compare scope, relationships, identifiers, and completeness.
- Week 4: Link SBOM subjects to digests and exercise vulnerability and fake-secret triage, ownership, deadlines, and response evidence.
- Week 5: Learn Cosign keyless signing and verification. Test correct and incorrect identity, issuer, digest, and bundle conditions.
- Week 6: Produce and verify SLSA-compatible provenance or supported artifact attestations. Compare independent rebuilds.
- Week 7: Harden CI permissions, OIDC claim trust, action pins, dependency inputs, and untrusted-code separation.
- Week 8: Use ephemeral builds, role-separated registry controls, and an independent digest-bound deployment gate.
- Week 9: Map NIST SSDF outcomes, test policy rules, stage enforcement, and implement exact expiring exceptions.
- Week 10: Run compromise exercises, measure response, complete original knowledge checks, package sanitized evidence, estimate cost, and verify cleanup.
Common mistakes to avoid
- Treating a Scorecard number as certification. Investigate check-level risk and context.
- Pinning forever. Pair reproducible resolution with frequent reviewed updates.
- Trusting package names without sources. Constrain registries, namespaces, authentication, and integrity.
- Calling a source manifest a complete final SBOM. Generate or reconcile against shipped bytes and declare limitations.
- Accepting any valid signature. Require expected identity, issuer, digest, and relevant claims.
- Verifying a tag and deploying it later. Resolve and carry one immutable digest.
- Generating provenance without consuming it. Enforce builder, source, revision, predicate, and subject policy at deployment.
- Using OIDC with a broad trust rule. Constrain claims and resulting role permissions.
- Running releases on persistent shared runners. Prefer clean ephemeral isolated builders.
- Making every scanner finding an opaque block. Test risk-based policy and provide governed exceptions.
- Keeping exceptions forever. Require expiry and earlier review triggers.
- Collecting evidence without ownership and consumers. Incident response needs digest-to-deployment traceability.
Present the work honestly
A credible portfolio can be entirely synthetic. Publish a sanitized architecture, threat model, policy table, dependency and Scorecard findings, workflow permission analysis, SBOM validation, digest, signature and provenance verification, failed negative tests, exception example, incident timeline, cost assumptions, and cleanup record. Explain what each evidence type proves and does not prove.
Do not claim that a lab achieved an organization-wide SLSA level, regulatory compliance, or production assurance unless it was independently assessed under the applicable requirements. State the selected tools, specification versions, plan limitations, test scope, and remaining risks. A strong demonstration is precise about boundaries and failure evidence.
These skills support DevSecOps, product security, application security, platform engineering, release engineering, cloud security, and security architecture work. Explore role language on the PrepKloud jobs page, but treat job requirements and compensation as employer-specific. Completing this path does not guarantee employment, certification, or security outcomes.
Official and authoritative references
- OpenSSF Scorecard
- OpenSSF Scorecard check documentation
- OpenSSF Best Practices Working Group guidance
- SLSA specification version 1.2
- SLSA: verifying artifacts
- Cosign: signing containers
- Cosign: verifying signatures and identity
- SPDX specifications
- CycloneDX specification overview
- GitHub artifact attestations
- GitHub dependency review
- GitHub Dependabot version updates
- GitHub Actions security hardening
- NIST SP 800-218 Secure Software Development Framework
- CISA Secure by Design
- CISA software bill of materials resources
Continue the practical path
- Software Supply Chain Security five-phase roadmap
- Software supply chain knowledge checks
- Software supply chain flashcards
- Software supply chain hands-on projects
- DevOps for AI Applications
- Infrastructure as Code for Beginners
- Cloud Lab Cost Control
- Explore related roles
- PrepKloud editorial policy
Frequently asked questions
Is software supply chain security a certification?
This PrepKloud resource is not a certification. It is an independent practical skill path with original knowledge checks and synthetic projects, not an exam, credential, blueprint, passing score, or guarantee.
Is an SBOM enough to secure a release?
No. An SBOM inventories components and relationships. Secure releases also need trusted source and dependency controls, immutable artifact identity, signatures or attestations, provenance verification, deployment policy, and response capability.
What is keyless signing?
Sigstore keyless signing uses an ephemeral signing key associated with an OIDC identity. Consumers still verify the exact digest, expected certificate identity or pattern, accepted issuer, and required claims.
What is the difference between signing and provenance?
A signature authenticates content under a trust policy. Provenance is an attested set of claims about where and how an artifact was built. Verify and authorize both against the same exact artifact digest.
How can this path be practiced safely?
Use an invented package, disposable repository and registry, nonfunctional token-shaped test string, least-privilege identities, short retention, and complete cleanup. Never use production secrets, proprietary source, customer data, or unauthorized systems.