You know the scenario: a mandate comes down from engineering leadership to "implement SAST," you spend weeks evaluating and rolling out a tool, and then... crickets. The reports pile up, un-triaged, and the team views the whole system as a chore that generates noise, not value. I've been there, and after guiding three different teams from resistance to adoption, I've settled on a workflow that turns this around. It's less about the *tool* and almost entirely about the *process* you wrap around it. The goal isn't to find every possible issue—it's to create a trusted, actionable stream of work.
The core issue is usually overwhelm. A fresh SAST run can generate thousands of findings. Presenting that directly to a feature team is a non-starter. Here’s my step-by-step approach to make the output consumable and, frankly, useful for developers.
**Phase 1: The Initial Triage (Security Team's Burden)**
Before a single developer sees a finding, the security or platform team *must* own the first filter. This is non-negotiable.
- **Suppress the universally noisy rules.** Every tool has them. Work with a small, trusted dev group to identify 3-5 rule patterns that are always false positives for your stack. Start there.
- **Establish a severity threshold for the first rollout.** Maybe you only surface "Critical" and "High" to start. "Medium" and "Low" stay in the security queue for now.
- **Context is king.** Manually review the first batch of top-severity findings. If a finding is valid, annotate it! Add a note like, "This looks real. The sink is in `payment_service.rb:123` and user input flows from `user_controller.rb:45`. Suggested fix: use `sanitize_input()` here."
**Phase 2: The Integration into Developer Workflow**
Now you have a curated list. Don't email it. Don't use a separate dashboard. Integrate it directly where they already work.
- **Leverage existing ticketing.** For each validated finding, create a ticket in their project management tool (Jira, Linear, etc.). The ticket must include: the file/line, the SAST rule name, a brief explanation of the *risk* (not just the flaw), and your annotated code snippet.
- **Automate the pipeline, but gate it.** Configure the SAST tool to run on every PR, but *do not* block merges initially. Instead, have it post a summary comment. Something like: "SAST scan detected 1 new potential issue. Review required: [Link to finding details]." This builds awareness without friction.
- **Start with a pilot group.** Choose one receptive team. Work with them to triage their initial backlog. Use their feedback to further refine your rule set and annotation templates.
**Phase 3: Building Trust & Ownership**
The pilot is where you prove value. Your job is to make it easy for them to succeed.
- **Host a 30-minute "fix-it" workshop.** Walk them through resolving 2-3 tickets. Show them how to use the tool's documentation to understand the finding.
- **Track and broadcast metrics that matter to *them*.** Not "vulnerabilities found." Track "Mean Time to Triage" and "Resolution Rate." Celebrate when the team closes their initial backlog.
- **Gradually shift left.** Once the process is trusted, you can start lowering the severity threshold you surface, and even enable pipeline blocking for critical, new findings on main branches.
The key mindset shift is this: you are not a police force sending tickets. You are a filtering and annotation service, making a high-volume signal useful for your colleagues. It takes upfront work from the security side, but that investment is what changes the entire dynamic. Start small, be generous with your context, and integrate, integrate, integrate.
Would love to hear what others have done in this space, especially around managing findings in monorepos—that adds another layer of complexity to the ownership question!
—Hannah
Measure twice, automate once.
Totally agree on suppressing the noisy rules first. What helped us was actually *sharing that list* with the devs and explaining *why* each rule was turned off. It built trust that we weren't just hiding problems, but curating signals.
It also stopped the "but it flagged this benign thing!" conversations before they started. We used a simple markdown file in the repo, and it became a living document they could comment on.
Prompt engineering is the new debugging