DevOps QA / Intermediate: trustworthy validation systems / Lesson 10
Pipeline secrets and supply-chain evidence
Protect the machinery producing quality evidence and distinguish security findings from artifact provenance.
On this page
Lesson goals
- Separate untrusted test execution from privileged delivery work.
- Use least privilege and verified provenance without overstating guarantees.
Treat contributed code as executable input
A pull request can change tests, package scripts, dependency installation hooks, and workflow files. Running it with credentials or a privileged runner crosses a trust boundary even when the stated purpose is only testing. Separate untrusted validation from artifact promotion and privileged publication. Understand the event semantics of the CI provider before exposing secrets; a familiar event name is not a security model. Do not check out untrusted code in a privileged workflow and assume log masking will contain it. Tests are code and can use every capability granted to their process.
Declare the smallest job authority
A unit-test job usually needs repository read access and local compute, not package publication or cloud administration. GitHub Actions permissions can reduce GITHUB_TOKEN authority, but they do not remove unrelated credentials supplied through environment variables or a persistent runner. Short-lived federated identity can reduce long-lived secret storage when configured with strict issuer, audience, repository, and environment conditions. It is not automatically safe merely because it uses OIDC. The example grants read-only contents permission to a conceptual test job and deliberately provides no deployment token.
permissions:
contents: read
jobs:
unit:
runs-on: ubuntu-24.04
timeout-minutes: 10
steps:
- name: Run prepared local unit suite
run: python -m unittest discover -s tests/unit
This is incomplete by design: trusted checkout and runtime setup must precede the test. ubuntu-24.04 selects a runner image family, not an immutable machine image. No secret or cloud identity is needed for this synthetic unit suite.
Verify what built the tested artifact
Dependency lockfiles, reviewed third-party actions, approved builder identity, and immutable artifact identifiers support supply-chain control. Pin third-party actions to reviewed full commit identifiers where policy requires it and automate review of updates; a mutable version tag is not immutable evidence. An SBOM inventories components, vulnerability scanning reports known findings, and provenance describes production of an artifact. None alone proves absence of malicious code or business defects. Verify provenance against trusted builder policy and the exact artifact rather than accepting any document that contains the word signed.
Separate verified facts from policy decisions
A gate can consume already-verified facts about artifact identity, builder trust, and vulnerability review. The function below is deliberately not a signature verifier; verification belongs to supported tooling with a documented trust root. Returning false should explain the missing fact without exposing credentials. Security scanners have false positives, false negatives, database age, and reachability questions. Triage findings with ownership and expiry rather than permanently ignoring an identifier. A clean scan supports a bounded claim about that tool’s knowledge and configuration, not a declaration that software is secure.
def supply_chain_eligible(facts):
required = (
"artifact_identity_verified",
"trusted_builder_verified",
"dependency_policy_reviewed",
"security_findings_reviewed",
)
return all(facts.get(key) is True for key in required)
A real implementation must obtain these facts from trusted verifiers, bind them to one artifact, and record policy version. Arbitrary JSON booleans from the candidate branch are not trustworthy attestations. This excerpt performs no scanning, signing, or external access.
Design diagnostics that do not leak authority
Synthetic credentials still need scope and cleanup, while real credentials should never be printed for debugging. Browser traces, HTTP dumps, command expansion, and uploaded environment files can expose values that masking misses after transformation. Minimize collection, redact at the source, restrict artifact access, and use short retention appropriate to the diagnostic need. If exposure occurs, follow the credential owner’s revocation and response process rather than assuming deletion of one log fixes it. Test the reporting path with a harmless sentinel to verify redaction without injecting a real secret.
Common errors and fixes
Untrusted tests access a publication credential
- Why it happens
- Validation and privileged work share credentials.
- How to fix it
- Separate trust boundaries and remove unnecessary authority.
- Prevent it next time
- Review event, runner, and credential scope together.
A provenance file is accepted without verification
- Why it happens
- Presence is confused with authentic trusted origin.
- How to fix it
- Verify artifact binding and builder identity with supported tools.
- Prevent it next time
- Document trust roots and policy versions.
A token appears in a trace artifact
- Why it happens
- Sensitive capture bypasses log masking.
- How to fix it
- Restrict exposure and invoke the owner’s response process.
- Prevent it next time
- Minimize and redact diagnostics before upload.
Check your understanding
1. An SBOM and zero scanner findings accompany a release. What remains unproven?
Show worked solution
Inventory and known-vulnerability checks do not establish business correctness, absence of unknown vulnerabilities, or trusted artifact production. Verify provenance and run behavior-specific evidence. Record scanner version, database age, scope, and unresolved limitations rather than turning zero findings into a universal security claim.
2. A unit suite asks for a cloud administrator credential to seed data. Redesign its boundary.
Show worked solution
Move ordinary rule tests to local synthetic fixtures with no cloud access. If a separate integration suite genuinely needs a service, provide narrowly scoped temporary resources and credentials through a trusted path. The name unit test does not justify broad authority.
Key takeaways
- The evidence-producing pipeline is itself a security boundary.
- Inventory, scanning, provenance, and behavior tests support different claims.
- Secrets must stay outside unnecessary test capabilities and diagnostics.