For one, Semgrep (without AI) emits a stream of possible vulnerabilities found via static analysis, and Assistant reviews this stream of vulns to filter out obvious false positives. This happens before developers are notified, so that we can prevent posting PR comments that would annoy devs, and instead just hold those notifications for review by an AppSec team. This seems to help increase trust in the security tool overall, as devs are less likely to approach alerts with skepticism.
Second, things deemed true positives also come with specific AI-generated instructions on how to solve them. This is one of the parts where the 'surgical' approach helped immensely; we noticed that as humans we usually first try to find a past instance of someone successfully fixing a similar problem in git history, and we look at the project dependencies to see what libraries are readily available. So both these are included in the context we pass in the prompt, which leads to some very impressive code generation that uses even internal libraries correctly when it's required to sanitize data, for example.
The most recent addition to this whole system is our memories system though. When users triage findings and leave comments such as "Anything under the /dashboard/ prefix is internal access only", Semgrep Assistant parses this for information it might want to learn to apply to triage decisions or fix instructions, and checks if these new facts apply to existing findings you already had in the backlog. We had a customer whose backlog was cut by around 40% by adding just 4-5 memories that explain common reasons vulns do not apply in their environment.
I know it's a saturated space but my team believes our approach is actually useful, so we're expecting comments written with some suspicion but optimistic we can convince some of there's something real[0] here (:
[0]: https://semgrep.dev/blog/2024/does-your-llm-thing-work-how-w...
