Map the delivery trust chain
Trace how a change moves from developer to production: source repository, review, build workers, dependency sources, artefact storage, signing, deployment and runtime configuration. Record the identities and secrets at each step. A pipeline often holds more production authority than an individual administrator.
Separate duties where consequence warrants it. Protect branches, require review for sensitive paths and limit who can change pipeline definitions or deployment destinations. Service identities should be scoped to the specific repository, environment and action rather than reused across unrelated systems.
Protect builds and artefacts
Use controlled, reproducible build environments where practical. Pin or verify dependencies, protect caches from untrusted contributions and prevent secrets from appearing in logs or artefacts. Treat third-party actions and plugins as code with inherited authority.
Create immutable or integrity-checked artefacts and promote the same tested package between environments rather than rebuilding differently. Record source revision, build inputs, checks and deployment result so responders can connect a running version to the decision that released it.
Design fast, risk-based gates
Apply stronger approval and testing to production, privileged components and security-sensitive changes. Give low-risk teams automated paved paths instead of forcing every release through manual security review. Failed checks need an owner and a documented exception route.
Monitor changes to pipeline policy, new credentials, unusual deployment locations and bypassed gates. Exercise credential revocation and clean rebuild after suspected compromise. Measure unreviewed change, secret age, build provenance coverage and recovery time rather than the number of scanning tools enabled.
What to do next.
- ✓Map source-to-production identities and secrets.
- ✓Protect branches and pipeline definitions.
- ✓Scope build and deployment identities narrowly.
- ✓Promote verified artefacts instead of rebuilding.
- ✓Create risk-based gates and owned exceptions.
- ✓Test clean rebuild and credential revocation.
Use guidance responsibly
Technology, provider behaviour and legal requirements change. Validate implementation details against current official documentation, test changes safely and obtain qualified legal advice where required.
Liam Khumalo
Secure Systems ContributorCovers software, SaaS and infrastructure design with an emphasis on maintainable controls, ownership and safe change.
More from this writer