Coder Legion - Recent posts tagged vulnerabilitymanagement

Finite State's Larry Pesce: Attackers Are Coming Back for Infrastructure Everyone Forgot to Watch

Tue, 08 Sep 2026 19:57:45 +0000

Over the past week, attackers have been hijacking MikroTik routers at scale, exploiting a chain of RouterOS vulnerabilities CERT Polska calls "MikroTrick." Two flaws, an SSH authentication bypass and a privilege escalation triggered by a specially crafted username, combine to give an unauthenticated attacker full administrative control of any exposed device. As of a September 5 scan, the Shadowserver Foundation counted more than 122,500 MikroTik devices with SSH reachable from the open internet, concentrated in Brazil, the U.S., Indonesia, the Czech Republic, and Ukraine. Exploitation began September 2, a day before MikroTik shipped patches and three days before CERT Polska published the technical detail defenders needed to detect it.

There's a detail in how these flaws were found that's easy to miss under the exploitation headlines: CERT Polska's team used OpenAI's GPT-5.5-cyber and GPT-5.6-sol models, through the vendor's Government and Trust Agency Collaboration program, to automate version comparison, RFC analysis, and binary review, with researchers independently verifying every finding before disclosure. That's AI accelerating the defensive side for once, not just the offensive one, though the exploitation timeline that followed shows how little breathing room that head start actually buys.

The pendulum, not the CVE, is the real story

Larry Pesce, VP of Services at Finite State, argues the specific vulnerabilities matter less than the pattern they fit into. "This is a very old argument dressed up in new CVEs," he said. "Network infrastructure was the original attack surface, back when worms and DNS cache poisoning and route hijacking were the front page news."

His read on the last two decades of attacker behavior is a pendulum, not a straight line. Defenders hardened the network perimeter, so attackers moved to the endpoint: client-side exploits, macros, phishing. EDR got good at watching endpoints, so attackers moved to cloud and identity, then to the sprawl of IoT and connected devices nobody was monitoring at all. Now, Pesce argues, the swing is back toward infrastructure. "Edge appliances, VPN gateways, and routers like these MikroTik boxes are attractive again for exactly the reason they were attractive twenty years ago: almost nothing runs an agent on them, almost nobody patches them promptly, and almost nobody actually knows how many of them they have exposed to the internet."

The inventory gap nobody closed

Pesce's sharpest point is about where organizational attention actually went over the past ten years. "Most organizations have spent the last decade building real inventory and telemetry for laptops and servers. Very few have done the same for the network gear sitting between those systems and the internet," he said. A router doesn't show up in an EDR console. It usually isn't in the CMDB unless someone remembered to add it. It gets touched during install and then left alone until something breaks.

That gap is exactly what a campaign like this is built to exploit, and it's why Pesce doesn't find 122,500 exposed devices a shocking number so much as a predictable one. "Nobody set out to leave that many boxes reachable on purpose. It's an accumulation of the same basic inventory gap, repeated at scale."

A numbers game, not a single-target intrusion

Pesce also draws a distinction worth sitting with: compromising a router at scale usually isn't about that one router. "It's about building a broad, disposable base, proxy points, relay infrastructure, a wide net of footholds, rather than a single surgical intrusion into one high-value target," he said. That's a different economic model than the supply-chain-style precision compromise that tends to dominate security headlines, and it changes what defense needs to look like. "You're not trying to stop one determined actor from reaching one target. You're trying to avoid being one anonymous node in somebody's infrastructure, which is a numbers game, and numbers games get won or lost on unglamorous things like patch cadence and knowing what you actually have exposed."

What MikroTik is asking affected users to do

Beyond patching, MikroTik's advisory asks administrators to actually check whether they've already been compromised. Updated RouterOS versions can flag a device's status after checking logs; a device marked "Flagged" should be treated as compromised outright, not just patched and left alone. Simply updating isn't sufficient on its own; the compromise can predate the fix. CERT.LV, for its part, said it had already confirmed a dozen compromised devices in Latvia out of several thousand exposed there, notified critical infrastructure operators, and continues tracking the fallout.

Not really a MikroTik story

Pesce's closing point is the one worth carrying into any infrastructure review this prompts. "None of this is new. It's the same swing the industry has made every few years: infrastructure, then endpoint, then cloud, then device, and back to infrastructure again, each time landing wherever defenders most recently stopped paying attention," he said. "The lesson isn't really about MikroTik. It's that 'know your inventory' never stopped being step one, and the network layer is overdue for the same rigor we finally applied to endpoints."

For developers and architects, the practical takeaway isn't a MikroTik-specific patch checklist. It's a question worth asking about every edge appliance, VPN gateway, and router sitting on the network: does it show up anywhere your team actually looks, or has it just been sitting there since install, waiting for its turn?

From Zero Visibility to a Measurable Security Baseline

Wed, 26 Aug 2026 15:15:28 +0000

Every security team has a “Day Zero” the moment before security tooling, visibility, and processes are in place. You can't confidently answer questions like:

• What devices are on the network?
• Which systems are vulnerable?
• Are our endpoints patched?
• Would we detect a compromise?

That was the starting point for this security lab. The environment had no vulnerability scanning history, no centralized patch management, no endpoint detection, and exposed Windows machines with open RDP. So I approached the problem from the ground up.

1️⃣ Discover Before You Defend
I started with network discovery using Wireshark to identify the devices actually connected to the environment.

2️⃣ Secure the Network With Tailscale
Instead of exposing more management services to the public internet, I established a private Tailscale network.

3️⃣ Establish a Vulnerability Baseline With Wazuh
Next, I deployed Wazuh agents across the endpoints with:
• Vulnerability detection
• File Integrity Monitoring
• MITRE ATT&CK mapping
• CIS Security Configuration Assessment (SCA)

4️⃣ Centralize Patch Management With Action1
Visibility alone isn't enough. Vulnerabilities need to be remediated. I deployed Action1 to centralize patch visibility and deployment while deliberately keeping its findings separate from Wazuh's.

5️⃣ Turn Security Into a Process
I also established severity-based remediation SLAs, critical vulnerabilities were also configured for automated patch deployment and auto-approval.

🔐 Key Lessons
• Discover before you defend.
You need an accurate asset inventory before “coverage” means anything.

• Secure connectivity before expanding management access.
Reduce unnecessary network exposure wherever possible.

• Baseline before remediating.
You need measurable evidence to demonstrate improvement.

• Understand what your security tools actually measure.
Different tools can legitimately produce different results.

• Automate security policies.
A policy sitting in a document doesn't enforce itself.

• Report verified outcomes, not just completed activities.
“Patch deployed” and “vulnerability confirmed remediated” are not the same thing.

👉 Read the full blog post here:

CVE Disclosures Have Doubled Two Years Running — And Now the Backlog Is "Radioactive"

Wed, 05 Aug 2026 01:12:52 +0000

"Vulnpocalypse" isn't a term Jeff Williams coined himself — he credits his marketing department — but the Contrast Security founder and OWASP creator uses it anyway, because it captures something real. Frontier AI models, Claude Mythos among them, can now find and exploit vulnerabilities at a cost approaching zero. That changes the math for every organization that spent years rationally deferring remediation on vulnerabilities nobody was ever likely to exploit. "Their whole backlog suddenly became radioactive," Williams said. Roughly half of that backlog is CVEs in open source dependencies; the other half is custom code vulnerabilities in a company's own software. Both just got dramatically cheaper to find and chain together into working exploits.

Williams breaks the shift into three forces. AI helps developers ship code faster, but not more securely, so the same defect rate now runs through a much larger volume of code, producing more vulnerabilities in absolute terms. AI helps security researchers find CVEs faster too, and Williams says disclosure rates have more than doubled this year, after doubling the year before. And AI helps attackers do what a human attacker used to do manually: probe running code for holes, just faster and at far greater scale.

Williams has been doing this for 30 years, and he's watched the tooling landscape evolve accordingly. Eleven years ago, when he last spoke with Coder Legion, a typical enterprise ran five or six point solutions for application security alone: static and dynamic scanners, software composition analysis, manual penetration testing, manual code review. Fixing what those tools found meant developers begging, borrowing, and stealing minutes out of their own roadmaps. On the production side, web application firewalls tried to block exploits at the perimeter, with mixed results. Since then, the finding side has consolidated into platforms and a newer category called ASPM that tries to unify results into one picture; Contrast built what Williams calls a context graph, a kind of digital twin of an application's security posture. On the production side, WAF gave way to RASP, which Contrast pioneered, and that category has since evolved into what's now called ADR, application detection and response.

The newest piece of that evolution launched days before this conversation: Contrast CVE Shield, a free compensating control that runs inside a live application and blocks known vulnerabilities from being exploited without requiring an immediate patch. It works through runtime microsandboxing wrapped around each supported CVE, blocking the specific capability an exploit needs rather than relying on signatures, which means new exploit variations hit the same protected boundary without requiring an update. Initial coverage spans 60 critical Java vulnerabilities, including Log4Shell, with support for Go, Node.js, .NET, and Python planned for later this year. For a security team staring down a backlog it can't patch fast enough and can't fully trust a WAF to cover, Williams pitches it as a third option: a way to satisfy compliance and buy time without pretending the underlying problem is fixed. The timing lines up with new government mandates shrinking the remediation window for critical vulnerabilities to three days, a deadline Williams calls directionally correct and, for most companies, close to impossible to hit without something like it.

Williams also founded OWASP and wrote its original Top 10 list in 2002, and he's candid about the strain AI-era vulnerability volume puts on a community-driven model. OWASP doesn't review every finding itself, he explains; it builds the tools, processes, and shared workforce that make review possible at scale. That informal capacity roughly matched the problem a couple of years ago. It doesn't now. OWASP remains, in Williams's view, the leading research organization on AI security specifically, but the field as a whole is stuck in a familiar pattern: build first, retrofit security once something breaks, then repeat.

Asked what one thing he'd want developers to understand, Williams points to MITRE's catalog of roughly a thousand distinct vulnerability classes, every one of them, he says, genuinely non-obvious. He uses clickjacking as an example: an attacker overlays an invisible, fully functional version of a legitimate site underneath something innocuous-looking, so a click that appears to hit a game button actually triggers an action on the hidden page underneath. Nobody invents that kind of attack by intuition. Someone has to think of it once, and then everyone else has to learn it. With a thousand of those tricks in circulation and AI now finding new ones faster than any team can track, Williams argues the expectation that developers alone can catch everything was never realistic, AI era or not.

He's not entirely pessimistic about where this goes. Williams argues the same AI capabilities now accelerating attackers can eventually automate the expert-intensive workflows, threat modeling, architecture review, security-by-design verification, that most organizations have never had the staff to do at scale. So far, he says, the industry has mostly used AI to automate yesterday's reactive workflows: find a vulnerability, patch it, repeat. The bigger opportunity, in his view, is using it to build software that's verified secure before it ships in the first place, closing the structural advantage defenders already have on paper, since they control the blueprint, and attackers don't, but have rarely been able to use.

Are You Ready for the 2026 OT Cyber Compliance Wave?

Sat, 27 Dec 2025 22:07:17 +0000

The clock is ticking.

By 2026, industrial operators worldwide will face stricter OT cyber regulations. Fines, operational restrictions, and compliance audits will no longer be a distant threat; they will be a daily reality.

Many companies think they’re prepared because they have the latest security tools. They’re not. Compliance isn’t just about technology; it’s about process, governance, and accountability.

What the 2026 Rules Are Targeting
While each country and industry has specific requirements, the trends are clear:

Actionable Policies: Policies must define who can act, when, and how.

Automated Reporting & Audit Trails: Manual logs won’t cut it; regulators expect evidence of real-time monitoring and response.

Operator Competency & Training: Staff must understand their role in compliance, not just in operations.

Integration Across Systems: IT and OT can’t operate in silos; compliance requires coordination.

In short, technology alone will not pass the audit. Governance and decision-making structures matter just as much.

The Cost of Ignoring Compliance
Companies that fail to prepare will face real consequences:

Regulatory fines and penalties

Production downtime due to forced shutdowns

Increased insurance premiums

Loss of customer trust and reputational damage

This isn’t hypothetical. Industrial cyber incidents have already caused multi-million-dollar losses, and regulators are taking notice.

How to Prepare for the Compliance Wave
Map Your Risks: Identify which OT systems matter most to safety, operations, and compliance.

Define Ownership: Assign clear responsibility for each risk and system.

Automate Where Possible: Automate monitoring, alerts, and reporting to reduce human error and speed decisions.

Train Your Staff: Ensure operators and managers understand compliance obligations, not just operational procedures.

Integrate IT & OT Governance: One coherent governance structure beats isolated teams and siloed dashboards.

By preparing today, companies can turn compliance into a competitive advantage, rather than a regulatory headache.

The Bottom Line
2026 is approaching fast. The next wave of OT cyber regulations will reward companies that combine technology, governance, and accountability.

The ones that ignore it? They won’t just fail audits, but they will also fail operations.

Compliance is a leadership responsibility.

Operator Fatigue In OT Cyber Security

Tue, 16 Dec 2025 23:23:26 +0000

The reality of cyberattacks on factories, power plants, or pipelines is far more mundane and far more dangerous than we normally imagine. In operational technology (OT) environments, the weakest link is often a tired, overworked, or cognitively overloaded operator.

Why Fatigue Matters in OT

OT systems, whether they control energy grids, manufacturing lines, or transportation networks, run around the clock in high-stakes environments. But operators are human. Fatigue slows reaction times, reduces attention to detail, and increases the likelihood of mistakes, even in routine tasks. Research shows that exhaustion leads to slips, lapses, and eventual burnout, leaving critical systems vulnerable.

In OT, these errors can escalate rapidly. A missed alert or skipped safety step can propagate consequences throughout a system. OSHA has highlighted fatigue as a contributing factor in major disasters, including the Texas City refinery explosion, the Challenger shuttle failure, and nuclear accidents at Chernobyl and Three Mile Island.

How Fatigue Leads to Cybersecurity Failures

Fatigue directly undermines cybersecurity. Consider these scenarios:

Missed Alerts and Signs: A sleep-deprived operator might overlook a warning light or log message that signals malware or intrusion. Attackers exploit these unnoticed indicators to act undetected.

Ignored Warnings: Continuous alarms can desensitize operators. After hours of responding to minor alerts, a critical cybersecurity alarm may be silenced or bypassed.

Risky Shortcuts: Fatigue drives shortcuts. Tired staff might reuse passwords, plug in unvetted USB drives, or skip updates, all opening doors for attackers. Studies show “security fatigue” correlates with risky behaviors.

Delayed Security Tasks: Long shifts and understaffing push essential updates and backups to the back burner, leaving vulnerabilities exposed.

Higher Phishing Success: Early morning or late-night shifts increase susceptibility to phishing attacks, as tired operators are less vigilant.

Real-world incidents illustrate the dangers: a USB drive left in a control system spreads malware overnight, an overdue patch is ignored during a night shift, and a recurring alert silenced by an exhausted operator allows ransomware to run unchecked.

Every shortcut, skipped check, or delayed update multiplies risk, without an attacker having to develop new exploits.

Why Industry Often Overlooks Fatigue

Fatigue risk is frequently ignored due to operational priorities and culture:

Production Above All: Management emphasizes uptime and speed, discouraging staff from admitting exhaustion or taking breaks.

OT Culture: Phrases like “push through” or “get it done” foster a mindset where endurance is celebrated, and mistakes are seen as carelessness rather than fatigue.

Invisible Factor: Unlike a technical breach, fatigue leaves no trace in logs. When incidents occur, “operator tired” rarely appears in reports.

Metrics Gap: Cybersecurity metrics measure technical controls, not human conditions. Long weekend shifts, extended hours, or cognitive overload go untracked.

Mitigating Fatigue Risk

To address this hidden threat, organizations must design OT systems with human limits in mind:

Enforce Healthy Shifts: Adequate rest, through 8-hour shifts, mandatory breaks, and rotation, reduces errors dramatically.

Reduce Alarm Overload: Streamlining alerts and filtering duplicates helps operators focus on genuine threats.

Automate Routine Tasks: Automation of repetitive monitoring and logging frees humans for critical decision-making.

Support Safe Practices: Encourage staff to pause, double-check, and report fatigue without fear of blame.

Training and Awareness: Include fatigue and cognitive load in security programs. Case studies of fatigue-related failures help staff understand the stakes.

Technical Aids: User-friendly security tools, like password managers and enforced multi-factor authentication, reduce the chance of mistakes under fatigue.

The Bottom Line
Operator fatigue is not merely an HR concern rather, it is a cybersecurity risk. In OT, the human at the control panel is often the last line of defense. No firewall, monitor, or segmentation strategy can fully protect a system if the operator is exhausted.

By recognizing fatigue as a key factor and implementing policies, automation, and cultural shifts to address it, organizations can dramatically reduce both safety and cybersecurity risks. Every technical control matters, but they are only half as effective if the human watching them is running on empty.

Attackers Know Your Human Patterns Better Than You Do

Tue, 16 Dec 2025 11:09:17 +0000

Let us face it. Your operators are predictable. This is not because they lack skill or because they do not care. It is simply because they are human. In operational technology environments that run around the clock, humans are naturally easy to read. Attackers understand this. While IT teams focus on firewalls, patch cycles, and threat intelligence dashboards, the real threat is quietly observing human behavior. Attackers map routines, memorize reaction times, and exploit tiny cracks in daily habits. All of this happens under your nose.

Walk into any control room and the patterns are obvious. Morning shifts check dashboards in the same order every day. Mid-shift alerts often get ignored until lunch. Night operators rely on checklists but fatigue makes them prone to skipping steps. These patterns are not flaws. They are survival mechanisms for humans operating in complex and high-pressure environments. Unfortunately, attackers feed on these predictable behaviors. A phishing email, a cleverly disguised USB, or a social engineering call timed to coincide with routine tasks can be enough to gain unauthorized access. Attackers do not need sophisticated exploits. They only need timing and an understanding of human behavior.

Behavioral analytics is the operational technology superpower most organizations ignore. Companies often track downtime, patch status, and recovery times. Few, however, track how humans actually behave under real-world conditions. Behavioral analytics is not about spying on employees. It is about understanding patterns to predict weak points before attackers exploit them. Knowing who skips double-checks under pressure, which shifts are prone to alert fatigue, and when procedural shortcuts appear allows you to design systems that make unsafe behavior impossible. Instead of blaming operators for mistakes, organizations can focus on designing environments where predictable human behavior cannot be turned against them.

Real-world examples show the danger clearly. At a chemical plant, the day shift ran a backup script every morning at ten oh five. One day, an attacker sent a phishing email at ten oh three. The operator, busy running the backup, clicked the email and granted unauthorized access. There was no advanced malware or zero-day exploit. The exploit happened because of a predictable human routine. A similar incident occurred at an oil pipeline. Night operators habitually ignored minor alarms until supervisors arrived for rounds. Hackers took advantage of this predictable pattern and embedded malware that went unnoticed for days. These incidents demonstrate that attackers do not need to break complex systems. They only need to exploit predictable human behavior.

Humans are often described as the weakest link in cybersecurity. This is misleading. Humans are not weak. They are predictable. Attackers read that predictability like an open-source manual. The challenge for operational technology security teams is not to eliminate human error because that is impossible. The challenge is to accept predictable behavior as a reality and design systems that prevent it from becoming a vulnerability. Effective security requires mapping these patterns, stress-testing them, engineering the environment, and continuously measuring results.

To protect operational technology systems, organizations must understand human behavior in context. Logs, workflow analysis, and incident data can reveal patterns in decision-making, task execution, and shift dynamics. Simulated attacks, phishing exercises, and operational distractions can expose vulnerabilities in a controlled setting and help teams adapt before real attackers strike. Engineering the environment to remove shortcuts, enforce checks, rotate responsibilities, and introduce unpredictability ensures that safe behavior is always the path of least resistance. Humans adapt, and so must your defenses.

The bottom line is simple. Attackers are already studying your operators in the same way analysts study network diagrams. They know when attention will lapse, which shifts are stressed, and which roles are most likely to take risky actions. If you are not mapping human patterns and designing systems around them, you are giving attackers the advantage. Predictable humans are not a flaw. They are a potential exploit. The real task of operational technology cybersecurity is to close that gap before attackers turn human consistency into a weapon.

Ultimate Guide to Handle React/Next.js RCE (CVE-2025–55182)

Fri, 05 Dec 2025 05:26:12 +0000

A Critical Front-End Vulnerability Hits Hard

On December 4, 2025, developers worldwide woke up to a CVSS 10.0 full-score RCE vulnerability in React 19 / Next.js (CVE-2025-55182, Next.js CVE-2025-66478).
If Log4Shell was a nightmare for Java in 2021, this is the darkest hour for full-stack JavaScript.

This vulnerability allows attackers to execute arbitrary code on your server via a single HTTP request—no authentication required.

01 Understanding the Vulnerability: The Achilles’ Heel of RSC

Flight Protocol & Serialization

React Server Components (RSC) introduced the Flight protocol to stream component trees between server and client:

Server → Client: Components are streamed in a JSON-like format.
Client → Server: When Server Actions (e.g., form submissions) are triggered, the client serializes parameters back to the server.

Unsafe Deserialization

The core of the vulnerability lies in the react-server package and its adapters (e.g., react-server-dom-webpack):

Cause: The server fails to safely validate the structure of deserialized objects.
Attack vector: Maliciously crafted RSC payloads exploit the server’s deserialization logic.
Trigger: When the server deserializes the payload, it executes arbitrary functions or instructions.
Impact: Malicious JavaScript runs in the server process context, bypassing sandboxes.

This is a classic unsafe deserialization vulnerability, amplified by RSC’s flexibility for complex object passing.

02 Who Is at Risk?

Affected frameworks include all React RSC implementations:

React versions: 19.0.0, 19.0.1, 19.1.x, 19.2.0
Next.js (App Router): v15.0.0–v15.5.6, v16.0.0–v16.0.6, v14.3.0-canary.77+
Other frameworks: Waku, RedwoodJS (RSC mode), and custom setups using react-server-dom-webpack/parcel.

Not affected: legacy Next.js using only Client Components (Pages Router).

03 Official Fix: Upgrade Immediately

Option 1: Upgrade Your Framework (Recommended)

Next.js users: Upgrade to the following patch versions or higher:

# Next.js v16
npm install next@16.0.7

# Next.js v15
npm install next@15.5.7
# or 15.4.8, 15.3.6, 15.2.6, 15.1.9, 15.0.5

# Next.js v14 Canary
# downgrade to stable v14 or upgrade to fixed v15

React native / custom integrations: Upgrade react, react-dom, and react-server-dom-* to the versions below:

npm install react@19.2.1 react-dom@19.2.1

Official patched versions: 19.0.1, 19.1.2, 19.2.1

Option 2: Mitigation Using WAF

If immediate code deployment isn’t possible (e.g., during a network freeze), use a Web Application Firewall (WAF).

Why WAF Matters for React RCE

Even if you patch this RCE, unknown vulnerabilities will always exist. A WAF like SafeLine provides:

Defense against unknown threats: Detects abnormal payloads, serialized data, and suspicious patterns that traditional rules miss.
Minimal false positives: Uses semantic analysis to distinguish malicious requests from normal traffic.
Continuous protection: Updated in real-time as new attack techniques emerge.

SafeLine WAF ensures that your full-stack React/Next.js apps stay protected even when you don’t yet know the next attack vector.

04 Full-Stack Security Considerations

React’s move across client and server boundaries complicates security. With Server Actions, developers can write backend logic directly in components — but this exposes HTTP-accessible endpoints.

CVE-2025-55182 is a wake-up call: you can patch today’s RCE, but tomorrow’s unknown vulnerabilities demand proactive protection.

Key takeaway: Patch your frameworks and deploy a WAF like SafeLine to defend against both known and unknown threats.

CrowdStrike AI agents reverse engineer malware and prioritize patches without human intervention.

Wed, 17 Sep 2025 21:17:21 +0000

CrowdStrike's Threat AI and Risk-Based Patching: Autonomous Security at Machine Speed

CrowdStrike deploys AI agents that reverse engineer malware and prioritize patches without human intervention.

CrowdStrike announced two capabilities that fundamentally change how organizations handle threat detection and vulnerability management. Threat AI introduces autonomous agents that can reverse engineer malware and hunt threats independently, while Risk-based Patching unifies security and IT operations through intelligent vulnerability prioritization.

Threat AI: Beyond Traditional Threat Intelligence

Traditional threat intelligence requires analysts to manually reverse engineer malware, correlate indicators, and hunt for threats across environments. CrowdStrike's Threat AI automates these workflows using autonomous agents trained on decisions from their Counter Adversary Operations team.

The Malware Analysis Agent can analyze suspicious files, identify code similarities, provide attribution, and generate YARA rules in seconds. This represents a significant shift from the current approach where malware analysis can take hours or days.

The Hunt Agent continuously scans environments for emerging threats, executes queries, and surfaces findings with actionable recommendations. Instead of periodic threat hunting exercises, organizations get continuous autonomous monitoring.

Technical Implementation Details

Both agents operate within CrowdStrike's Threat Intelligence and Hunting modules, leveraging the Enterprise Graph data layer announced yesterday. This architecture allows agents to reason across multiple data sources without requiring custom integrations.

The agents generate YARA rules automatically, which is significant for security teams. YARA rules help detect malware families rather than individual samples, scaling protection across entire threat categories. Manual YARA rule creation requires deep expertise and time that many organizations lack.

The Browser Extension adds contextual intelligence directly into analysts' workflows, providing CrowdStrike's threat data during external research without switching applications.

Risk-Based Patching: Solving the Security-IT Divide

The Risk-based Patching capability addresses a persistent organizational problem: security teams identify vulnerabilities using one set of tools, while IT teams deploy patches using completely different systems. This creates delays that attackers exploit.

CrowdStrike's approach combines Falcon Exposure Management with Falcon for IT to create a unified workflow. Exposure Management identifies which vulnerabilities are most likely to be exploited based on adversary activity and attack paths. The IT module then applies patches with safety controls to prevent system downtime.

The Technical Architecture

The system uses ExPRT.AI scoring to prioritize vulnerabilities based on real-world exploitation likelihood rather than just CVSS scores. This matters because many high-CVSS vulnerabilities are never exploited in practice, while some lower-scored vulnerabilities become active attack vectors.

Patch Safety Scores use sensor intelligence to assess the risk of applying specific patches to individual systems. This helps IT teams understand which systems can be safely patched immediately versus those requiring maintenance windows.

The single-agent architecture means organizations don't need separate tools for vulnerability scanning, patch management, and endpoint protection. Everything operates through the Falcon platform.

Impact on Development and Operations Teams

For development teams, the Threat AI capabilities provide faster feedback on security issues. Instead of waiting for security analysts to manually review suspicious code or indicators, autonomous agents can provide immediate analysis and recommendations.

The unified patching approach simplifies DevOps workflows by eliminating handoffs between security and IT teams. Development teams can see vulnerability priorities and patch status through a single interface rather than coordinating across multiple tools.

Practical Applications

Organizations can now automate threat hunting that previously required dedicated analysts. The Hunt Agent can monitor for specific adversary techniques, emerging malware families, or indicators of compromise without human intervention.

For incident response, the Malware Analysis Agent can provide immediate context when suspicious files are detected. Instead of escalating every unknown file to analysts, the system can quickly determine if it matches known malware families or represents a new threat.

The patching system addresses the common scenario where security teams identify critical vulnerabilities but struggle to get them prioritized by IT teams who lack context about exploitation likelihood.

Security Considerations

The autonomous nature of these systems raises questions about oversight and control. CrowdStrike emphasizes that analysts remain in command, with agents designed to augment rather than replace human decision-making.

The agents operate within predefined rules and can explain their reasoning, which helps maintain accountability. However, organizations will need to establish governance frameworks for autonomous security actions.

Integration with Existing Workflows

The Browser Extension suggests CrowdStrike recognizes that analysts work across multiple tools and platforms. Rather than forcing workflow changes, they're bringing intelligence into existing research processes.

The Model Context Protocol integration announced yesterday means these agents can collaborate with other AI systems, potentially creating more comprehensive automated workflows.

Strategic Implications

CrowdStrike's approach represents a bet that the future of cybersecurity lies in autonomous systems rather than human-operated tools. As attack speeds increase, human response times become insufficient.

The unified platform strategy also positions CrowdStrike to expand beyond traditional cybersecurity into IT operations, potentially competing with established systems management vendors.

Implementation Considerations

Organizations adopting these capabilities will need to retrain security teams to work alongside autonomous agents rather than performing manual analysis. This represents a significant shift in security operations.

The effectiveness of the AI agents depends on the quality of CrowdStrike's training data and threat intelligence. Organizations should evaluate how well the agents perform in their specific environments before relying on them for critical decisions.

Looking Forward

The combination of autonomous threat hunting and intelligent patch prioritization addresses two major pain points in enterprise security. Whether this approach proves effective at scale will depend on how well the AI agents adapt to new threats and how successfully organizations integrate them into existing processes.

For now, the technology provides a clear path toward more automated security operations, potentially freeing human analysts to focus on strategic planning and complex investigations rather than routine analysis tasks.

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.