HomeRoadmaps › Software supply chain security
High-demand practical skill path — not a certification

Software Supply Chain Security Roadmap

Build trust from dependency intake to deployment: inventory components, harden CI identity and builders, sign and attest immutable artifacts, verify provenance, govern exceptions, and respond to compromised packages or release paths.

5 practical phasesSuggested pace: 8-10 weeks25 original knowledge checks2 evidence-rich projects
This is a practical skill path, not certification training. It has no exam provider, blueprint, passing score, credential, or job guarantee. Progress is demonstrated by building controls, breaking them safely, verifying exact artifact digests, and producing reviewable evidence. The path uses authoritative OpenSSF, SLSA, Sigstore, SPDX, CycloneDX, GitHub, NIST, and CISA guidance—not marketplace questions.

What the path develops

Software supply chain security is a connected system rather than one scanner. The learning goal is to explain and implement how source, dependencies, identities, runners, artifacts, metadata, registries, deployment gates, exceptions, and incident response reinforce one another.

Threats and intakeAttack paths, maintainer risk, source identity, dependency pinning, Scorecard, review.
Inventory and triageSPDX, CycloneDX, SBOM scope, completeness, vulnerabilities, secrets, consumers.
Artifact trustDigests, signatures, keyless identity, attestations, SLSA provenance, reproducibility.
Hardened deliveryOIDC, least privilege, workflow pins, isolated builds, registry controls, verification.
Governance and responsePolicy gates, exceptions, evidence, metrics, containment, rebuild, notification.
1

Threat models and dependency trust

Weeks 1-2

Begin with the artifact lifecycle and make trust decisions explicit before adding tools.

  • Trace source, maintainer, package source, build, registry, deployment, and consumer boundaries
  • Model source compromise, malicious packages, dependency confusion, stolen identity, and artifact substitution
  • Evaluate dependencies with OpenSSF Scorecard check details and use-case context
  • Require approved registries, namespaces, lock or integrity files, ownership, and purpose
  • Review direct and transitive dependency changes on every pull request
  • Use Dependabot or equivalent renovation for small, frequent, reviewable updates
  • Assess maintenance, security policy, release practices, licenses, vulnerabilities, and removal options
  • Protect source, workflow, lock, ownership, and policy changes with review and status checks
2

SBOMs, vulnerability intelligence, and secrets

Weeks 3-4

Build an artifact and component inventory that responders can actually use.

  • Understand SPDX as an international open standard and CycloneDX as an extensible BOM model
  • Select a format and version based on consumer interoperability rather than branding
  • Generate against the final artifact or reconcile source, build, and image inventories
  • Record root subject, hashes, identifiers, dependency relationships, generator, and completeness
  • Bind or attest each SBOM to an immutable artifact digest
  • Validate syntax, schema, expected components, freshness, and data-quality status
  • Triage vulnerability matches with version confirmation, exposure, exploitability, fixes, owner, and deadline
  • Exercise secret detection, invalidation, impact assessment, rotation, cleanup, and prevention with a fake token
3

Signing, attestations, provenance, and reproducibility

Weeks 5-6

Learn what each kind of evidence proves, then bind it to the exact artifact consumers receive.

  • Use SHA-256 digests as immutable artifact identity and treat tags as mutable pointers
  • Distinguish signature integrity and signer authentication from vulnerability or quality claims
  • Sign with Cosign keyless identity using an approved OIDC release context
  • Verify certificate identity or pattern, OIDC issuer, claims, transparency or bundle evidence, and digest
  • Understand attestations as authenticated predicates about named subjects
  • Produce and verify SLSA provenance for source, revision, builder, workflow, and build inputs
  • Authorize predicate type and claim values rather than accepting any valid attestation
  • Build independently, compare digests, and remove hidden timestamps, ordering, network, and tool inputs
4

Harden CI, builders, registries, and deployment

Weeks 7-8

Separate the identity that produces evidence from the identity that verifies and deploys it.

  • Set workflow permissions to read-only or none and grant narrow job-level capabilities
  • Constrain OIDC issuer, audience, repository, protected ref or environment, and cloud role
  • Keep untrusted pull-request code out of privileged release and signing contexts
  • Pin reviewed actions, tools, base images, and package inputs to immutable identifiers
  • Use ephemeral isolated builders with declared inputs, controlled networks, and verified destruction
  • Separate registry pull, publish, promote, quarantine, and delete roles
  • Require SBOM, provenance, signature identity, scans, and approved exceptions for promotion
  • Resolve, verify, authorize, and deploy one exact digest through an independent gate
5

Governance, exceptions, evidence, and incident response

Weeks 9-10

Scale controls through transparent policy and prove the organization can contain and recover from compromise.

  • Map outcomes and evidence to NIST SSDF Prepare, Protect, Produce, and Respond practices
  • Use criticality tiers and distinguish fail, missing, stale, malformed, and unavailable evidence
  • Roll policy from report to warning to enforcement with tests, owners, and rollback
  • Require exceptions to name exact scope, rationale, controls, owner, approver, evidence, and expiry
  • Link artifact digests to source, builder, SBOM, provenance, registry, deployments, consumers, and owners
  • Exercise compromised dependency, leaked secret, moved tag, and compromised builder scenarios
  • Measure verified-release coverage, remediation age, SBOM freshness, exception health, and response time
  • Contain publishing, preserve evidence, scope digests, notify consumers, rebuild trusted artifacts, and verify recovery

PrepKloud learning surfaces

Official and authoritative sources

OpenSSF Scorecard and best practices

Use automated project risk signals, check-level remediation, secure development guides, and source-control practices.

Open Scorecard
Open best practices
SLSA specification

Study threats, build and source tracks, levels, attestations, provenance, builder assessment, and artifact verification.

Open SLSA v1.2
Sigstore and Cosign

Follow current keyless signing, bundle, identity, issuer, signature, attestation, registry, and verification guidance.

Open Cosign docs
SPDX and CycloneDX

Review current specification versions, object models, supported encodings, identifiers, dependency graphs, completeness, and validation.

Open SPDX
Open CycloneDX
GitHub supply chain documentation

Use artifact attestations, dependency review, Dependabot, OIDC, workflow hardening, vulnerability scanning, and secret scanning documentation.

Open GitHub docs
NIST SSDF and CISA

Map practical controls to secure development outcomes and current government secure-software and Secure by Design guidance.

Open NIST SSDF
Open CISA Secure by Design

Frequently asked questions

Is this software supply chain path a certification?

No. It is an independent practical skill path with original knowledge checks and synthetic projects. It has no exam provider, blueprint, passing score, credential, or guarantee.

Do I need a production registry or real secret?

No. Use a disposable registry namespace, harmless synthetic package, and documented nonfunctional token-shaped string. The projects are designed to practice realistic response without production code, data, or credentials.

What is the difference between an SBOM and provenance?

An SBOM inventories components and relationships for a software subject. Provenance describes where and how an artifact was produced. Bind both to an immutable digest and verify each for its intended claim.

Does keyless signing mean identity checks are unnecessary?

No. Keyless signing removes management of a long-lived signer key, but the verifier must still constrain certificate identity and OIDC issuer, check the artifact digest, and authorize required claims.

What projects are included?

The first builds a hardened CI release with final-artifact SBOM, provenance, keyless signing, and deploy-time verification. The second creates an organization baseline for Scorecard, dependencies, registry controls, exceptions, metrics, and incident exercises.

Editorial and safety note: PrepKloud is independent. This roadmap is original educational content grounded in the linked official and authoritative sources. It contains no marketplace copying, certification claim, legal assurance, security guarantee, or job guarantee. Use only synthetic packages and secrets in labs, verify current tool versions and feature eligibility, follow service terms, and obtain authorization before testing any organization system.

Make every release explain its origin

Practice the judgment, build both projects, inject failures safely, and retain evidence that another engineer can verify.