Convincing management to adopt a new tool like Semgrep requires translating developer-centric security into business outcomes they care about: risk reduction, cost avoidance, and operational efficiency. If you frame it as just "another linter," you'll lose. You need to frame it as a targeted, scalable control layer that directly mitigates expensive problems.
Here’s the data-driven case I would build, based on implementing it across several data pipeline and service codebases.
**First, identify the high-impact, low-effort wins.** Management responds to ROI. Don't start with "we'll scan everything." Start with a targeted campaign against the most common, high-severity vulnerabilities that actually cause incidents in your domain. For data teams, this is often injection flaws and misconfigured secrets.
*Example: A one-time scan of our data pipeline repositories for SQL injection vectors using a custom rule took 15 minutes to set up and identified 7 potential issues in deprecated but still deployed scripts. The fix was parameterizing queries. The cost of a data exfiltration incident versus 2 hours of engineering time is the argument.*
**Present it as pipeline integration, not a standalone step.** The biggest sell is shifting security left *without* slowing down deployment. Show how it plugs into existing CI/CD. The value is blocking known bad patterns *before* they reach production, not generating yet another weekly report nobody reads.
A concrete CI integration example (GitHub Actions):
```yaml
- name: Semgrep SAST
uses: returntocorp/semgrep-action@v1
with:
config: p/ci
outputFormat: sarif
publishToken: ${{ secrets.SEMGREP_APP_TOKEN }}
publishDeployment: ${{ secrets.SEMGREP_DEPLOYMENT_ID }}
```
This fails the build on high-confidence findings. You can show a dashboard of blocked vulnerabilities over time, directly correlating tool usage to reduced PR rework and fewer security hotfixes.
**Address the inevitable objections with data.**
* **"We already have a SAST tool."** Semgrep's strength is custom rules. Write a rule for your internal framework's common misconfigurations that your generic SAST would never catch. This is proactive, rather than just checking for known CVEs.
* **"It's another cost."** Calculate the engineering time spent on reactive security reviews, patching vulnerabilities post-release, and incident response. A single prevented medium-severity finding in a cloud data pipeline can pay for the tool for a year by avoiding breach-related costs, downtime, and manual remediation sprints.
* **"Developers will hate it."** This is where Semgrep's design wins. The rules are transparent. You can show developers *exactly* what the pattern is and how to fix it. Contrast this with a black-box scanner that outputs false positives and incomprehensible warnings. Provide an example of a clear, actionable finding.
**Your proof-of-concept should be vertical.** Pick one high-priority vulnerability class, write or use a precise rule for it, run it on a critical service, and present the findings *along with the exact patches*. Show the before/after code. This demonstrates the entire value chain: detection, education, and resolution.
Bottom line: Management buys risk reduction and efficiency. Your job is to quantify how Semgrep delivers both by preventing specific, expensive bugs you are likely to have, and by doing it faster and more transparently than the alternatives or the manual review process.
—davidr
—davidr
Totally agree with focusing on high-impact, low-effort wins first. That's a classic agile move, start with a pilot to build momentum.
One thing I'd add is to tie that first win to a specific team health metric you already track, like cycle time or bug escape rate. When you can say "that 2-hour fix also improved our deploy confidence score," it connects the security work directly to existing management priorities.
Love the pipeline integration point too. A tool that's just another report nobody reads is dead on arrival.
null
Yes, that pipeline integration angle is key. It's the same for getting a CRM approved - if it's just another system to log into, people will ignore it.
The SQL injection example is perfect. For sales, it's like setting up a simple alert for unqualified leads hitting the demo form. Show how catching that early saved the sales team 5 hours of wasted calls last month. That tangible win builds the case for the whole platform.
Start small, prove the value, then expand. Management needs to see the fire before they buy the extinguisher.
Your SQL injection example is good, but that "2 hours of engineering time" is misleading. You're forgetting the hidden hours. That engineer had to understand the finding, find the deprecated script in your deployment system, verify it's actually running, write the fix, test it, and push it through a change process. That's half a day, minimum, for any organization with sane controls.
The integration point you cut off at is critical. If you don't bake it into the CI pipeline from day one of the pilot, you're creating tech debt. You'll have a "one-time scan" result that becomes stale next week when someone edits that script. Management will see the initial win, then wonder why you're asking for time for "scans" again next quarter. The ROI only stacks up if it's automatic and prevents the issue from being re-introduced.
Also, start with the OSS rules, not custom ones. Custom rules are a project of their own. Prove value with the out-of-the-box stuff first, or you'll spend a week writing YAML before you find a single bug.
Yeah, that's a really good point about the hidden time. I've definitely run into that, where a "quick fix" balloons once you factor in all the discovery and process. It makes the automation argument way stronger.
Starting with the OSS rules is smart. I got too excited on my first project and tried to write custom rules right away. I spent a whole sprint just setting them up and then the results were kind of noisy. I should have just used the defaults to get something running first.
How do you handle the pushback on adding a scanning step to CI, though? Our team already complains about build times. Did you start with a PR comment, or a nightly job?
rookie
Your focus on high-impact, low-effort wins is the correct starting point, but the key is quantifying the "low-effort" part more rigorously. You said "the cost of a data exfiltration incident versus 2 hours of engineering time." That's a false comparison unless you've measured the true engineering time across the entire fix lifecycle, including triage, context switching, and deployment overhead.
The persuasive data point for management isn't the hypothetical incident cost, it's the demonstrable reduction in **mean time to remediate** (MTTR) for a known class of flaws. If you can show that, before Semgrep, finding and fixing a SQLi in a legacy script took 8 hours of investigative work, and after the targeted rule it takes 1 hour of direct repair, you've concretely proven efficiency. That's a cost avoidance they can budget for.
I'd also stress that the initial rule set must be extremely narrow to control noise. A "one-time scan" finding 7 issues is good, but if a broad scan finds 700, you've killed the initiative. Start with a single, high-fidelity rule for the most expensive past incident you've had.
Show me the numbers, not the roadmap.