Why AI AppSec Needs Organizational Context to Work

There's a joke that's been circulating in security circles for a while: AI didn't kill AppSec, it just made AppSec's existing problems louder. More findings. More alerts. More noise for already-stretched teams to wade through. The scanners got smarter and somehow the spreadsheets got longer.

That tension sits at the center of a recent conversation on Daniel Miessler's Unsupervised Learning podcast between Miessler and Sarit Tager, who works on application security at Palo Alto Networks. The exchange is worth paying attention to—not because it's a product pitch dressed up as analysis (though that dimension is present and worth noting), but because the diagnosis they're working from is largely accurate, and the proposed cure raises questions worth sitting with.

The detection problem that more detection doesn't solve

Start with what Tager calls the core AppSec problem: it hasn't changed. "All these models which are great and they find a lot of security issues," she says, "but they still have the problem that was AppSec from the beginning. How do I remediate without damaging my organization?"

This is real. AI-powered static analysis and LLM-assisted code review are genuinely good at surfacing vulnerabilities—better than traditional rule-based scanners in many respects. But "finding" and "fixing" are different disciplines. Tager describes watching an LLM recommend removing a flag to patch a vulnerability, only for someone to point out that removing the flag breaks the application entirely. Generic advice from a model that doesn't know your codebase is just a different flavor of bad advice.

The alert fatigue problem is real and getting worse. As AI tools get better at detection, the volume of findings climbs. Teams aren't getting fewer things to triage—they're getting more, with no corresponding increase in capacity to act on them. The question "should I fix everything?" is now genuinely unanswerable without context, because the answer is obviously no, but nobody knows which everything to skip.

CVSS scores were always educated guesses

Miessler makes a point that's worth lifting out of the podcast context because it stands on its own: vulnerability scoring systems like CVSS have always been "rudimentary guesses about what's actually happening in the company." A score tells you something about the theoretical severity of a flaw. It tells you almost nothing about whether that flaw is reachable in your specific deployment, whether the container it lives in is even exposed to the internet, or whether the team that owns that repo tends to ship fixes in two days or two months.

"The more you know about us as a company," Miessler says, "the prioritization just gets really obvious."

That's the argument at the center of the conversation, and it's a compelling one. The shift they're describing is from generic vulnerability scoring to what Tager calls organizational, cloud, and business context—knowing not just that a vulnerability exists, but whether it's deployed, whether it's reachable, what it touches, who owns it, and how your organization has historically handled similar issues.

The practical example Tager gives is a good one: an external attack surface management tool confirms that a container isn't exposed to the internet. That fact should directly downgrade the urgency of a vulnerability sitting inside that container. Today, those two pieces of information often live in separate products that never talk to each other. The vulnerability gets scored in isolation. The patch queue fills up with things that couldn't be exploited anyway.

The platform advantage—and what it costs

Here's where the conversation gets interesting, and where the tension worth surfacing lives.

Tager is describing a Palo Alto Networks platform play. The context she's talking about—endpoints from Cortex XDR, cloud posture from Cortex Cloud, supply chain signals from pipeline configurations, identity data—only becomes available if an organization has multiple Palo Alto products deployed and integrated. The data lake that makes contextual prioritization possible is, in practice, a data lake that the vendor controls.

Miessler acknowledges this explicitly: small startups that understand the context idea still face a problem, because "gathering that information is actually much more difficult than deploying your product." The context-first approach requires significant platform investment before it starts delivering its core value proposition. That's not a knock on the approach—it's just the shape of the trade-off.

The upside Tager describes is real: if you commit to the platform, you get a graph of relationships that connects code to pipelines to images to cloud deployments to external exposure. You can answer the question "is this package actually in the running image?" instead of patching every repo that lists it as a dependency. You can see that a developer who committed suspicious code also has extensive cloud privileges—a signal that's invisible if your dev tooling and your cloud security live in separate consoles.

Whether that upside is worth the vendor lock-in is a calculation every organization has to run for itself. What's not really arguable is that the concept—treating organizational knowledge as the primary input to security decisions—is the right direction.

"PRD to production" and the security debt it creates

One of the more interesting threads in the conversation is what Tager calls "PRD to production"—the emerging reality that product managers, designers, and other non-developers can increasingly ship working code just by describing what they want. Miessler compares it to the farm-to-table movement in food: the idea that something can go from raw intent directly to a finished product, cutting out the intermediary.

The security implication is uncomfortable. If the person writing the intent doesn't understand the code that gets generated, they almost certainly can't evaluate the security of that code. "I'll probably go back to the LLM and say, 'I got this security issue, can you help me fix it?'" Tager says. "I don't think I will fix it by myself, probably."

Vercel's DeepSec is one attempt to address exactly this problem—building security review directly into AI-assisted code generation. The challenge is that you're asking the same class of tool that generated potentially flawed code to audit its own output. That's not impossible, but it introduces a category of risk that's different from traditional AppSec.

The "PRD to production" world means more code, written faster, by more people with less context about what they're building. The attack surface grows not because anyone is being reckless, but because the barrier to shipping code has dropped dramatically. Security programs designed around the assumption that developers understand their codebase are going to struggle in this environment.

The automation imperative and its honest limits

The Log4Shell comparison Miessler reaches for is a good illustration of where the industry currently sits. When that vulnerability dropped in late 2021, enterprises managed their response via Excel spreadsheets—calling developers onto Zoom calls and having them type in a column whether they owned an affected system. In 2021. For a critical, actively exploited vulnerability.

Tager's point is that this can't be the model going forward. Attackers are using AI to generate and probe vulnerabilities continuously. The asymmetry gets worse if defenders are still triaging manually. "This has to be automated, otherwise it will never scale up," she says. The volume of attacks isn't going to decrease.

The vision she describes for the next three years involves AI guardrails embedded directly in developer environments, continuous automated remediation for lower-risk fixes (minor version upgrades, flag changes with known dependency trees), and human review reserved for genuinely complex decisions. The analogy Miessler offers is deliberately reductive but lands: you wouldn't put a human in the middle of an Excel formula. The calculation is happening too fast.

What that framework leaves open is the question of which decisions actually require human judgment, and whether the line is being drawn in the right place. Automated patching that doesn't break APIs is easier to defend. Automated triage that deprioritizes vulnerabilities because a container "appears" unexposed is a more consequential call. Getting that wrong—dismissing something as low-priority because the context graph said so—isn't just an efficiency loss. It's a missed critical finding with a plausible-looking paper trail.

The honest version of this argument acknowledges that context-driven automation is better than no context and no automation. It doesn't claim that context is ever complete or that the graph is always right.

---

Rachel "Rach" Kovacs covers cybersecurity and privacy for Buzzrag.