Coder Legion - Recent posts tagged applicationsecurity

Contrast Security: Triaging AI Scanner Output Costs 400x More Than Running the Scan

Thu, 27 Aug 2026 13:15:00 +0000

Here's a number worth sitting with: scanning a 2-million-line codebase with an AI-powered tool costs roughly $315 in tokens. Triaging what that scan finds costs $128,000. That 400x gap, buried in Contrast Security's new AppSec Overflow 2026 report, is a sharper indictment of "AI will solve your security backlog" than any headline vulnerability count. The scanning was never the expensive part. Making sense of what it found is.

Contrast's report draws on runtime telemetry from inside hundreds of thousands of production applications and APIs, giving it a vantage point most vendor research doesn't have: not what's theoretically vulnerable in a codebase, but what's actually being reached and exploited in live production. The headline framing is stark. "AppSec math is broken, and in 2026, AI is a massive contributing factor," the report states, and the numbers back that up from multiple directions at once.

The attack volume is relentless, but mostly noise

The average monitored application absorbs 11,382 attacks a month, roughly one every four minutes. That number sounds alarming until you break it down: 87.8% are automated probes, low-stakes reconnaissance that maps attack surfaces without doing harm. Another 11.9% are suspicious but unconfirmed. The number that actually matters is the remaining 0.4%, an average of 42 viable attacks per month per application, meaning Contrast confirmed the exploit reached and triggered real vulnerable code. No false positives in that category; runtime observation proves activation, not just exposure.

Untrusted deserialization leads the viable attack data at 27.5%, followed by path traversal at 20.1% and method tampering at 13.4%. SQL injection, despite being one of the most well-understood vulnerability classes in software, still shows up in the top five attack techniques across every industry vertical the report tracked, a reminder that "well documented" and "actually fixed" are very different things.

Why the find-and-fix model is structurally broken, not just slow

The average application carries 106 vulnerability findings in custom code, and while roughly 60% of those are informational noise, an average of 22 are rated high or critical. Teams are closing just 3.4 vulnerabilities per application per month, and the mean time to remediate a critical vulnerability sits at 92 days. Third-party code fares no better: 54% of the CVE instances Contrast observed in production are from vulnerabilities disclosed more than a year ago.

That gap matters more than it used to because the other side of the equation has collapsed. Third-party research the report cites, aggregated by Zero Day Clock across more than 83,000 CVEs, shows mean time-to-exploit dropping from 2.3 years in 2018 to effectively same-day in 2026. Independent data from VulnCheck backs the trend, finding 29% of exploited CVEs in 2025 were weaponized on or before the day the CVE was published. A 92-day patch cycle against a same-day exploitation window isn't a performance problem. It's a structural mismatch that faster patching alone can't close.

The AI scanning findings, and one claim worth a caveat

The report's most useful contribution isn't the vulnerability count, it's the honest accounting of what AI scanning tools actually deliver today. Beyond the $315-versus-$128,000 triage-cost gap, Contrast found that three different AI scanners analyzing the identical codebase agreed on only 5% of findings. A single scanner rerun three times against unchanged code reproduced just 17% of its own prior results. That's not a minor calibration issue; it's a fundamental reliability problem for any team trying to build a repeatable process around these tools. Contrast's own framing is blunt: "For now, it's making the hole a lot deeper."

Worth flagging separately: the report opens with a claim about Anthropic's Claude Mythos model reportedly discovering thousands of previously unknown zero-day vulnerabilities in production testing, including a flaw in OpenBSD that had survived 27 years of human review. This has circulated in several industry newsletters, but Contrast's own report is careful to caveat it: "Anthropic has not disclosed the time, accuracy and human effort that was required for their analysis, making it difficult for security leaders to make real risk assessments today." Treat the underlying capability claim as unverified, even as the broader trend it's illustrating, AI compressing vulnerability discovery timelines, is well supported by the report's own runtime data.

Why CVSS and EPSS alone will steer you wrong

The report's prioritization section is the most practically useful part for a working developer or architect. Generic CVSS base scores tend to inflate perceived risk because most organizations never layer in the local context the scoring system was actually designed to incorporate. EPSS, which predicts 30-day exploitation probability, correlates strongly with real-world exploitation, 85% of CVEs with an EPSS score above 94% are on CISA's Known Exploited Vulnerabilities list, but it isn't complete either. The report cites two confirmed-exploited CVEs with EPSS scores of 22.2% and 0.88% respectively, low enough that a pure EPSS-driven process would have deprioritized both.

Contrast's answer is reachability and exploitability analysis: does the vulnerable function actually execute, does untrusted data actually reach it, and is the application configured in a way that makes exploitation possible. That's a meaningfully different, more precise filter than severity scores alone, though it's also, unsurprisingly, exactly what Contrast's own runtime platform is built to provide. Worth reading that recommendation with the appropriate grain of salt given who's making it, even where the underlying logic holds up.

What this actually means for the average team

Strip away the vendor framing and the practical takeaway is straightforward: attack surface and vulnerability volume are both growing faster than patch cycles can absorb, generic severity scores aren't precise enough to prioritize effectively at that scale, and AI scanning tools, at least in their current form, are adding inconsistent findings to the pile faster than they're helping teams work through it. The report's own conclusion lands on runtime visibility, actually knowing which vulnerabilities are reachable and being actively targeted, as the lever that matters most. That's a reasonable read of the data, even from a company that sells exactly that capability.

Harness GM Rahul Sood: Most "AI Remediation" Claims Don't Actually Work. Here's What Does.

Wed, 19 Aug 2026 15:00:00 +0000

Application security has operated on human timelines for as long as it's existed: a scanner flags something, a ticket gets filed, developers and security argue over priority, and a fix ships weeks or months later, if it ships at all. Rahul Sood, GM of Application Security at Harness, points to Log4j as the cautionary tale everyone in the industry already knows by heart. "It was not uncommon for companies to say it took us almost one year to get rid of it," he said. "Right now, that does not work when attackers have AI that can identify vulnerabilities in your code, even if you thought your code was safe."

Harness is launching a set of AI-driven application security capabilities this week aimed at collapsing that timeline. The stakes are concrete: attackers are now going from disclosure to first exploit in as little as six hours, while the average vulnerability still takes more than 50 days to fix. Sood breaks into three required shifts: defenders need to actually use AI to find weaknesses in their own code, the window between discovering a vulnerability and fixing it needs to compress from months to hours, and organizations need to accept that not every fix will land before an attacker finds a way in, which means building a containment strategy alongside the fix itself.

Scanning with frontier models is real, and also too slow to run daily

Sood doesn't dispute that frontier models can scan code effectively. The problem is cost and speed. He cited a bank going through Anthropic's Glasswing program that took three months to scan its entire codebase using an LLM — and Glasswing partners broadly have surfaced roughly 10 times more vulnerabilities using LLM-based scanning than traditional tools find, a wave of visibility that just becomes a bigger backlog without a faster way to act. "The cost is it takes a lot of tokens. The output is not deterministic, and it's not easy for you to go and triage these vulnerabilities," he said.

Harness's answer is two separate capabilities rather than one. The first, LLM Scan Orchestration, is a native integration between its CI/CD security tooling and LLM-based scanning, supporting both Claude and OpenAI's Codex, so findings get triaged, deduplicated, and normalized into a developer's existing workflow instead of arriving as an unstructured wall of output. The second, AI SAST, layers AI reasoning on top of traditional static analysis, aiming to catch what conventional scanners miss (Sood pointed to business logic attacks as an example) while using that reasoning to cut false positives and explain why a finding matters. From there, a Triage Agent automatically prioritizes what's actually exploitable so teams can focus on real risk, and a Remediation Agent writes and validates a fix for a prioritized finding, opening a pull request for a developer to review and approve.

A zero-day agent that maps blast radius across your entire environment

For open-source and third-party code specifically, Harness is launching an agent that tracks newly disclosed zero-days and maps them against a customer's actual environment: artifacts, pipelines, and repos. Sood argues this is where Harness's position gives it an edge most competitors can't match, since the platform already has visibility into what's in production and what's being built. Once the blast radius is identified, policies can block new builds that carry the vulnerability while triage and remediation catch up. Sood's claim is that this compresses zero-day response from weeks or months down to hours.

The differentiator he leans on hardest, though, isn't detection. It's remediation that's actually been checked. "We don't just validate that the security vulnerability is being fixed. We also validate that the fix will not break your pipeline," he said. Because Harness manages the pipeline itself, a proposed fix gets tested against the customer's own unit tests before it ships, not just checked against the vulnerability in isolation.

Closing the loop with production shielding

Even with a compressed timeline, not every fix lands before an attacker moves. Harness's answer is a virtual patch at the perimeter, deployed against a specific API to block the traffic pattern that would exploit a known vulnerability. Customers choose between two modes: monitoring, where the patch alerts a human to assess, or blocking, where the traffic is stopped automatically. Sood said the choice comes down to a customer's confidence level, the criticality of the API, and their overall risk appetite, rather than a one-size-fits-all default.

That same logic extends to how much autonomy the underlying agents get generally. Sood expects most customers to start with a human in the loop and move toward more autonomous workflows only as trust builds, and the platform supports the full range, from fully manual to fully autonomous, configurable per customer and even per class of fix.

What changes for the developer staring at a vulnerability list

For engineers used to a scanner dumping a long, mostly-noise list of findings, Sood said the real shift isn't just fewer false positives, it's clarity on what's actually reachable and exploitable versus theoretical. Combined with a recommended fix that's been validated against a team's own test suite, the goal is to give developers back the time currently lost triaging vulnerabilities that were never going to matter. "Development teams are being completely overwhelmed by the huge number of vulnerabilities being generated by scanners," Sood said, to the point where it crowds out shipping actual business-relevant code.

What to be skeptical of

Asked what's overhyped in this space even as he's building in it, Sood didn't hedge. "This entire claim that agents can do all this work for you," he said, pointing specifically at remediation. "Most of it doesn't really work." His advice for developers and architects evaluating any vendor's AI remediation claims, Harness included: test it yourself, and be skeptical of a fix recommendation generated without real understanding of your specific environment and test cases. A recommendation that isn't validated against your actual code is still just a guess wearing a more confident outfit.

Cursor CLI Ran Code From Cloned Repos Before Its Own Trust Prompt Ever Loaded

Mon, 10 Aug 2026 14:00:00 +0000

Cursor's command-line coding agent has a workspace trust feature. It's supposed to stop the agent from acting on a project until you've told it you trust that project. Security researcher Francisco Rosales at Manifold Security found a way around it, and the gap ran deeper than a single missed check.

The setup script that ran before trust was asked

The issue lives in Cursor CLI's worktree feature. Run the CLI with -w, and it creates a worktree under ~/.cursor/worktrees//. A repository can define a setup command for that worktree in a file called .cursor/worktrees.json, using a setup-worktree key. Cursor passes that command straight to sh -c.

That's a normal convenience feature. The problem is when it runs. On builds before 2026.07.23-e383d2b, the setup script executed during workspace resolution, and that step finished before the code path that shows the trust dialog. So a repository's own command ran on your machine before you'd ever seen, let alone answered, the trust prompt.

Rosales put it plainly: the trust gate exists so a user can assert they trust a workspace before the agent acts in it. Code execution is supposed to sit behind that gate. This didn't.

The sandbox didn't cover it either

Cursor CLI also ships a sandbox that limits what terminal commands can read, write, and reach on the network. Reasonable users would assume turning it on protects them here. It doesn't.

The worktree setup script is pinned to insecure_none, the setting that turns the sandbox off entirely for that script. So even a developer running Cursor with --sandbox enabled still had a repository-supplied command execute directly on the host, outside any sandbox boundary.

And once that command runs, Rosales confirmed it has the same access as the person running Cursor. Same files, same credentials, same environment. There's no reduced-privilege step in between.

No advisory, and a bumpy disclosure process

Cursor shipped a fix in build 2026.07.23-e383d2b. What it didn't ship was a security advisory. Rosales said Manifold's report was closed as "Informative" on July 29, with two reasons given: the issue requires a user to clone or open an attacker-controlled repository, and the report didn't demonstrate a bypass of workspace trust in the strictest sense. Manifold pushed back with more context, including a reference to a previous Cursor CVE covering similar territory, and hadn't heard back as of this writing.

It's worth sitting with that first reason for a second. "Requires the user to clone an attacker-controlled repo" describes most of what developers do all day. Cloning repos, opening PRs, checking out a coworker's branch, trying out an open-source tool. That's the entire threat surface AI coding agents operate in.

Not just a Cursor problem

Rosales was careful to scope his team's research to Cursor CLI's worktree mechanism specifically, since that's what they tested and can confirm. But he also flagged that workspace trust bypasses through configuration files or other planted repo content, potentially leading to remote code execution, are a known category. Multiple researchers have found variations of it across different agentic coding tools.

His read on why this keeps happening: speed. Everyone building and shipping with AI coding assistants is optimizing for moving fast, and auditing the configuration a repository ships for a specific agent isn't something most developers are doing. It's not on anyone's checklist yet.

What to actually do about it

The narrow fix: update to build 2026.07.23-e383d2b or later, where the worktree setup script is now gated behind the trust prompt. But Rosales flagged an important caveat — once you click "trust," the script still runs, and it still runs outside the sandbox. Trusting a repo means the code in that script executes on your machine, full stop. If you're opening a repo you haven't fully audited, pass --skip-worktree-setup to skip that step.

The wider takeaway is less comfortable. Rosales doesn't think the trust prompt should be treated as a security control. He called it closer to a warning, and pointed out that many coding assistants already ship modes that skip these dialogs entirely for the sake of speed.

That's the real shift developers and security teams need to make. AI agents are capable, configurable, and genuinely useful for moving faster. They're also a new and significant part of the threat model, and "ask before acting" assumes a pace of development that agentic tooling has already outrun in places.

Why this habit is so easy to miss

Most developers don't think of cloning a repo as an action with consequences. It's step one, not a decision point. You pull down a project, open it, and start reading code before you've formed any opinion about whether you trust it. AI coding agents insert themselves right at that moment, and they're built to act fast on your behalf.

That's exactly the gap this research exposes. A .cursor/worktrees.json file sitting quietly in a repo isn't something most people check for, and there's no reason they would have, until now. It's a small, easy-to-miss configuration detail that happens to sit directly in the path of code execution.

If you're pulling down unfamiliar repos regularly, and most developers are, it's worth treating any agent-specific config file the same way you'd treat a postinstall script in a package.json: something to glance at before you run anything, not after. Worth checking what your agent of choice actually gates, and when.

Devs fix only 6 vulnerabilities monthly while facing 17 new ones - production attack data essential.

Thu, 17 Jul 2025 11:09:58 +0000

Software Under Siege: Why Production Data is the Key to Secure Code

The numbers are staggering and sobering: applications face attacks every three minutes, with defenders taking 84 days to patch critical vulnerabilities while attackers exploit them in just five days. According to Contrast Security's new "Software Under Siege 2025" research report, based on 1.6 trillion daily security observations from real production applications, the mathematics of modern application security simply don't add up in defenders' favor.

But buried within this seemingly dire data lies a counterintuitive insight that could fundamentally change how organizations approach application security: the answer isn't necessarily writing more secure code upfront, but rather using production attack intelligence to guide development efforts with surgical precision.

The False Positive Problem

"Most AppSec technologies see possible attacks, so they report huge numbers like thousands or tens of thousands of attacks per month," explains Jeff Williams, CTO and founder of Contrast Security, who has spent three decades in application security. "But when you actually watch the way that the application handles that request, you can differentiate. You can say, 'Hey, that's not an attack.'"

The research reveals a stark reality: while applications face over 14,000 attack attempts monthly, only 81 of those are "viable attacks" that actually reach exploitable vulnerabilities. The rest? Ambient internet noise—what Williams calls "mosquitoes" that defenders don't need to react to every time one flies by.

This distinction matters enormously for development teams drowning in vulnerability backlogs. The average organization now carries 1.1 million application vulnerabilities in its backlog, according to recent analyst research. With developers fixing only six vulnerabilities per application per month while discovering 17 new ones, the mathematical trajectory is unsustainable.

The Speed Asymmetry Crisis

The speed differential between attackers and defenders has reached crisis proportions. While attackers can exploit new vulnerabilities in five days and achieve lateral movement in just 48 minutes, defenders require an average of 194 days to identify breaches and 64 additional days to contain them.

"Large organizations have hundreds or thousands of applications, so you're adding net 11 new vulnerabilities per month per app," Williams notes. "If you do that for a few years across thousands of applications, you end up with massive backlogs."

Traditional security tools aren't equipped for this reality. Web Application Firewalls (WAFs) operate as "best effort" technology at the perimeter, unable to understand the applications they're protecting. Endpoint Detection and Response (EDR) tools miss application-layer attacks entirely due to what Williams calls "attack laundering"—when malicious activity originates through the application rather than directly targeting the operating system.

"Many application attacks stay in the application layer, and EDR can never see them," Williams explains. "Things like unsafe deserialization, SQL injection, and expression language injection—none of those touch the operating system."

The AI Amplification Effect

Artificial intelligence is simultaneously making the problem worse and pointing toward solutions. On the attack side, AI dramatically lowers barriers for novice attackers, enabling them to create sophisticated exploits like unsafe deserialization attacks without deep technical expertise.

For development teams using AI coding assistants, the news isn't encouraging. "AI doesn't generate code that's any more secure than humans generate," Williams cautions. "It's trained on code built by humans in the last generation, so that's the kind of code it produces." Multiple studies confirm AI-generated code carries similar security risks to human-written code.

However, AI also offers unprecedented opportunities for defenders when applied to high-quality production data.

The Production Data Advantage

Here's where Williams' research reveals something counterintuitive: the key to writing secure code isn't necessarily shifting further left in the development process, but rather gathering intelligence from production applications under real attack.

"My epiphany over the last 10 years is that in order to build code securely, you have to have context from production," Williams explains. "You have to know where you're being attacked, what attack types are being used against you, and which things in production are really exploitable."

This approach flips conventional wisdom. Rather than trying to anticipate every possible vulnerability during development (often resulting in false positive overload), teams can use actual attack intelligence to prioritize their security efforts with laser focus.

The data supports this approach: 99% of the 1.6 trillion security-relevant transactions Contrast observes daily are executed correctly. "Developers are getting almost everything right relative to the code they're writing," Williams notes. "It's in that 1% where we see the serious vulnerabilities and mistakes."

Practical Implementation Strategies

For CISOs and development leaders, this research suggests several strategic shifts:

1. Deploy Application Detection and Response (ADR) in production environments to gain real-time visibility into which vulnerabilities are actually being targeted. Unlike traditional tools that generate mountains of theoretical vulnerabilities, ADR identifies only those being actively exploited.

2. Use production attack data to prioritize remediation efforts. When development teams know which vulnerabilities attackers are actually targeting, they can focus their limited time on issues that matter rather than chasing theoretical risks.

3. Implement runtime protection for vulnerabilities that can't be immediately patched. Williams notes that ADR can completely eliminate entire categories of attacks, including expression language injection, SQL injection, and unsafe deserialization.

4. Focus on signal versus noise. By filtering vulnerability reports through production attack intelligence, teams can dramatically reduce their effective backlog while maintaining security posture.

Success Stories

The approach yields measurable results. Williams cites BMW as an example of a large organization that has "effectively eliminated their backlog and reduced their mean time to remediate vulnerabilities to one day" by implementing production-informed security practices.

"When you contextualize things and give developers real vulnerabilities, they can tighten the feedback loop," Williams explains. "Across hundreds or thousands of applications, they can get excellent AppSec programs going."

The Path Forward

The research reveals that method tampering appears as the most universal attack across all programming languages—not because it's particularly sophisticated, but because it's easy to attempt. Attackers simply try different HTTP verbs on every endpoint to find access control gaps.

This pattern reflects a broader trend: attackers are increasingly automated and opportunistic, scanning for the easiest targets rather than developing highly sophisticated, targeted exploits. Defenders can leverage this by focusing protection efforts on the vulnerabilities actually being exploited, rather than trying to eliminate every theoretical risk.

As Williams puts it, referencing the movie Cars: "You have to turn right to go left. People think they have to put more effort farther left to prevent vulnerabilities from getting into production. But there's no context over there, so you just get overwhelmed with false positives. The answer, counterintuitively, is in production."

For development teams and security leaders struggling with ever-growing vulnerability backlogs and accelerating attack timelines, this insight offers a path forward: use production intelligence to guide development priorities, deploy runtime protection for immediate risk reduction, and focus precious development resources on the vulnerabilities that truly matter.

The mathematics of modern application security may seem impossible, but with the right data and approach, defenders can finally start winning the race.