The Gap Between SAST Promise and Reality

▶ Watch (2:36)

Plugging a SAST tool into a GitHub organization produced 5,000 findings. 70% were false positives. Developers ignored everything, even critical ones. Security became a backlog, not a program. The promise of shift-left and developer empowerment collapsed into cacophony. Without trust, even perfect findings are garbage. The team needed a process to turn noise into signal.

Severity Filtering and Risk-Based Prioritization

▶ Watch (9:09)

The first fix: stop chasing low-severity noise. Using Semgrep Pro’s specialized rules and SR memories, the team dropped low and informational findings. They reduced 5,000 findings to 800. Then they prioritized by risk, not severity. They focused on compliance-scoped systems, payment processing, and PII-handling repositories. That covered 40% of the organization but 95% of real business risk.

Embedding into Developer Workflows

▶ Watch (10:37)

SAST findings went into PR comments with live feedback and fix recommendations. CI/CD checks blocked only criticals, with a break-glass exception for emergency deployments. Slack and Jira provided real-time severity updates. A dedicated technical debt team adopted Semgrep Pro for self-service and fixed 600 vulnerabilities by deleting an old Oracle library. Adoption happened when signal lived where developers worked.

AI-Driven Remediation: From 130 Days to 17 Days

▶ Watch (14:45)

Traditional SAST tells you what is broken, not how to fix it. The team aggregated similar findings (e.g., 10 SQL injections into one ticket), cloned the code, and used a laser-focused LLM prompt to generate patches. They created pull requests labeled as security recommendations for developer validation. This process fixed 78 high-severity vulnerabilities in three PRs over one week. Remediation time dropped from 130 days to 17 days.

Q&A

How do you balance severity vs. risk when prioritizing findings? Prioritize by risk, not severity; severity does not account for business context. ▶ 27:28

Do you recommend using one LLM vendor or a mix for auto-remediation? Use whatever the company already licenses; for simple input-validation bugs a cheaper model works, while complex logic may need a smarter model like Opus or Claude 3.5. ▶ 28:35

Notable Quotes

When 50% of findings are false positive, the answer is no. We don’t care. Adrián Puente Z. · ▶ 6:45

Without trust even perfect findings are garbage. Adrián Puente Z. · ▶ 7:03

I was able to remediate around 78 high severity vulnerabilities with three PRs and it took me like a week. Adrián Puente Z. · ▶ 18:44

SAST adoption only works with developers not at them. Adrián Puente Z. · ▶ 21:20

Key Takeaways

  • Filter SAST findings by severity and risk, not volume.
  • Embed security into developer workflows with PR comments and break glass.
  • Use AI to generate patches and cut remediation time from months to weeks.