By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
ToolAccuracy of FindingsDetects Non-Pattern-Based Issues?Coverage of SAST FindingsSpeed of ScanningUsability & Dev Experience
DryRun SecurityVery high – caught multiple critical issues missed by othersYes – context-based analysis, logic flaws & SSRFBroad coverage of standard vulns, logic flaws, and extendableNear real-time PR feedback
Snyk CodeHigh on well-known patterns (SQLi, XSS), but misses other categoriesLimited – AI-based, focuses on recognized vulnerabilitiesGood coverage of standard vulns; may miss SSRF or advanced auth logic issuesFast, often near PR speedDecent GitHub integration, but rules are a black box
GitHub Advanced Security (CodeQL)Very high precision for known queries, low false positivesPartial – strong dataflow for known issues, needs custom queriesGood for SQLi and XSS but logic flaws require advanced CodeQL experience.Moderate to slow (GitHub Action based)Requires CodeQL expertise for custom logic
SemgrepMedium, but there is a good community for adding rulesPrimarily pattern-based with limited dataflowDecent coverage with the right rules, can still miss advanced logic or SSRFFast scansHas custom rules, but dev teams must maintain them
SonarQubeLow – misses serious issues in our testingLimited – mostly pattern-based, code quality orientedBasic coverage for standard vulns, many hotspots require manual reviewModerate, usually in CIDashboard-based approach, can pass “quality gate” despite real vulns
Vulnerability ClassSnyk (partial)GitHub (CodeQL) (partial)SemgrepSonarQubeDryRun Security
SQL Injection
*
Cross-Site Scripting (XSS)
SSRF
Auth Flaw / IDOR
User Enumeration
Hardcoded Token
ToolAccuracy of FindingsDetects Non-Pattern-Based Issues?Coverage of C# VulnerabilitiesScan SpeedDeveloper Experience
DryRun Security
Very high – caught all critical flaws missed by others
Yes – context-based analysis finds logic errors, auth flaws, etc.
Broad coverage of OWASP Top 10 vulns plus business logic issuesNear real-time (PR comment within seconds)Clear single PR comment with detailed insights; no config or custom scripts needed
Snyk CodeHigh on known patterns (SQLi, XSS), but misses logic/flow bugsLimited – focuses on recognizable vulnerability patterns
Good for standard vulns; may miss SSRF or auth logic issues 
Fast (integrates into PR checks)Decent GitHub integration, but rules are a black box (no easy customization)
GitHub Advanced Security (CodeQL)Low - missed everything except SQL InjectionMostly pattern-basedLow – only discovered SQL InjectionSlowest of all but finished in 1 minuteConcise annotation with a suggested fix and optional auto-remedation
SemgrepMedium – finds common issues with community rules, some missesPrimarily pattern-based, limited data flow analysis
Decent coverage with the right rules; misses advanced logic flaws 
Very fast (runs as lightweight CI)Custom rules possible, but require maintenance and security expertise
SonarQube
Low – missed serious issues in our testing
Mostly pattern-based (code quality focus)Basic coverage for known vulns; many issues flagged as “hotspots” require manual review Moderate (runs in CI/CD pipeline)Results in dashboard; risk of false sense of security if quality gate passes despite vulnerabilities
Vulnerability ClassSnyk CodeGitHub Advanced Security (CodeQL)SemgrepSonarQubeDryRun Security
SQL Injection (SQLi)
Cross-Site Scripting (XSS)
Server-Side Request Forgery (SSRF)
Auth Logic/IDOR
User Enumeration
Hardcoded Credentials
VulnerabilityDryRun SecuritySemgrepGitHub CodeQLSonarQubeSnyk Code
1. Remote Code Execution via Unsafe Deserialization
2. Code Injection via eval() Usage
3. SQL Injection in a Raw Database Query
4. Weak Encryption (AES ECB Mode)
5. Broken Access Control / Logic Flaw in Authentication
Total Found5/53/51/51/50/5
VulnerabilityDryRun SecuritySnykCodeQLSonarQubeSemgrep
Server-Side Request Forgery (SSRF)
(Hotspot)
Cross-Site Scripting (XSS)
SQL Injection (SQLi)
IDOR / Broken Access Control
Invalid Token Validation Logic
Broken Email Verification Logic
DimensionWhy It Matters
Surface
Entry points & data sources highlight tainted flows early.
Language
Code idioms reveal hidden sinks and framework quirks.
Intent
What is the purpose of the code being changed/added?
Design
Robustness and resilience of changing code.
Environment
Libraries, build flags, and infra metadata flag, infrastructure (IaC) all give clues around the risks in changing code.
KPIPattern-Based SASTDryRun CSA
Mean Time to Regex
3–8 hrs per noisy finding set
Not required
Mean Time to Context
N/A
< 1 min
False-Positive Rate
50–85 %< 5 %
Logic-Flaw Detection
< 5 %
90%+
Severity
CriticalHigh
Location
utils/authorization.py :L118
utils/authorization.py :L49 & L82 & L164
Issue
JWT Algorithm Confusion Attack:
jwt.decode() selects the algorithm from unverified JWT headers.
Insecure OIDC Endpoint Communication:
urllib.request.urlopen called without explicit TLS/CA handling.
Impact
Complete auth bypass (switch RS256→HS256, forge tokens with public key as HMAC secret).
Susceptible to MITM if default SSL behavior is weakened or cert store compromised.
Remediation
Replace the dynamic algorithm selection with a fixed, expected algorithm list. Change line 118 from algorithms=[unverified_header.get('alg', 'RS256')] to algorithms=['RS256'] to only accept RS256 tokens. Add algorithm validation before token verification to ensure the header algorithm matches expected values.
Create a secure SSL context using ssl.create_default_context() with proper certificate verification. Configure explicit timeout values for all HTTP requests to prevent hanging connections. Add explicit SSL/TLS configuration by creating an HTTPSHandler with the secure SSL context. Implement proper error handling specifically for SSL certificate validation failures.
Key Insight
This vulnerability arises from trusting an unverified portion of the JWT to determine the verification method itself
This vulnerability stems from a lack of explicit secure communication practices, leaving the application reliant on potentially weak default behaviors.
DryRun Security News
January 15, 2026

Why I Joined DryRun Security

Security teams cannot keep up with the scope and pace of product development. Code velocity continues to rise, and AI-assisted development is pushing it even faster. I joined DryRun Security because the company is tackling that reality head-on, with a product and a team I trust.

Hi, I’m Justin Collins. I previously served as CISO at Gusto, worked in the application security trenches at SurveyMonkey and Twitter, and now I’ve joined DryRun Security as a Principal AI Security Researcher. I also created and maintain Brakeman, a free static analysis security scanner for Ruby on Rails. I had the opportunity to use DryRun Security at Gusto as a customer, and it’s exciting to be able to join the team!

The problem I keep running into

Most AppSec teams are small, but the development org they support is not. That gap shows up every day as an unending stream of pull requests, new features, new dependencies, new technologies, and… of course new attack paths and systemic risk.

Traditional tooling can help, but it often asks security teams to become full-time toolsmiths. Building useful automation usually means writing and maintaining custom rules, tuning language-specific configurations, and constantly fighting false positives. In the real world, teams get the basics running, then move on. They do not have time to build deep, custom coverage for every language and framework.

AI is making that gap worse. Developers now ship code in languages and frameworks they have never used before. That is powerful, and it changes the risk profile. Security teams cannot hire fast enough or build expertise fast enough to keep up with that output.

Why DryRun Security

DryRun is taking a practical approach to scaling AppSec. Instead of forcing every guardrail into brittle pattern matching, it lets teams express intent in natural language and enforce it in code review through Natural Language Code Policies, powered by its proprietary Contextual Security Analysis engine. If I can say, “Here’s the problem I’m seeing,” I want the system to find it, explain it, and help stop risky changes before they land.

Most organizations also need a two-tier security workflow. First, fast automated blocking or feedback for clear vulnerabilities. Second, high-signal notifications for the architectural and strategic issues that still need human judgment.

That balance is what I believe AppSec needs right now. Enable velocity, and focus human time where conversations and guidance actually reduce risk.

I also joined because of the founders. If anyone is going to get this right, these are the people I trust to get it done. Ken and James are building from a problem-first mindset. They deeply understand and care about the pain AppSec teams live with, not just the market category.

That reminds me a lot of the leadership team at Gusto who brought passion for small business problems to work every day. The best products I have seen come from teams who start with lived experience and build to solve those problems for their customers.

What I will focus on

As Principal AI Security Researcher, I will focus on how AI changes software risk and how we help teams with insights move faster. We’re delivering Code Security Intelligence so that AppSec teams see and prevent risk and development teams ship code without fear. That means improving how we identify what should be automated, when a human should be in the loop, and how we empower people with the information they need.

If you are facing the same tension between shipping faster and staying secure, I would love to compare notes. We’re all on the AI journey, and DryRun Security is in an excellent position to enable it.

Learn more about DryRun Security.

Ready to see it in action on your code? Get a demo.