Software Supply-Chain Security, SBOMs, Signatures, Provenance, Trusted Agents, and Dependency Controls: Concepts, Architecture, and Mental Model

1. The practical problem: a green build is not a trustworthy origin story

Jenkins can orchestrate compilation, tests, packaging, signing and publication, but orchestration alone does not tell a consumer what bytes were built, which source revision produced them, which dependencies entered the build, where the build ran or who was allowed to sign the result. Supply-chain security adds verifiable evidence around those questions.

The key mental shift is from “the job succeeded” to “this exact subject digest was produced from this exact source under this builder identity, accompanied by this dependency inventory and this signed provenance, and the promotion policy verified those claims.”

2. The evidence chain

flowchart TD
  A["Trusted source SHA + Jenkinsfile/library refs"] --> B["Dependency resolution + lock state"]
  B --> C["Trusted isolated agent + pinned tool/image"]
  C --> D["Artifact bytes"]
  D --> E["SHA-256 digest"]
  D --> F["SBOM"]
  E --> G["Provenance subject"]
  F --> H["Policy inputs"]
  G --> I["Signature / attestation"]
  I --> H
  H --> J["Promotion decision"]
  J --> K["Repository / deployment evidence"]
  

Every arrow represents a claim that needs evidence. The source SHA identifies code, but not the resulting bytes. A digest identifies bytes, but not who produced them. An SBOM inventories components, but does not certify they are vulnerability-free. A signature authenticates a statement or artifact under a key or identity, but only a verifier that checks the expected identity and subject digest turns that signature into a useful policy decision. Provenance connects the subject digest to build inputs and builder context.

3. Five artifacts that are often confused

4. Keep the state layers separate

For this chapter, record at least these layers separately:

• Controller configuration: Jenkins core/Java/plugin baseline, credentials IDs and job definition.
• Build identity: item full name, build number/URL/cause, exact source SHA and Jenkinsfile/library refs.
• Execution identity: agent name/label, executor, workspace, base image or VM identity, OS/architecture, Syft/Cosign/tool versions.
• Dependency state: lockfile/checksum state and resolved dependency evidence.
• Artifact state: path, byte size and immutable SHA-256 digest.
• Supply-chain evidence: CycloneDX/SPDX SBOM, provenance predicate, signing identity/key fingerprint and verification output.
• External state: repository coordinates/promotion status and deployment consumer identity, if used.

Do not store a private signing key inside archived artifacts, stashes, build logs or an untrusted workspace. A signing agent or external signing service has a materially different trust boundary from an ordinary test agent.

5. Inspect before you mutate

Before adding signing or SBOM generation, capture what exists. These commands are read-only inside a disposable repository/agent workspace.

set -euo pipefail
printf 'source_sha='; git rev-parse HEAD
printf 'jenkinsfile_sha='; sha256sum Jenkinsfile 2>/dev/null || true
printf 'java='; java -version 2>&1 | head -1
printf 'syft='; syft version
printf 'cosign='; cosign version
printf 'os='; uname -a
find . -maxdepth 2 -type f -name '*lock*' -o -name 'pom.xml' -o -name 'package-lock.json' | sort

The point is not the command list; it is establishing the exact input and tool context before claims are created. If a later verifier cannot tie an SBOM or provenance statement to the artifact digest, the evidence packet is incomplete.

6. Trusted builder means more than “agent online”

An online Jenkins agent merely means the controller can communicate with it. A supply-chain trusted builder additionally needs a reviewed image/VM baseline, restricted who-can-schedule policy, controlled tool installation, bounded network/credential access, protected signing identity and reproducible evidence about the environment. Untrusted pull-request code must not be allowed to modify trusted library code, read signing material or execute on the same privileged signing pool by default.

7. SBOM is inventory, not a security verdict

Syft can emit CycloneDX or SPDX from a directory, archive, package or image. The output is valuable evidence because downstream tooling can identify package names, versions, relationships and identifiers. It is still a snapshot produced by a tool with known detection limits. Vulnerability scanning is a separate operation that consumes package inventory plus advisory data and policy.

mkdir -p evidence
syft dir:. -o cyclonedx-json=evidence/sbom.cdx.json
sha256sum evidence/sbom.cdx.json > evidence/sbom.cdx.json.sha256
jq '.bomFormat, .specVersion, (.components | length)' evidence/sbom.cdx.json

8. Provenance: bind subject bytes to build context

SLSA v1.2 describes provenance as verifiable information about where, when and how an artifact was produced. The recommended build provenance predicate continues to use https://slsa.dev/provenance/v1. For Jenkins, a useful minimal statement names the artifact subject digest and records a builder identity plus external parameters such as source URI and source digest. A hand-written lab statement teaches the schema; it does not magically make the Jenkins builder SLSA-compliant.

The trust comes from who creates and signs the statement, how that builder is isolated, and what policy later verifies—not from the presence of a JSON file named provenance.json.

9. DevOps connection

Promotion should consume evidence about immutable bytes, not rebuild from a branch name. Chapter 31 therefore becomes the bridge between earlier Jenkins execution/security chapters and Chapter 32’s artifact repository/promotion model: build once on an appropriate builder, identify the result by digest, attach SBOM/provenance/signature evidence, verify policy, then move the same bytes forward.

Knowledge check

Answer before revealing the explanation.

Official references and version notes

Use primary documentation because supply-chain formats, signing defaults and Jenkins security guidance evolve.

• Jenkins Java Support Policy
• Jenkins Security Advisories
• Sigstore Cosign — signing blobs
• Sigstore Cosign — verifying signatures
• Anchore Syft — SBOM generation
• CycloneDX specification overview
• SPDX specifications
• SLSA specification v1.2
• SLSA build provenance