Notifications
Clear all
Topic starter
20/08/2026 5:42 pm
TL;DR: Software supply chain risk now spans source code, dependencies, CI/CD, build systems, cloud infrastructure, and third parties, and Cycode argues that the biggest exposure points are secrets leakage, overprivileged service accounts, and build integrity failures. The governance lesson is that identity, provenance, and runtime control have to be managed together, or attackers can turn one upstream weakness into downstream compromise.
NHIMG editorial — based on content published by Cycode: Software Supply Chain: The Complete Guide
Questions worth separating out
Q: How should security teams handle exposed secrets in modern software pipelines?
A: Treat exposed secrets as identity incidents, not just code defects.
Q: Why do CI/CD service accounts increase supply chain risk?
A: CI/CD service accounts are dangerous when they can change builds, approvals, or deployments across many systems with one credential.
Q: What breaks when artifact provenance is missing in software delivery?
A: Without provenance, teams cannot prove where a build came from, whether it was altered, or whether the deployed artifact matches what was reviewed.
Practitioner guidance
- Scope every pipeline identity to a single job or environment Remove shared service accounts where possible, set explicit expiration for CI/CD credentials, and bind each automation identity to the smallest repository, runner, or deployment path it needs.
- Rotate and revoke leaked secrets as an incident, not a hygiene task Create a response path for exposed API keys, tokens, and certificates that includes detection, revocation, re-issue, and dependency review across repos, logs, and build outputs.
- Require signed artifacts with provenance checks before release Block deployments unless the artifact is signed, the build source is traceable, and any post-build modification can be detected before promotion into production.
What's in the full article
Cycode's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step control patterns for securing CI/CD service accounts, runners, and deployment credentials across the SDLC.
- Implementation detail on SBOM, dependency tracking, and artifact provenance workflows for release governance.
- Operational guidance for secrets discovery, leak response, and pipeline hardening in development environments.
- Cycode's AI-assisted development governance considerations, including how generated code changes supply chain risk.
👉 Read Cycode's full guide to software supply chain security risks and controls →
Software supply chain risk: what IAM and security teams miss?
Explore further
20/08/2026 6:26 pm
Software supply chain security is now an identity governance problem, not only an AppSec problem. Once delivery depends on service accounts, pipeline tokens, and third-party automation, the question shifts from "is the code safe" to "which identities can alter what gets built and released." That is an IAM and PAM question as much as a tooling question, and it means NHI lifecycle controls belong in the SDLC. Practitioners should govern pipeline identities with the same discipline they apply to privileged human access.
A question worth separating out:
Q: How should organisations govern third-party access in regulated environments?
A: They should review third-party access as a separate governance stream with its own owners, expiry rules, and evidence trail. Third-party entitlements often outlive the business need that created them, which makes them harder to defend in audit and harder to contain when the relationship changes.
👉 Read our full editorial: Software supply chain risk is now an identity problem too
