From Noise to Notes: Orchestrating SAST with Developers through AI-Driven Remediation

I recently had the incredible honor of presenting my talk, “From Noise to Notes: Orchestrating SAST with Developers through AI-Driven Remediation,” at BSidesSF 2026. It was an amazing experience, and I am truly honored to have been part of the conference this year. I was personally mind-blown by the professionalism and perfect coordination of every detail by the organizers, which made the event a seamless success. This initiative was successfully managed and executed by a lean team: me as a full-time employee and one dedicated contractor. My presentation focused on the journey of transforming Static Application Security Testing (SAST) from a source of developer frustration into a high-value security partner within my current employer.

The Philosophy: Shifting Left

The core of our strategy is the concept of “shifting left.” SAST is a method of checking computer programs for security vulnerabilities by analyzing source code without actually running the program. By integrating these scans early in the Software Development Lifecycle (SDLC), we help developers catch issues like injection flaws or hardcoded secrets while they are still writing code. This makes fixes faster, cheaper, and more effective than finding them after deployment.

The Challenge of “Cacophony”

The promise of SAST is to empower developers, but the reality often starts with “cacophony.” When we first rolled out our scanning capabilities across over 1,000 repositories, we were met with a staggering backlog of approximately 3,500 findings.
This massive volume of alerts created a significant problem: noise and mistrust. When engineers are overwhelmed with thousands of findings, many of which are false positives or low-risk items, they begin to see security as a blocker that slows them down. We learned quickly that raw finding counts do not equal security value, and without developer trust, even the most critical findings are often ignored.

Signal vs. Noise: The Quality of Findings

A turning point in our success story was recognizing the difference in the quality of findings. While community-driven rules, such as those used in Opengrep, provide a low-cost entry point for scanning, they are often limited to single-file or single-function analysis. This limited scope can lead to higher false-positive rates because the tool cannot track dangerous data as it moves across different files.

To build a high-signal program, we prioritized Research-curated Pro rules. These high-confidence, professionally maintained rules are only available through Semgrep Pro. Unlike community rules, Pro rules leverage advanced inter-file dataflow analysis to trace vulnerabilities across the entire codebase. By focusing our efforts on these specific findings, we were able to effectively separate high-quality “notes” from the background “noise,” ensuring that the issues we sent to developers were accurate and actionable.

Finding Harmony Through Prioritization

To move from noise to an actionable signal, we changed our approach to focus on what matters most to developers and the business. This section of our journey was critical to rebuilding trust across our engineering teams. We implemented a multi-layered strategy to tune our results:

• Prioritizing by Severity and Confidence: We shifted our focus strictly to findings classified as High or Critical Severity that also carried High or Medium Confidence. This was largely made possible by the Pro rules, which are specifically designed to produce highly accurate findings.
• Risk-Based Classification: We used a system to classify repositories by data sensitivity (levels D0 to D2) and availability tiers (T1 to T2). This allowed us to focus our primary efforts on core business systems and repositories that handle sensitive customer or financial data.
• Leveraging Advanced Tooling: We utilized Semgrep Memories to auto-learn patterns and suppress repeated false positives. Additionally, we deployed Semgrep Assistant, an LLM-powered triage tool, to pre-triage findings and reduce the manual effort required from our engineering teams.
• Aggregating Results: To reduce context switching, we began reporting similar triaged findings within a single ticket rather than flooding developers with individual alerts for the same underlying issue.

Success and Expansion

By the end of Q3 2025, this focused high-impact scope allowed us to reduce nearly 6,000 total findings down to 785 prioritized items. At that time, we were scanning 1,039 of our 2,760 repositories, which covered approximately 95% of our high-risk systems.
Based on the success of this story, we received additional budget by the first quarter of 2026. This allowed us to increase our coverage to 100% of our repositories. Remarkably, reaching full coverage only resulted in a spike of approximately 20% more findings. This small increase proved that our initial risk-based classification strategy was correct: the vast majority of critical issues were indeed captured within our first prioritized 95%. Today, we have reached a major security milestone: we have achieved zero open findings with Critical or High severity and high confidence across our entire codebase.

Closing the Last Mile: Vibe Security Patching

Vibe Security Patching is the strategic solution to what is often called the “Last Mile” problem in application security. While traditional Static Application Security Testing (SAST) is excellent at identifying what is wrong and where it is located, it traditionally stops there, leaving the difficult task of determining how to fix the issue entirely to the developer.

We recognized that this gap creates a significant burden for engineers, who must research the vulnerability, understand the specific code context, and write a fix from scratch, a process that is frequently slow and error-prone. To close this gap, we moved beyond mere detection into AI driven remediation.

The Five Step Orchestration Process

Vibe Security Patching follows a structured workflow to turn findings into fixes:

1. Security Engineer Triage: A security professional identifies high impact vulnerabilities from the existing backlog.
2. Aggregate and Scope: Similar issues across the entire codebase are grouped together. This allows for fixing multiple instances of a vulnerability pattern at once rather than addressing them in isolation.
3. AI Patch Generation: Using Semgrep Assistant (an LLM powered tool), the system analyzes the finding and its surrounding context to create a “code-vibed” security patch. This patch is specifically designed to match the existing style and logic of the company’s codebase.
4. Developer Review: Instead of starting from zero, the developer receives a ready to review patch that they can quickly apply or modify as needed.
5. Merge and Verify: Once approved, the patch is merged, and the vulnerability is officially resolved.

Context Awareness and “Memories”

A critical component of this success is the use of Semgrep Multimodal and Memories. These advanced AI features allow the tool to learn the preferred libraries and functions used by engineering. This ensures the generated patches are not generic but are tailored to our specific architectural standards.

Impact on Security Velocity

The transformation from manual remediation to Vibe Security Patching has shifted security from a blocker to a partner for our engineering teams. By automating the “how to fix” portion of the lifecycle, the Mean Time to Remediation (MTTR) for prioritized vulnerabilities was reduced from weeks to just 48 to 72 hours. This allows my company to maintain high developer velocity while ensuring a secure by default coding environment.

Key Takeaways

As we look toward the future of application security, these four lessons remain our north star:

1. SAST adoption only works when it works WITH developers: Empathy, trust, and developer experience are non-negotiable.
2. Reduce noise to find signal: Focus strictly on high-confidence, high-severity findings and use AI to help with auto-triaging.
3. Measure outcomes, not findings: Prioritize metrics like adoption rates and fix rates over raw vulnerability counts.
4. AI closes the last mile: Moving from alerts to actual fixes through AI-driven remediation accelerates secure software delivery.

Our journey proved that SAST adoption only works when it works with developers. Empathy and developer experience are non-negotiable. By focusing on high-quality Pro rules and AI-driven fixes, we moved from a state of noise to a state of notes. I am incredibly grateful to the BSidesSF team for the opportunity to share this story at such a perfectly run event. Building a secure culture is about more than just tools; it is about turning findings into fixes and building confidence across the entire organization.

You can download the presentation here: “From Noise to Notes: Orchestrating SAST with Developers through AI-Driven Remediation,”