{"id":3932,"date":"2026-04-28T14:22:03","date_gmt":"2026-04-28T14:22:03","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/04\/28\/the-code-doesnt-care-who-wrote-it-why-context-not-ai-fear-will-define-modern-application-security\/"},"modified":"2026-04-28T14:22:03","modified_gmt":"2026-04-28T14:22:03","slug":"the-code-doesnt-care-who-wrote-it-why-context-not-ai-fear-will-define-modern-application-security","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/04\/28\/the-code-doesnt-care-who-wrote-it-why-context-not-ai-fear-will-define-modern-application-security\/","title":{"rendered":"The Code Doesn\u2019t Care Who Wrote It: Why Context, Not AI Fear, Will Define Modern Application Security\u00a0"},"content":{"rendered":"
\"AI-based,<\/div>\n

\"AI-based,<\/p>\n

AI has already arrived in the software development lifecycle; not as a pilot program or controlled experiment, but as an everyday reality. Developers are using AI coding assistants to generate functions, refactor modules, review pull requests, and accelerate delivery,\u00a0often in direct tension with corporate policies meant to limit or control that use.<\/span>\u00a0<\/span><\/p>\n

While it\u2019s tempting to consider this some kind of \u2018Shadow AI\u2019 or \u2018Governance Failure\u2019, it is a signal of things to come in this brave new world of AI-accelerated software engineering.<\/span>\u00a0<\/span><\/p>\n

Recent industry surveys show that\u00a0<\/span>well over half of developers now rely on AI coding assistants<\/span><\/a> in their daily work, with many using them frequently or constantly. At the same time, more than three-quarters of organisations have formal policies that restrict or prohibit that same usage. From a security perspective, that tension is understandable\u00a0but\u00a0may be\u00a0misplaced, because from the standpoint of application risk, the code itself doesn\u2019t care who wrote it.<\/span>\u00a0<\/span><\/p>\n

Whether a snippet, a function, a module, or a review was produced by a human engineer, a junior intern, an open source package, or the latest frontier language model is ultimately irrelevant. Vulnerabilities don\u2019t discriminate based on authorship. Licenses don\u2019t behave differently because the code was \u201cAI-generated\u201d. The risk profile of an application is defined by what is deployed, not by how human or virtuous or compliant the development process appears on paper.<\/span>\u00a0<\/span><\/p>\n

AI is not introducing a new category of security threats. It is acting as an\u00a0accelerant\u00a0for risks that already existed.<\/span>\u00a0<\/span><\/p>\n

A Throughput Problem, Not a Threat to Singularity<\/span><\/b>\u00a0<\/span><\/h3>\n

The rise of large language models and agentic development tools has dramatically increased the speed at which software is written, modified, and shipped. Codebases are growing faster than most AppSec programs were designed to handle. Over the past five years, average file counts have\u00a0<\/span>grown by more than 200%<\/span><\/a>, while vulnerability volumes have increased at a similar pace\u00a0\u2014\u00a0doubling in some ecosystems in a single year.<\/span>\u00a0<\/span><\/p>\n

This isn\u2019t a \u201csecurity singularity.\u201d It\u2019s the same fundamental challenge application security has always faced: keeping feedback loops intact while systems scale.<\/span>\u00a0<\/span><\/p>\n

Unfortunately, many security pipelines still scale linearly in a world that is now exponential. Nearly 60% of teams deploy to production daily or more frequently, yet a large proportion still rely on manual security testing. Even among mature organisations, most test less than two-thirds of their application portfolios. Unsurprisingly, more than 80% of teams report that security testing slows development.<\/span>\u00a0<\/span><\/p>\n

\u201cAI\u201d\u00a0didn\u2019t create this bottleneck, but it has\u00a0exposed it.<\/span>\u00a0<\/span><\/p>\n

When releases outpace review, organisations respond with exceptions, escalations, and deferred remediation. Feedback arrives weeks or months after the relevant code was written, long after the developer context has dissolved. The result is a familiar spiral: growing backlogs, increasing noise, and diminishing trust in security outputs.<\/span>\u00a0<\/span><\/p>\n

The Confidence Paradox<\/span><\/b>\u00a0<\/span><\/h3>\n

That erosion of trust shows up clearly in how security teams describe their own effectiveness. Nearly 90% of security professionals express confidence in their organisation\u2019s ability to manage AI-related risks;\u00a0yet a majority also describe the alerts they receive as \u201cmostly noise.\u201d<\/span>\u00a0<\/span><\/p>\n

High confidence. Low discrimination.<\/span>\u00a0<\/span><\/p>\n

This paradox isn\u2019t caused by bad tooling. It\u2019s caused by missing context.<\/span>\u00a0<\/span><\/p>\n

For years, the industry has tolerated high false-positive rates in exchange for theoretical completeness. That trade-off becomes untenable when AI-accelerated development floods pipelines with findings faster than teams can triage them. Every noisy alert consumes human attention, delays delivery, and reduces the likelihood that truly meaningful issues are addressed in time.<\/span>\u00a0<\/span><\/p>\n

The solution isn\u2019t more alerts. It\u2019s better information, earlier.<\/span>\u00a0<\/span><\/p>\n

What AI Knows\u00a0and What It Doesn\u2019t<\/span><\/b>\u00a0<\/span><\/h3>\n

The latest generation of Large\u00a0Language\u00a0Models are exceptionally good at\u00a0sampling\u00a0general patterns from historical data\u00a0that they\u2019ve been trained on. That\u2019s why they\u2019re effective at writing syntactically correct code or identifying common vulnerability classes. But there are entire categories of knowledge they fundamentally lack:<\/span>\u00a0<\/span><\/p>\n