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.
AI in AppSec
May 20, 2026

Nobody Makes Their Own Screws Anymore

How AI is transforming software engineering from handcrafted trade to managed autonomous systems.
By Ken Johnson, CTO & Co-Founder of DryRun Security

I've been around computers for over 30 years. My interest started when I was around 10 years old. Professionally, I've been doing this since I was 19 (24 years ago).

Back then, my actual job was network engineering. My PASSION was hacking. And when I say hacking, I don't mean posting screenshots from Burp Suite on LinkedIn while talking about "shifting left." I mean old-school offensive security culture. Tiny communities. IRC channels. Trading notes and software with people you didn't know, had never seen, and probably never would.

There weren't cybersecurity degrees. Heck, "cybersecurity" didn't exist as an industry. Now I meet cybersecurity graduates who don't know what Metasploit is.

Shudders in 1337.

But honestly? This is what always happens. A small group of obsessed weirdos build a discipline. Then tooling and access to information improve. A new job market surfaces. The industry scales. Abstractions rise. Money pours in. Conferences appear. Certifications happen. The field industrializes. Eventually most practitioners stop being artisans and become operators.

That's not me insulting anybody. That's just how industries evolve. I am a weirdo who turned into an operator. It's fine. It's natural, even.

Nobody makes their own screws anymore.

At one point, craftsmen did. Today screws are standardized, mass produced, abstracted away. Nobody building a house or a car sits around lovingly handcrafting fasteners. Mature industries stop obsessing over handcrafted primitives and start optimizing systems, throughput, reliability, and operations.

Software engineering is heading in the exact same direction.

The Artisanal Era of Software Engineering Is Ending

There's this romantic idea floating around engineering that software development is fundamentally handcrafted intellectual artistry. Sometimes it is. Most of the time it absolutely is not.

Most security engineers are not discovering entirely new classes of vulnerabilities. Most software engineers are not inventing databases. They are not writing operating systems or building elegant distributed consensus algorithms by candlelight while sipping pour-over coffee and listening to a podcast about software craftsmanship.

Most companies are trying to ship products. And most engineers, historically, were already doing production work: CRUD apps, internal systems, APIs, business logic, integrations, operational software. Valuable work, absolutely. But not artisanal mastery if we're being honest with ourselves.

AI is not creating this reality. It's exposing it.

The handcrafted era of software engineering isn't disappearing because AI suddenly became magical. It's disappearing because the economics of software delivery are changing and because most engineering organizations were already optimizing for throughput long before AI showed up. The difference now is that the abstractions are getting good enough to absorb larger portions of the labor.

And I think people are still underestimating what that means.

The Future of Engineering Looks More Like an Amazon Warehouse

If you want to understand where software engineering is heading, stop thinking about science fiction and start looking at modern warehouses.

Amazon warehouses are full of automation. Some are nearly entirely autonomous. Robots move products. Systems optimize routing. Machines coordinate massive amounts of operational work. But humans are still there. Not because the robots failed. Because highly autonomous systems still require:

  • Oversight
  • Governance
  • Exception handling
  • Troubleshooting
  • Optimization
  • Safety controls
  • Operational management

That's the future I see for engineering. Not one super-intelligent AI replacing the entire engineering department. A managed autonomous workforce.

You'll have fleets of specialized agents:

  • Software engineering agents
  • Security agents
  • QA agents
  • SRE agents
  • Compliance agents
  • Functional review agents
  • Functional testing agents
  • … ready for it…. perhaps even PM agents!

Each with their own tooling, rules, context systems, memory models, skills, MCP integrations, evaluation pipelines, and operational constraints. And humans overseeing all of it. Not writing every line themselves. Managing the factory floor.

We're Already Living Inside This Transition

At DryRun Security, we already see engineering teams shipping significantly more work through AI-assisted editors and autonomous tooling. For VERY small, VERY low-risk changes, we'll literally assign issues to bots. Not as a joke. Not as a demo. As operational reality.

Here is the catch though… We use internally developed skills, rules, review systems, QA processes, security validation, and automation pipelines to govern how those systems behave. We still require human beings to attest that the non-human entities have done their work, correctly before that code will ever reach production.

And increasingly the pattern looks like this:

  • A human drafts the design or intent.
  • Autonomous systems implement large portions of the work.
  • Specialized agents review the output.
  • Humans validate that the systems behaved correctly.

That last part matters more than people realize. Because these systems drift constantly. This is one of the things people outside the operational reality of AI development still massively underestimate.

The newest model is not always better.

Sometimes performance gets worse. Sometimes behavior changes in subtle ways. Sometimes tools regress. Sometimes context handling degrades. Sometimes workflows that worked yesterday suddenly become unreliable because a model version changed, a tool changed, a memory system changed, or somebody decided skills are dead and now everything needs to be a "flippedy-widget".

Honestly, parts of the industry are a complete mess right now. Everyone is racing to standardize systems while simultaneously inventing the systems they're trying to standardize.

Rules became Claude files. Claude files became skills. Skills became agentic workflows. MCPs appeared. Now everyone is building portable agent ecosystems while praying the next model update doesn't light the entire workflow on fire. This is not a stable ecosystem yet. Which is exactly why human oversight becomes more important, not less.

The Real Job Is Becoming Governance

The future engineer will spend less time manually producing code and more time:

  • validating systems
  • reviewing outputs
  • managing context
  • tuning workflows
  • debugging autonomous behavior
  • handling exceptions
  • governing operational pipelines
  • and maintaining institutional knowledge

That last part is critical. Institutional knowledge is becoming machine-consumable infrastructure. Every organization is trying to encode their engineering standards, security practices, architecture decisions, operational processes, business logic, testing expectations, review patterns, and deployment safety rules into autonomous systems. And somebody has to own that.

I believe domain experts will increasingly manage domain-specific agentic workforces. Security experts managing security agents. SREs managing operational agents. QA experts managing testing fleets. Engineering leaders managing software delivery systems.

Not just prompts. Everything: models, reinforcement learning strategies, retrieval systems, skills, memory, context optimization, tool access, evaluation pipelines, governance controls, and cost management.

Because these systems behave less like deterministic software and more like employees. Highly productive employees. But employees nonetheless.

The Industry Is Moving Too Fast, Not Too Slow

One thing I don't actually believe is that the industry is resisting this transition. If anything, the opposite is happening. The bigger risk is companies going all in too fast.

People are wildly over-trusting systems they barely understand operationally. And the stakes matter. If your AI screws up a landing page headline, who cares. If your autonomous systems are touching financial systems, healthcare platforms, critical infrastructure, authentication, authorization, industrial controls, or medical devices, the consequences stop being theoretical very quickly.

Which means autonomous delivery requires governance. We're going to need:

  • versioned skills and rules
  • allow-listed tooling
  • supply chain controls for MCPs and agent ecosystems
  • evaluation frameworks
  • observability into agent behavior
  • rollback capabilities
  • auditability
  • verification systems
  • and probably entirely new operational disciplines

Because yes, all the same supply chain disasters from package managers are absolutely coming for agent ecosystems too. Of course they are. Humans built those ecosystems too.

Juniors Will Learn Differently

I also think education itself is going to struggle badly with this transition. Honestly, I already think most education systems are flawed. We teach people fundamentals, then test memorization and deduction through standardized testing, while often failing to teach them how to use the actual tools they'll depend on professionally every day.

Imagine training (Building) architects how to design a building without teaching them CAD. You don't have to imagine because people right now are going six figures into debt for the privilege of that "education" (but I'll save my full rant on traditional education for a later date). That's effectively what a lot of engineering education still looks like.

Now, fundamentals still matter. The OSI model still matters. Systems thinking still matters. Networking still matters. Architecture still matters. But the operational interface to engineering is changing.

Most people will learn on the job, inside autonomous systems, while learning how those systems fail, drift, optimize poorly, hallucinate, and break under pressure. The higher-level engineer becomes the person who understands ambiguity, system behavior, scalability and performance, interconnected failures, optimization tradeoffs, and operational governance. Not necessarily the person manually typing the most code.

The typing was never the valuable part anyway.

The Deep Experts Aren't Going Away

There will still be exceptional engineers: researchers, exploit developers, compiler experts, distributed systems experts, people solving genuinely difficult computer science issues, people discovering entirely new classes of problems.

Just like there are still elite security researchers today. But most industries eventually industrialize around the work that happens 95% of the time. That's what's happening to software engineering now. Not because software engineering stopped mattering. Software is the infrastructure for today's civilization. And infrastructure eventually must be operationalized.

Nobody makes their own screws anymore. And soon, very few people will handcraft software either.