Practice : Security Testing in CI/CD

Purpose and Strategic Importance

Security Testing in CI/CD ensures that security vulnerabilities are identified and addressed as early as possible in the software delivery process. By embedding security into the pipeline, teams can prevent issues from reaching production, reduce remediation costs, and accelerate secure delivery.

This practice supports the “shift-left” movement in security, making it continuous, collaborative, and proactive. It’s foundational for DevSecOps and critical to maintaining user trust, data protection, and compliance.

Description of the Practice

  • Security tests run automatically during CI/CD, alongside unit and integration tests.
  • Techniques include static application security testing (SAST), software composition analysis (SCA), secret scanning, dependency checks, and dynamic application security testing (DAST).
  • Common tools include Snyk, SonarQube, Trivy, GitHub Advanced Security, and OWASP ZAP.
  • Results are integrated into code reviews, dashboards, and developer feedback loops.
  • Tests are tuned to balance thoroughness and false positive reduction.

How to Practise It (Playbook)

1. Getting Started

  • Integrate basic SAST and SCA tools into your CI pipeline.
  • Scan for known vulnerabilities in open-source dependencies and container images.
  • Configure pipelines to fail on high-severity issues or introduce manual gates for review.
  • Include secret scanning to catch hardcoded credentials before they’re pushed.

2. Scaling and Maturing

  • Expand security tests to include DAST, IaC scanning, and runtime protections.
  • Prioritise remediation with contextual risk scoring and vulnerability policies.
  • Automate triage and ticket creation for security issues in backlog tooling.
  • Monitor pipeline performance to ensure security doesn’t block speed.
  • Collaborate with security champions across squads to improve threat modelling.

3. Team Behaviours to Encourage

  • Treat security bugs like any other defects - fix early and visibly.
  • Include security testing results in retros, sprint reviews, and release readiness.
  • Encourage developers to fix issues, not just silence them.
  • Share knowledge through secure coding workshops and threat model reviews.

4. Watch Out For…

  • Pipeline noise from poorly tuned tools - resulting in alert fatigue.
  • Ignoring test failures due to process friction or lack of ownership.
  • Treating security as a blocker rather than a quality enabler.
  • Delayed feedback loops that slow down secure delivery.

5. Signals of Success

  • Security vulnerabilities are detected and addressed early in the dev cycle.
  • CI/CD pipelines balance security and speed with minimal false positives.
  • Developers understand and act on security feedback in code reviews.
  • Security posture improves across all environments - from dev to prod.
  • Secure coding becomes part of engineering culture, not a separate function.