I need to vent. Our security tools are making me less productive, less engaged with security, and honestly making our codebase LESS secure because I’ve started ignoring security warnings entirely.
This isn’t a security team problem. This is a tooling problem. And I think we can do better.
The Current State: Death by A Thousand Alerts
Here’s what my typical PR workflow looks like:
Monday 10am: Open PR for new feature (authentication flow for social login)
Monday 10:15am: CI/CD security checks start running
Monday 11:30am: Security checks complete. PR blocked.
Alerts:
- Semgrep: 12 findings (8 HIGH, 4 MEDIUM)
- Snyk: 23 vulnerabilities (15 HIGH, 5 CRITICAL, 3 MEDIUM)
- CodeQL: 6 potential issues
- Trivy: 18 container vulnerabilities
- SonarQube: 31 code smells, 4 security hotspots
Total: 94 security issues flagged
My reaction: Despair.
The False Positive Problem
Here’s what happened when I investigated those 94 issues:
Actually Critical (need to fix): 3
- SQL injection risk in new login endpoint
- Exposed API key in test file
- Outdated auth library with known exploit
False Positives or Irrelevant (don’t apply to my code): 87
- “Potential XSS” in admin-only debug code
- “Weak cryptography” in test mocks
- “Hardcoded secret” (it’s the string “password” in a comment)
- Dependencies flagged by 3 different tools (counted 3x)
- Container base image issues (I don’t control the base image)
- Code smells that aren’t security issues
Low Priority (theoretical issues with no real risk): 4
- Possible DoS if attacker sends 10,000 requests (we have rate limiting)
- Information disclosure in error messages (no sensitive data exposed)
So: 3% signal, 97% noise.
Why I Started Ignoring Security Warnings
I’m embarrassed to admit this, but after 6 months of this, I now do this:
- Open PR
- See 94 security alerts
- Scan for anything with “authentication” or “injection” in the title
- Fix those (if they look real)
- Click “Request Security Bypass” for the rest
- Move on with my life
This is bad. I know it’s bad. But the alternative is spending 4 hours investigating alerts where 90% are false positives.
What Makes Security Tools Frustrating
1. Cryptic Error Messages
Tool says:
What I need to know:
- What specific line of code is the problem?
- What user input reaches this code?
- What’s the actual attack vector?
- How do I fix it?
- Is this actually exploitable in my context?
Security tools are written for security engineers, not developers.
2. No Remediation Guidance
Tool says: “Vulnerability: lodash prototype pollution CVE-2025-12345”
What I need:
- Upgrade to lodash 4.17.21 → one-click apply fix
- Or: This vulnerability is not reachable in your code because you don’t use the affected method
- Or: Alternative package with same functionality: lodash-es
“Vulnerability detected” without fix guidance is just anxiety-inducing noise.
3. Can’t Distinguish Critical from Noise
Every tool has its own severity scoring. Some findings are marked HIGH that are clearly LOW risk.
Example: “Hardcoded password detected: ‘password123’”
Context: That’s literally the string “password123” in a test case checking password validation.
The tool has no context awareness.
4. Different Tools Contradict Each Other
Semgrep: “This SQL query is safe (parameterized)”
CodeQL: “This SQL query is vulnerable (CWE-89)”
Which one is right? As a developer, I have no idea. So I request bypass for both and move on.
5. No Integration with My Workflow
I live in VS Code and GitHub. Security findings are in:
- Separate Snyk dashboard
- Separate Semgrep dashboard
- SonarQube web UI
- Email alerts
- Slack notifications
I have to context-switch to 5 different tools to understand my security posture. That’s never going to happen consistently.
What Good Security Tooling Looks Like
I don’t have all the answers, but here’s what would make me actually engage with security:
1. Explain the Actual Risk (Not Just CVE Numbers)
Bad: “CVE-2025-12345: CVSS Score 8.5”
Good: “An attacker could bypass authentication by sending a specially crafted JWT token, gaining access to user accounts. This affects your /api/login endpoint which is publicly accessible.”
Context. Attack vector. Business impact. In plain language.
2. Actionable Fix Suggestions
Bad: “Vulnerability in [email protected]”
Good:
npm install [email protected]
One click to fix. Or better, auto-fix with a PR I can review and merge.
3. Smart Prioritization Based on Reachability
Instead of: 94 alerts, all marked HIGH
Show me:
- 3 CRITICAL (exploitable from public API, affects authentication)
- 8 HIGH (exploitable but requires authentication)
- 23 MEDIUM (exploitable but low likelihood or low impact)
- 60 LOW (not reachable, theoretical only)
I can fix 3 critical issues today. I cannot fix 94 issues today.
4. IDE Integration (Pre-Commit Feedback)
Show me security issues in VS Code as I write code:
- Red squiggly under unsafe SQL query
- Hover: “SQL injection risk. Use parameterized query.”
- Quick fix: Auto-refactor to use parameterized query
This is how linters and type checkers work. Security should work the same way.
5. Reduce False Positives Ruthlessly
I’d rather have 10 high-confidence findings than 100 maybe-issues.
Security teams should tune tools aggressively:
- Suppress findings that are false positives for our codebase
- Customize rules to understand our architecture
- Exclude test code, generated code, vendored code from scanning
Quality over quantity.
Why This Matters for Security Outcomes
When security tools are frustrating:
- Developers ignore them (I’m proof)
- Security bypasses become routine
- Real issues get lost in noise
- Developer-security relationship becomes adversarial
When security tools are helpful:
- Developers actually pay attention
- Issues get fixed faster
- Security becomes part of development culture
- Everyone’s safer
Right now, security tools optimize for finding more vulnerabilities. They should optimize for fixing critical vulnerabilities faster.
Tools That Are Getting It Right
A few tools I’ve seen that have better developer experience:
Snyk (sometimes):
- Shows dependencies with known fixes
- Can auto-PR dependency updates
- Explains vulnerability impact
GitHub Advanced Security:
- Integrated into GitHub UI (no context switching)
- Inline annotations on PR diffs
- Helpful documentation links
Semgrep (when tuned):
- Customizable rules
- Fast execution
- Clear error messages
But even these generate too much noise without tuning.
My Questions for Security Teams
1. Do you measure developer engagement with security tools?
- What percentage of security findings do developers fix vs bypass?
- How long does it take developers to respond to security alerts?
- Developer satisfaction with security tools (survey)?
2. Do you know your false positive rate?
- Of 100 HIGH severity findings, how many are actually exploitable?
- Are you tuning tools to reduce false positives?
3. Have you talked to developers about what would make security tools more usable?
- User research on security tool workflows
- Usability testing with actual developers
- Feedback loops to improve tools
What I’m Committing To
I recognize I’m part of the problem. Ignoring security warnings is irresponsible.
Here’s what I’m going to do differently:
1. Talk to security team about tuning tools
- Share examples of false positives
- Help configure rules for our codebase
- Provide feedback on what’s helpful vs noise
2. Set aside time for security review
- Dedicate 1 hour per week to security findings
- Fix at least 3 high-priority issues per sprint
- Don’t request bypass without investigation
3. Learn security fundamentals
- Take OWASP Top 10 course
- Learn to read security tool output better
- Understand common vulnerability patterns
But I need security teams to meet me halfway:
Security teams: Make your tools respect developer time. Every alert should be worth interrupting someone’s focus. Every finding should be actionable.
If security tools become helpful instead of frustrating, developers will actually use them. And that’s when we’ll get real improvements in security.
Who else is frustrated with security tooling? What would make it better?