Notifications
Clear all
Topic starter
19/08/2026 3:54 pm
TL;DR: Weak access control, exposed secrets, unchecked dependencies, and overbroad deployment permissions can move attackers from source access to production compromise, according to Appknox. The security model must shift from post-build review to identity-aware, automated controls embedded across the delivery chain.
NHIMG editorial — based on content published by Appknox: CI/CD Security Checklist for Engineering Managers
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should security teams implement CI/CD security without slowing delivery down?
A: Build security into the pipeline itself instead of adding late-stage manual gates.
Q: Why do exposed secrets in CI/CD pipelines create such a large blast radius?
A: CI/CD systems often hold cloud credentials, deployment tokens, and repository access in the same execution context.
Q: What breaks when CI/CD runners are reused across jobs?
A: Reusable runners can retain tokens, cached dependencies, logs, and state from previous executions.
Practitioner guidance
- Harden pipeline identity controls Require MFA for source control, CI platforms, and artifact repositories, then apply RBAC to remove unused accounts and narrow who can change pipeline definitions.
- Move secrets out of code paths Block repositories, YAML files, and plaintext environment variables from holding credentials, and force all privileged values into external secret managers.
- Make build environments disposable Use ephemeral runners, prevent state persistence across jobs, and generate SBOMs for every build so a compromised job cannot contaminate later releases.
What's in the full article
Appknox's full blog covers the operational detail this post intentionally leaves for the source:
- A step-by-step CI/CD checklist for access control, branch protection, and secrets handling across GitHub, GitLab, and Bitbucket.
- Concrete examples of SAST, DAST, and IaC scanning inside build pipelines, including tool choices and configuration patterns.
- Deployment-stage guidance on OIDC-based credentials, protected environments, and least-privilege permissions for production releases.
- Incident response steps for token revocation, pipeline shutdown, artifact validation, and post-incident rechecks.
👉 Read Appknox's CI/CD security checklist for engineering managers →
CI/CD security checklist: are your build and deploy controls enough?
Explore further
19/08/2026 4:31 pm
CI/CD pipelines are now identity-bearing production systems, not just engineering tooling. The article correctly treats access, secrets, and deployment permissions as first-class security controls because these pipelines can ship code directly into production. That makes their service accounts, tokens, and runners part of the identity estate, even if they are managed by engineering teams rather than IAM teams. The governance implication is straightforward: if a pipeline can deploy, it needs the same lifecycle, audit, and privilege discipline as any other high-risk identity domain.
A question worth separating out:
Q: What should teams do when a CI/CD credential is exposed?
A: Revoke the token, validate the affected pipeline and artifact chain, and confirm whether the credential was used for deployment or build access. Then rotate any related secrets, review recent pipeline changes, and verify that protected environments and approvals still block unauthorized release activity.
👉 Read our full editorial: CI/CD security gaps are still exposing build secrets and deploy access
