Skip to main content

Pro audit program · v1.0

SAST / DAST / Secret Scanning in CI

The three scanners every CI/CD should run, with finding triage and trend tracking.

  • General target area
  • NIST SSDF / OWASP framework
  • 7 controls in this program
  • Cyentrix Cyentrix Trusted Author
Sign in to run → Back to library

About this program

The three scanners every CI/CD should run, with finding triage and trend tracking.

Risks addressed

  • Critical Secret committed to a public repo
  • Critical SQL injection ships because no SAST in CI
  • High Findings pile up without ownership u2014 scanner ignored

Controls (7)

  1. SAST on every PR

    High

    Static Application Security Testing (SAST) is automatically executed on every pull request (PR) before code can be merged into protected branches. The SAST tool scans source code for security vulnerabilities such as injection flaws, authentication bypasses, hardcoded secrets, and insecure…

    How to test + evidence

    Testing procedure: CI runs SAST per PR; high / critical findings block the merge.

    Evidence to collect: CI workflow + last run.

  2. DAST against staging on every release

    High

    Dynamic Application Security Testing (DAST) is automatically executed against the staging environment as a mandatory step in every software release pipeline. The DAST scanner performs runtime analysis by sending crafted requests to the deployed application to identify vulnerabilities such as…

    How to test + evidence

    Testing procedure: DAST runs against staging; high findings block release or get explicit exception.

    Evidence to collect: CI workflow + last DAST report.

  3. Secret scanning pre-commit + push

    Critical

    Secret scanning pre-commit and push controls integrate automated tooling into developer workflows to detect and prevent hardcoded credentials, API keys, tokens, certificates, and other sensitive data from being committed to version control repositories. These tools scan code changes locally before…

    How to test + evidence

    Testing procedure: Pre-commit hook + repo-side push protection; positives notify security.

    Evidence to collect: Hook config + recent block.

  4. Triage SLA per severity

    High

    This control establishes and enforces service level agreements (SLAs) that define maximum response and remediation timeframes for security incidents based on their severity classification (e.g., Critical, High, Medium, Low). Automated ticketing systems route incidents to appropriate teams and trigger escalations…

    How to test + evidence

    Testing procedure: Critical 7d / High 14d / Medium 30d. Trend reported monthly.

    Evidence to collect: Triage dashboard.

  5. False-positive feedback loop

    Medium

    A false-positive feedback loop is a continuous improvement mechanism for security monitoring systems where security analysts systematically review, categorize, and report detection rules that incorrectly flag benign activity as malicious. The feedback is used to tune detection logic, adjust thresholds,…

    How to test + evidence

    Testing procedure: Engineers can mark FPs with justification; security reviews patterns weekly.

    Evidence to collect: FP register.

  6. Backlog of older findings tracked

    Medium

    This control ensures that security findings and vulnerabilities that were not remediated within the initial target timeframe are actively tracked in a backlog system with documented justification, assigned ownership, and prioritized remediation plans. The backlog should include all aged findings…

    How to test + evidence

    Testing procedure: Findings older than the policy SLA show up on the team dashboard.

    Evidence to collect: Dashboard screenshot.

  7. Container image scanning before push

    High

    Container image scanning before push requires that all container images undergo automated vulnerability and compliance scanning prior to being pushed to a container registry. Scanning tools analyze image layers, dependencies, and configuration for known CVEs, malware, misconfigurations, and policy violations.…

    How to test + evidence

    Testing procedure: Built images scanned (Trivy / Grype / equivalent) before promotion.

    Evidence to collect: CI step + last scan.