DryRun Security

Are you looking for an AI-native approach to SAST? It can be challenging to determine the efficacy of tools, and it's difficult to discern from marketing sites which tools are AI-native versus those that incorporate AI into a legacy, regex-based approach. Don't worry, I've got you covered. We realized that not all SAST tools are created equal—accuracy (i.e., finding true vulnerabilities without swamping teams with false positives) is the key differentiator. We created the 2025 SAST Accuracy Report ( 🔗 link to report in the comments) This report compares the accuracy of five prominent tools—DryRun Security, Semgrep, Snyk Code, GitHub Advanced Security (CodeQL), and SonarQube / SonarCloud. The comparison is based on head-to-head public tests in Ruby, Python, C#, and Java. The report findings demonstrate how these solutions address both traditional application security issues and more complex logic flaws such as IDOR, BOLA, and business-logic errors. All of the tested tools advertise AI-augmented capabilities, but only DryRun Security provides an AI-native approach to detection. Check the comments for a link to the full, ungated report.

If you think your LLM makes your code secure, you’ve already lost. Code generation isn’t code security. Understanding risk and context is. That’s the difference Code Security Intelligence makes. I wrote this blog post to draw a clear line between using LLMs for security vs. assuming LLMs are security. At DryRun, we use advanced LLMs as part of our Code Security Intelligence solution which orchestrates our code review agents much like a human reviewer. LLMs can help understand code, patterns, and intent, but context, policy, and risk analysis require more than a base frontier model can provide. The post explains why relying solely on your coding assistant for security is a category error and how true AppSec intelligence uses AI to reason about code the way a seasoned security engineer would. Check out the post or hit me up if you want to chat about AI and security! https://lnkd.in/gEBaXvwp

Story time. Almost every school day, I’d walk my kids from the parking lot to the front doors. But the sidewalk ended about 20 feet too soon. The last stretch was grass, dirt, or, on rainy days... mud. Then one summer, something amazing happened: they paved it. Suddenly, no more off-roading with backpacks and kids in tow. It was smoother, safer, and faster. That’s the beauty of a paved path. I first heard the phrase from friends like Jason Chan, Adrian Cockcroft, Damon Edwards, Gene Kim, Patrick Debois, and John Willis in the DevOps community. A “paved path” is how teams ship software faster and with fewer defects—by creating a clear, supported, default route for everyone to follow. But here’s the thing: security has rarely been part of that path. It’s usually bolted on, lobbed in, or hidden under the buzzword of “Shift Left.” Helpful at times, but it never quite achieves the paved path ideal. At DryRun Security, we’re changing that. We’ve built Contextual Security Agents—a team of AI-powered AppSec agents that dryrun your code before it ships. They enforce policy, detect vulnerabilities (including logic flaws most tools miss), and provide real insight that appsec & eng teams need. With DryRun Security, security is the paved path. Which means teams can finally ship secure software by default, not as an afterthought.

This is a new raft of tooling and companies that are being created because the hardest problems in appsec today are context-dependent. Let's parse that a bit. AI‑Native SAST solutions are built from the ground up with artificial intelligence at their core. These systems analyze code changes in near real time, incorporating multiple contextual layers such as code type, developer intent, architectural design, and runtime environment. This holistic understanding enables them to detect complex logic vulnerabilities, such as Insecure Direct Object References (IDOR), Authz issues, enumeration issues, and logic flaws. These tools continuously learn and improve based on developer interactions, resulting in more precise findings over time. Notable players in this space include DryRun Security's Contextual Security Analysis, Pixee's remediation-focused tooling, Mobb’s CI-integrated fix engine, and Corgea’s AI-first detection platform. In contrast, SAST + AI tools are traditional pattern-matching scanners retrofitted with gen-AI layers. Detection remains largely dependent on regular expressions or abstract syntax tree (AST) signatures. After the scan, a language model may reword findings or propose generic patches. Because these models lack visibility into broader architectural context or user flows, they often fail to detect deeper risks. Snyk Code with Autofix, Semgrep’s AI Assist, and SonarQube’s Clean Code AI exemplify this retrofit approach. At DryRun Security we're very excited about what we're accomplishing for customers. If you struggle with context-dependent appsec issues, I'd encourage you to give AI-native SAST a serious look. I've never been more excited to be in AppSec than I am right now. also, if you read this far: thanks! I wrote a full blog post on this topic, and I'll link it in the comments.

Pattern-Matching SAST is Dead. Long Live Context. Copy/paste prompt included to prove it. Ever wondered how many critical bugs your regex-driven scanner is quietly skipping? Use the below prompt and drop the generated snippets into PRs, and run your Static Application Security Testing (SAST) tool. I’ll bet you a BBQ lunch you’re about to find some blind spots. When you’re done, share your outcomes—because the future of AppSec isn’t pattern-matching, it’s context. ↓ Copy this prompt ↓ ~~~ START OF PROMPT ~~~ You are a senior application-security educator creating demo code. Mission: Produce 3 minimal code snippets suitable for separate pull requests (PRs) against a fork of a sample app available at github.com/<project_name> that each introduce a realistic application security flaw. Use the language or framework of the sample app to produce a realistic application security flaw. (For example, use node/express and ts for an OWASP Juice Shop fork). Try to avoid detection of pattern-matching SAST tooling that might be in place. So, in the case of a realistic IDOR flaw, which has object-level authorization missing, letting one user access another’s data, you might consider the following constraints. Evasion constraints (to dodge pattern-matching SAST): 1. Avoid the strings: id, userId, owner, accountId, getUser 2. Obfuscate key fields via base64/hex or an innocuous alias. 3. Keep each snippet ≤ 25 lines; single-purpose functions. 4. Add a comment that looks like a harmless refactor. Order of operations: Before you start, collect the sample app github url and ask the user what type of flaw, suggest IDOR, resource enumeration, SQLi, or XSS if the user isn't sure. Output format: ### Snippet {n} \`\`\`<language> // code here \`\`\` _Where and how to add this PR to the code: <one sentence>_ _Why pattern-based SAST rules miss it: <one sentence>_ ~~~ END OF PROMPT ~~~ #appsec #SAST #ContextualSecurityAnalysis #DevOps #DevSecOps

Pattern-matching SAST tools are built to catch the obvious. They light up on known patterns, bury teams in false positives, and still miss the flaws that actually get exploited. Think IDOR, broken auth, and business logic issues. That is why we built Contextual Security Analysis at DryRun Security. Instead of chasing regexes, CSA reasons about code in context. It reviews code the way your best AppSec engineer would. In our SAST Accuracy Report, we put five tools head-to-head across Rails, Django, .NET, and Spring. DryRun Security detected 23 of 26 seeded vulnerability samples. That is about 88 percent, including nearly all the logic flaws. The next best tool caught less than half. If you are still relying on pattern matching alone, this report makes the case for what you're missing and where the future of AppSec is heading.