CI/CD Pipeline Security: SAST, DAST and SCA in Practice

CI/CD pipeline security means treating vulnerabilities as code defects — found and fixed before deployment, not after an incident. This approach, called shift-left, moves security controls to the earliest stages of the development cycle, where the cost of remediation is between 10 and 100 times lower than in production.

Why the pipeline is a critical attack surface

The CI/CD pipeline has privileged access to practically everything: the code repository, cloud credentials, the container registry, staging and production environments. An attacker who compromises the pipeline does not need to exploit the application — they control the process that builds the application. The SolarWinds (2020) and 3CX (2023) cases demonstrated that malicious code injected at the build stage can be signed and distributed as legitimate to thousands of customers with no alarm. In SolarWinds, the compromised artifact passed signature verification and was distributed through the official update channel. In 3CX, a contaminated third-party dependency was enough to compromise the official signed installer. These supply chain attacks made pipeline security a priority equivalent to the security of the application itself.

The four layers of analysis: SAST, SCA, DAST and IaC

Technique	What it analyzes	When it runs	Example tools
SAST	Application source code (without execution)	Commit / Pull Request	Semgrep, CodeQL, Checkmarx, SonarQube
SCA	Third-party dependencies (CVEs, licenses)	Commit / Pull Request	Snyk, OWASP Dependency-Check, Dependabot, Grype
DAST	Running application (staging)	After deploy to staging	OWASP ZAP, Nuclei, Burp Suite Enterprise
IaC Scanning	Infrastructure as code (Terraform, K8s)	Commit with an infra change	Checkov, KICS, Terrascan, tfsec
Container Scanning	Docker images (OS packages, CVEs)	Image build, before push	Trivy, Grype, Snyk Container
Secret Scanning	Credentials and tokens in code	First job of the pipeline	Gitleaks, Trufflehog, GitHub Secret Scanning

SAST: finding what you built wrong

Static Application Security Testing reads the code without executing it, building a model of data flow and the call graph to detect insecure patterns. SAST finds SQL injection when an unsanitized variable reaches a query, XSS when user input is rendered without escaping, the use of obsolete cryptographic algorithms (MD5, DES), references to dangerous functions (strcpy, eval, exec) and hardcoded configurations such as credentials in code. SAST's weak point is the false-positive rate — older tools generate noise that discredits the process. The solution is to use tools based on semantic rules with a low FP rate (Semgrep, CodeQL) and to configure a baseline on the first run: every existing result is accepted as known technical debt, and the gate blocks only new findings introduced in the PR under review.

SCA: the risk you imported

Software Composition Analysis solves a growing problem: most of a modern application's code was not written by the team — it is open source libraries. The npm tree of a typical Node.js application pulls in 500 to 2,000 transitive packages. SCA maps the complete dependency graph, cross-references it with CVE databases (NVD, GitHub Advisory Database, OSV) and flags: which package is vulnerable, which version fixes it, and whether a compatible version exists in the current graph. Beyond CVEs, SCA checks licenses — a GPL dependency in a proprietary product can create significant legal liability. Pipeline integration must include continuous monitoring: a dependency that was safe last week may have a CVE published today, with no code change on your part.

DAST: confirming what is still exploitable

Dynamic Application Security Testing acts like an external security researcher: it interacts with the running application, sends malicious payloads and observes the behavior. DAST finds what SAST cannot — flaws that emerge only at runtime, such as incorrect server configurations, missing security headers (CSP, HSTS, X-Frame-Options), undocumented endpoints that escaped static analysis, and business-logic vulnerabilities that depend on sequences of requests. The challenge of DAST in automated pipelines is execution time and coverage: a full crawl can take hours. The practical solution is a targeted DAST test suite — run against the critical endpoints defined in the application's OpenAPI specification — and a broad passive scan that injects no payloads and therefore causes no side effects on test data.

Poisoned Pipeline Execution: the attack on the CI itself

Poisoned Pipeline Execution (PPE) is a class of attacks catalogued by Cider Security researchers in 2021. The premise is simple: if an attacker can modify the workflow definition file (such as .github/workflows/ci.yml) in a context where the pipeline has access to production secrets, they can exfiltrate credentials, modify artifacts during the build or escalate privileges to the registry and the cloud. This access can come from an external PR (fork), from an unprotected branch, or from a compromised third-party action dependency. Mitigation requires multiple controls: workflows for external PRs must use the pull_request event (without production secrets) instead of pull_request_target; third-party actions must be pinned by an immutable commit hash, not by a semantic tag that can be silently rewritten; the GITHUB_TOKEN must have minimal permissions declared explicitly; and cloud authentication must use OIDC instead of static credentials stored in environment variables.

Artifact signing and the SLSA framework

The technical answer to supply chain attacks is to ensure verifiable provenance — cryptographic evidence that a specific artifact was produced by a specific process from a specific commit. The SLSA framework (Supply-chain Levels for Software Artifacts, pronounced salsa), maintained by the Linux Foundation and backed by Google, GitHub and others, defines four maturity levels. SLSA 1 requires automatically generated provenance. SLSA 2 adds cryptographic signing of the provenance. SLSA 3 requires the build to run on controlled, auditable infrastructure, and the provenance to be generated by the build system itself in a non-forgeable way. SLSA 4 (still in development) adds hermetic and reproducible builds. The practical implementation uses Sigstore — an open source project offering signing without private key management, using ephemeral certificates bound to OIDC identities — and Cosign to sign and verify container images. With SLSA 3 + Cosign, a deployment system can refuse any image whose signed provenance does not match the expected repository and commit, making attacks like SolarWinds detectable before distribution.

Least privilege on runners: the most neglected principle

CI runners are machines with privileged access that execute arbitrary code on every push. Despite this, most organizations grant them broad cloud, registry and secret permissions. The least-privilege model for runners requires: (1) using OIDC for cloud authentication — the runner obtains a temporary, minimally scoped token per job, with no persistent credentials; (2) separating environments by branch — runners for external PRs do not access staging secrets, only runners for merges into the main branch do; (3) isolating production runners on a separate network, with no outbound route to the internet except specific endpoints; (4) using ephemeral runners — destroyed after each job, with no persistent state that could be compromised between runs; (5) regularly auditing the IAM permissions assigned to each runner role with tools such as AWS IAM Access Analyzer or GCP IAM Recommender.

Security gates: blocking without paralyzing development

A security gate is a stop condition that prevents the pipeline from advancing when a security criterion is not met. The naive implementation — block any CVE or any SAST finding — paralyzes development on day one. The effective implementation uses three criteria: severity (block only critical/high with an available fix), novelty (diff-based alerting: block only findings introduced in the PR, not historical technical debt) and deadline (medium findings become tickets with a 30-day SLA, low ones go into the quarterly backlog). This model lets the team move forward without accumulating new vulnerabilities while addressing existing debt in a structured way. The tracking metric is MTTR by severity — Mean Time to Remediate — which should be monitored and reported monthly to demonstrate the maturity of the security program.

Normative references

Implementing DevSecOps in regulated environments should align with: the OWASP DevSecOps Guideline (owasp.org/www-project-devsecops-guideline), which maps security controls to each SDLC phase; the NIST SSDF — Secure Software Development Framework (SP 800-218), a U.S. government reference adopted in federal contracts and increasingly required in enterprise contracts in Brazil; SLSA (slsa.dev) for supply chain integrity; and, in the Brazilian context, BCB Resolution 4.658 and CVM Resolution 35/2021, which require formal risk management in the systems development cycle for financial institutions. Alignment with ISO 27001:2022 Annex A.8 (Asset Security) and A.8.25-A.8.31 (Secure development lifecycle) is required in certification audits and in contracts with large corporations.

Frequently asked questions

What is the difference between SAST, DAST and SCA in the context of CI/CD?

SAST analyzes source code without executing the application, detecting flaws such as SQL injection and insecure cryptography use directly in the repository. DAST interacts with the running application in staging, simulating external attacks. SCA does not analyze the code you wrote, but the third-party libraries you use: it maps known CVEs, problematic licenses and transitive dependencies. The three approaches are complementary — SAST finds what you built wrong, SCA detects what you imported wrong, DAST confirms what is still exploitable at runtime.

At which pipeline stage should each tool run?

SAST and SCA run on the commit or pull request, before the merge into the main branch. Secret scanning should be the first job of the pipeline. IaC scanning runs whenever Terraform, CloudFormation, Helm or Kubernetes files are modified. Container scanning acts on the Docker image build, before the push to the registry. DAST goes after the deploy to staging, when the application is running and accessible — on an isolated environment URL, not in production.

What is a security gate and how do you configure it without stalling the team?

A security gate is a stop condition in the pipeline that blocks advancement when a security criterion is not met. A configuration that does not paralyze development combines three criteria: minimum severity (block only critical/high with an available fix), diff-based alerting (block only new findings introduced in the PR, not existing technical debt) and remediation deadline (medium findings become tickets with a 30-day SLA). Tools such as Semgrep, Snyk and GitHub Advanced Security support this model natively.

What is Poisoned Pipeline Execution and how do you mitigate it?

Poisoned Pipeline Execution is an attack in which an adversary injects malicious code into the pipeline definition file to exfiltrate secrets or tamper with artifacts during the build. Mitigation requires: never running external-PR workflows with access to production secrets; pinning third-party actions by an immutable commit hash; using OIDC instead of static credentials; and applying explicit minimal permissions to each job's GITHUB_TOKEN.

How do supply chain attacks like SolarWinds and 3CX relate to the pipeline?

The SolarWinds attack injected malicious code at the compilation stage, generating a signed, legitimate artifact distributed to 18,000 customers. The 3CX case compromised a third-party dependency that contaminated the official signed installer. Both demonstrate that trust in the final binary does not equal trust in the process that generated it. The technical answer is the SLSA framework with signing via Sigstore/Cosign: verifiable provenance and hermetic builds make these attacks detectable before distribution.

What are the normative references for implementing DevSecOps?

The main references are: the OWASP DevSecOps Guideline (controls per SDLC phase), NIST SSDF SP 800-218 (secure development practices), SLSA (supply chain integrity), the CIS Software Supply Chain Security Guide, and in Brazil BCB Resolution 4.658 and CVM Resolution 35/2021 for regulated institutions. Alignment with ISO 27001:2022 Annex A.8.25-A.8.31 is required in certification audits and enterprise contracts.

How Decripte implements DevSecOps

Decripte integrates DevSecOps and AppSec practices into organizations of every size — from sole proprietors who need a secure pipeline for their APIs to enterprises with more than 100,000 employees managing dozens of products in production. The implementation covers the audit of the existing pipeline, integration of SAST, SCA, DAST, IaC and container scanning tools, definition of security gates calibrated to the team's maturity, adoption of SLSA and Sigstore for artifact integrity, and training of development teams in secure practices. The result is measured in MTTR, reduction of vulnerabilities introduced per PR and compliance with regulatory requirements. Explore the implementation plans or start with an analysis of your pipeline at the free tier.