Skip to main content

Integrating Security Testing into the CI/CD Pipeline

🌟 Objective​

To ensure that security tests are executed automatically and with well-defined criteria in all relevant CI/CD pipelines, guaranteeing:

  • Early detection of flaws and blocking of builds when necessary;
  • Traceability between results, artefacts and commits;
  • Reinforcement of the security culture as part of the delivery process;
  • Fulfilment of regulatory and internal requirements without depending on manual actions.

Security that is not integrated into the pipeline is invisible - and therefore ineffective.

🔍 What “integrating tests into the pipeline” means​

Integrating tests into the pipeline means automating the execution of security tests as part of the build, validation, release or deploy process. It may include:

  • Execution of SAST, SCA, DAST, fuzzing, regressions and linters;
  • Generation of SBOMs and security coverage analysis;
  • Validation of findings, thresholds and gates by severity;
  • Production of traceable artefacts with validation evidence.

⚙️ How to apply​

  1. Map the pipeline stages where each type of test must take place:
    • Pre-build (linters, SBOM);
    • Build (SAST, SCA);
    • Staging (DAST, IAST, fuzzing);
    • Release (final validation and regressions);
  2. Create specific security jobs, with visible and versioned output;
  3. Define gates and blocking criteria by severity, type of flaw or absence of validation;
  4. Include metadata in the build artefacts (e.g. commit, environment, tool version, hash);
  5. Ensure isolation of the test environments, especially for fuzzing and DAST;
  6. Run security tests in parallel, without affecting total delivery time.

💡 Tests such as SAST and regression may be blocking; tests such as DAST and fuzzing may be informative in asynchronous pipelines.

✅ Good practices​

  • Create pipelines dedicated to security, when possible (e.g. nightly or post-release);
  • Keep a history of executions and results per commit, branch and release;
  • Integrate findings with the backlog or triage system (Jira, Azure Boards);
  • Ensure that tools are versioned and controlled as dependencies;
  • Validate the real coverage and frequency of the tests in the pipeline (not just the presence of the jobs);
  • Involve DevOps teams in orchestration and continuous maintenance.

📎 Cross-references​

DocumentStrategic relevance
Chapter 07 - Secure CI/CDConditions for secure execution and segregation
01-sast.md, 02-dast.mdTest types that must be automated
06-cobertura-e-priorizacao.mdDefines what, when and how to test in the pipeline
08-gestao-findings.mdEnsures effective handling of the results
Chapter 12 - Monitoring and OperationsTracking of security failures at runtime

📦 Integrating tests into the pipeline turns security into a continuous, auditable and verifiable activity - instead of a one-off checklist before delivery.