CI and dependency trust
Review build and dependency trust from source selection through a verifiable artifact and its deployment authority.
This is the complete downloadable file. Open plain text ↗
---
name: supply-chain
description: "Review build and dependency trust from source selection through a verifiable artifact and its deployment authority."
---
# CI and dependency trust
Review build and dependency trust from source selection through a verifiable artifact and its deployment authority.
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
## Bring to the review
- Workflow definitions
- Lockfiles and dependency policy
- Build identities and artifact attestations
## Review guide
### 1. Map trusted inputs
Identify source revisions, external actions, package registries, caches, and contributors that influence a build.
### 2. Review execution authority
Confirm untrusted changes cannot inherit secrets, deployment credentials, or mutable release authority.
### 3. Verify provenance
Link the released artifact to its source, builder, dependency resolution, and approval evidence.
### 4. Constrain dependencies
Use explicit registries, namespace ownership, immutable versions, and reviewable lockfile changes.
## What to produce
- Build trust map
- Workflow permission review
- Dependency provenance record
## Common mistakes
- Assuming a repository event is trusted
- Using mutable build references
- Treating a package name as proof of ownership
## Reading and source context
### Resources
- [SLSA v1.2: supply-chain security and build provenance](https://vulns.co/research/resources/slsa-v1-2-supply-chain-build-provenance/)
- [OWASP Application Security Verification Standard (ASVS)](https://vulns.co/research/resources/owasp-asvs-5-security-verification-standard/)
- [NIST SP 800-190: Application Container Security Guide](https://vulns.co/research/resources/nist-sp-800-190-container-isolation-guide/)
### Diagrams
- [Build evidence must match the artifact and trusted builder](https://vulns.co/research/diagrams/build-artifact-provenance-boundary/)
### Reports
- [Angular automation trust and cache isolation weakness](https://vulns.co/research/reports/angular-ci-cache-trust-2026/)
## Provenance
Editorial guide by vulns.co / GK Data. Updated 2026-10-11.
Library snapshot: 2026-10-04; commit d5550c7891119cf1379e235721541c947850a3b3.
The guide is an editorial synthesis. Linked records preserve their own sources and review dates.
Reader: https://vulns.co/skills/supply-chain/
The review
What to look for
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
Map trusted inputs
Identify source revisions, external actions, package registries, caches, and contributors that influence a build.
Review execution authority
Confirm untrusted changes cannot inherit secrets, deployment credentials, or mutable release authority.
Verify provenance
Link the released artifact to its source, builder, dependency resolution, and approval evidence.
Constrain dependencies
Use explicit registries, namespace ownership, immutable versions, and reviewable lockfile changes.
What to produce
- Build trust map
- Workflow permission review
- Dependency provenance record
Common mistakes
- Assuming a repository event is trusted
- Using mutable build references
- Treating a package name as proof of ownership
Continue the study
Reading & source context
Editorial notes above connect these references. Open each record for its original source and review date.
Visual models
Connected disclosures
From the field toolkit
Guide by GK Data · Research snapshot 2026-10-04.
Sources and review dates are preserved in the library provenance.