Code security within the pipeline

The security of continuous delivery depends on the ability to automatically detect insecure code, poor practices or known vulnerabilities before the build or the deploy. This practice defines the technical security validation controls to be applied directly within CI/CD pipelines, in a traceable way and proportional to risk.

Code must never be promoted without automated security validations that are visible in the pipeline.

---

🎯 Objectives

• Ensure that all delivered code has passed automated and consistent security validations;
• Integrate security testing as a mandatory part of the CI/CD flow;
• Prevent the inclusion of malicious or insecure code, or code with exposed secrets, in builds or releases.

---

🛠️ Practices

1. Integration of security testing into the pipeline

   • Inclusion of SAST (static analysis) as a mandatory pipeline stage;
   • Regular execution of scanners for secrets and hardcoded credentials;
   • Application of security linters (e.g. IaC, containers, internal policies).

2. Validation against the requirements defined in Chapter 02

   • The pipeline must verify whether the code meets the applicable security requirements;
   • L2 and L3 applications must have security gates defined as formal criteria.

3. Automatic rejection of code that violates minimum criteria

   • The build must fail if insecure functions, outdated libraries or embedded secrets are detected;
   • There must be explicit approval/rejection criteria (e.g. minimum quality, blocking critical findings).

4. Preservation and traceability of analysis results

   • Test results must be stored and associated with commits, branches or releases;
   • L3 applications must keep a formal history and mechanisms for reviewing findings.

5. Coverage proportional to risk and to the type of application

   • Critical applications must include IaC and SBOM testing, and analysis of dependencies, containers and binaries;
   • Coverage must be documented and revisited regularly.

---

⚖️ Proportional application by risk level

Level	Mandatory requirements	Enhanced requirements
L1	Basic SAST and secrets scanning integrated	-
L2	Build fails if minimum criteria are violated	IaC linters; analysis of containers and dependencies
L3	Formal findings policy; traceability per commit	Full coverage; formal validation with security gates

---

📌 Practical examples

• GitHub Actions

  • Integration with CodeQL, TruffleHog, IaC linters;
  • Automatic rejection with continue-on-error: false.

• GitLab

  • Integrated security (SAST, Secret Detection, Container Scanning);
  • Export of findings to dashboards and artefacts.

• Azure DevOps

  • SAST/DAST tasks as mandatory stages in azure-pipelines.yml;
  • Blocking quality gates via extensions (e.g. SonarQube).

• Jenkins

  • Integration with scanners (e.g. SonarQube, Semgrep, detect-secrets);
  • Automatic failure via control policies in the pipeline.

---

📉 Mitigated risks

• Inclusion of malicious or insecure code (OSC&R: SC0001, SC0006);
• Builds with undetected known vulnerabilities (OSC&R: SC0008);
• Outdated or compromised dependencies (link with Ch. 05);
• Leakage of hardcoded secrets (OSC&R: CI0010).

---