Software Supply-Chain Security, SBOMs, Signatures, Provenance, Trusted Agents, and Dependency Controls: Diagnostics, Failure Modes, Security, and Performance

1. Evidence-first diagnostic sequence

1. Preserve job full name, build number/URL, queue ID, source SHA and the first failing log/evidence files.
2. Confirm Jenkins core/Java/plugin baseline and current security advisories.
3. Confirm Jenkinsfile and Shared Library revisions and build cause.
4. Inspect queue reason, label eligibility, agent identity, Remoting/JVM and workspace.
5. Confirm tool versions, pinned image/tool checksums and dependency lock state.
6. Recompute the artifact digest and compare it with the signature/provenance subject.
7. Inspect SBOM schema/generator output independently from vulnerability/policy results.
8. Verify the expected signer/builder identity—not just cryptographic validity.
9. Check repository/promotion state only after local artifact/evidence consistency is established.
10. Apply the least destructive correction and rerun only the smallest safe scope.

2. Failure map

3. Intentionally broken example: verify “any valid signature”

The following policy is broken conceptually:

# BROKEN POLICY IDEA — do not use as a production gate
cosign verify-blob artifact.bin --bundle artifact.sigstore.json

A verifier that does not constrain the expected public key or keyless certificate identity/issuer can accept a signature that is valid cryptographically but irrelevant to your release policy. For key-based verification, point to the expected trusted public key and manage its fingerprint. For keyless verification, constrain both identity and issuer.

# Keyless policy shape — example identity only
cosign verify-blob artifact.bin \
  --bundle artifact.sigstore.json \
  --certificate-identity='release-bot@example.invalid' \
  --certificate-oidc-issuer='https://issuer.example.invalid'

The example domain is deliberately non-production. A real CI identity must match the provider’s documented identity semantics exactly.

4. Failure: “SBOM generated” interpreted as “safe”

Generation success proves that the tool emitted a document. Vulnerability analysis needs an advisory source and matcher; license policy needs license evidence and organizational rules; dependency approval may need provenance or repository admission controls. Preserve the original SBOM and its digest before running downstream analysis so you can prove which inventory the policy evaluated.

5. Failure: signed mutable name instead of immutable subject

Signing a release note that says image: app:prod is weaker than binding verification to the immutable image/artifact digest. Tags and filenames are routing conveniences; policy should resolve them to immutable identity and ensure the signature/provenance subject matches.

6. Failure: provenance generated on an untrusted agent

A JSON statement can say anything. If repository-controlled code on an untrusted agent can choose builder.id, source SHA or subject digest and then sign with release authority, the provenance is self-asserted. Separate build orchestration from trusted evidence generation, or use a build platform mechanism that can emit provenance outside the workload’s control.

7. Plugin/tool advisories are builder evidence

On 16 September 2026 Jenkins published an advisory affecting multiple plugins including OWASP Dependency-Check, Pipeline: Groovy Libraries and Script Security. This matters even if Chapter 31 does not require those plugins: a trusted builder’s controller/plugin baseline is part of its transitive trust. Record the plugin catalog used for release jobs and review advisories before declaring the builder trusted.

Likewise, Cosign 3.1.3 was released with a fix for a legacy-bundle verification bypass. Pinning a version without watching security releases is not enough; governance includes updating the pinned baseline after testing.

8. Performance: measure before weakening evidence

SBOM generation can be I/O-heavy on large workspaces/images. Signing is usually small compared with compilation, but transparency/identity services add network latency. Before adding executors or disabling evidence, measure stage duration, artifact size, SBOM size, cache behavior, repository transfer time and queue wait separately.

9. Repair checklist

• Never regenerate evidence before preserving the failed evidence packet.
• Do not sign a rebuilt artifact merely to “make verification pass.”
• Do not disable identity constraints or --check-claims-style protections to make a gate green.
• Do not expose signing keys to fork/PR builds.
• Do not delete by “latest”; guard exact build, digest, repository coordinate and lab namespace.

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