CI/CD security testing

Expanded Definition

CI/CD security testing is the practice of embedding security checks into the software delivery pipeline so that code, configuration, dependencies, containers, and runtime behaviour are assessed before release. It is broader than a single scanner: mature programmes combine source analysis, dependency review, secrets detection, infrastructure-as-code checks, dynamic testing, and policy gates that can stop an unsafe build from progressing. In NHI Management Group’s view, the term is best understood as a control layer for software supply chain risk, not just a developer convenience.

Definitions vary across vendors because some products describe only static analysis while others include runtime validation or release governance. For that reason, the scope should be stated explicitly when the term is used. The governance value is strongest when testing is tied to release criteria, change management, and evidence collection rather than treated as a post-build report. The NIST Cybersecurity Framework 2.0 provides a useful reference point for aligning these checks with risk management and protective controls.

The most common misapplication is calling a pipeline “secure” because one scanner ran once, which occurs when teams confuse visibility with enforced release control.

Examples and Use Cases

Implementing CI/CD security testing rigorously often introduces build latency and release friction, requiring organisations to weigh faster delivery against stronger pre-deployment assurance.

• static application security testing runs on pull requests to catch injection flaws, unsafe deserialisation, and insecure coding patterns before merge.
• Software composition analysis checks third-party packages for known vulnerabilities and licence issues, helping teams avoid shipping risky dependencies.
• Secrets scanning blocks hard-coded API keys, tokens, and certificates from entering repositories or build artefacts.
• Infrastructure-as-code testing validates cloud templates against insecure defaults, such as public storage, weak network exposure, or missing logging.
• Dynamic testing in staging exercises a deployed service to identify authentication weaknesses, broken access control, or unsafe error handling.

Where pipeline security is used for regulated environments, teams often map test evidence to NIST Cybersecurity Framework 2.0 outcomes so that release decisions are easier to audit and repeat. The key is not to treat every control as a blocker; instead, teams should define which findings fail a build, which trigger review, and which generate tracked exceptions. That decision-making model keeps testing actionable rather than noisy.

Why It Matters for Security Teams

CI/CD security testing matters because modern breaches increasingly start with weak code, unsafe dependencies, exposed secrets, or misconfigured deployment assets that move from commit to production in minutes. When teams do not test within the delivery process, security review happens too late to prevent propagation, and remediation becomes costlier after release. For identity-heavy systems, this also affects IAM and NHI governance: compromised service accounts, leaked tokens, and overly permissive automation credentials often emerge from insecure pipeline practices rather than from application code alone.

Security teams need to see this term as part of operational governance, not just engineering hygiene. That means defining ownership, evidence retention, exception handling, and escalation paths for failed checks. It also means understanding that CI/CD security testing is only effective when the pipeline can enforce policy, not merely report findings. The most useful programmes integrate these checks with change control, release approvals, and monitoring so that risky artefacts are caught before they become trusted production dependencies.

Organisations typically encounter the full cost of CI/CD security testing only after a compromised build, exposed secret, or vulnerable dependency reaches production, at which point the pipeline itself becomes the only practical place to stop recurrence.

Related resources from NHI Mgmt Group

• How should security teams implement API security testing in CI/CD pipelines?
• What is workload identity federation and why is it important for CI/CD security?
• How should security teams govern machine credentials across cloud and CI/CD environments?
• How should security teams govern credentials used by CI/CD pipelines?