Dependency and CI supply chain
Treat the build as an app. The question is which identity can publish, which workflow can read secrets, and which package name the install trusts.
Tags: supply-chain, cicd, dependencies, secrets
Checklist
- Names the build trusts: Package, image, and action names in the install and workflow files. An unpinned or easily confused name is a lead only if you can show the pipeline resolves it.
- Pins: Lockfiles, action commit SHAs, and image digests. A floating tag is a note with the file and line, not a severity by itself.
- Workflow identity: OIDC to cloud, long-lived tokens, and who can open a change that runs a privileged workflow. Record the identity, not a token value.
- Secret exposure: pull_request versus pull_request_target, fork access, and logs you are allowed to open. A secret printed in a log you can read is the result.
- Provenance: Attestations and signatures. Note whether deploy verifies them or only stores them next to the artifact.
- Who can publish: Maintainers and the release workflow for a dependency you actually use. A single unreviewed publish path is the design note.
- Artifact handoff: Build output uploaded, then pulled by a later job or a registry. Auth on that download URL, and whether it stays valid after the job ends.
- Stop line: Do not publish a package, claim a name, or run a workflow you do not own. Evidence is the config and an install resolution you can explain.