What the AI Era Means for Defenders

It’s been just over six months since Project Glasswing was announced, and we’re still starting to understand what it means for the industry.

For me, it solidified my beliefs. InfoSec defenders need to adopt more of the practices that good development teams already use: Infrastructure as code, CI/CD pipelines, and automated testing give organizations a way to make changes quickly with evidence that those changes will work.

That matters when sophisticated attackers can move faster and less-skilled attackers gain capabilities they previously lacked.

The pressure comes from several directions

AI has made development cheap. New software is coming online from people who don’t have security teams, sometimes without anyone who knows what a security review should involve.

At the same time, AI is helping find vulnerabilities in software we already depend on. These are separate problems, with different implications for defenders:

What’s changingWhat defenders need to account forMore software can be built with fewer resourcesMore applications may reach production without security reviewExisting vulnerabilities become easier to discoverMore findings need validation, prioritization, and remediationAttackers get assistance developing exploitsDefenders may have less time to address an exposed vulnerability

An increase in reported vulnerabilities doesn’t necessarily mean software has become worse. We may be finding problems that have existed for years. Anthropic’s early Glasswing update described verification, disclosure, and patching as constraints on handling its findings. Anthropic’s Glasswing update

For practitioners, the question is how much additional remediation work their organization can actually handle.

“Just patch it” is awful advice

First, you have to identify the criticality of a patch and weigh it against all the other patches waiting for attention.

Do you use CVSS? Your own internal scoring? Does cyber intelligence tell you which vulnerabilities are being actively exploited by the threat actors that most affect your organization or industry?

Then you have to find the owner.

The server may be secure. The application code may be secure. But a dependency in the base layer of the container image your organization standardized on is vulnerable.

```mermaid
flowchart TD
    V["Vulnerable dependency"] --> I["Shared base container image"]
    I --> A["Application A<br/>Team A"]
    I --> B["Application B<br/>Team B"]
    I --> C["Application C<br/>Team C"]
    A --> T["Coordinate the update and validate affected workflows"]
    B --> T
    C --> T
    T --> P["Deploy across affected applications"]
```

The person maintaining that image has to coordinate with multiple teams and accept the risk of breaking something outside their control.

Being nervous about patching is understandable when you have no reliable way to determine whether a change will disrupt the business. Getting past that requires investment in how changes are tested and delivered.

Confidence comes from testing what customers do

I’ve worked in an environment where a code change could go from a developer’s laptop to production in roughly 90 minutes.

They followed testing best practices, including unit and integration testing. But the most important part was automated user acceptance testing. They understood what customers needed to accomplish and tested those requirements.

Consider a hypothetical document-upload application:

A parsing library has a vulnerability, and the vendor releases a patch. After updating it, can the customer still upload a document and complete the workflow successfully?

Installing the dependency successfully doesn’t answer that question. Neither does testing an individual function in isolation.

The pipeline should give you evidence about the complete workflow before the change reaches production.

```mermaid
flowchart LR
    P["Apply patch<br/>in QA"] --> T["Run automated tests<br/>including customer workflows"]
    T --> D{"Requirements<br/>still met?"}
    D -- Yes --> R["Promote to production"]
    D -- No --> I["Investigate failure<br/>and decide how to handle exposure"]
    I --> P
```

Imagine upgrading your dependencies and having the pipeline tell you whether the application still meets its user requirements. You could repeat that process throughout the day instead of treating every update as a separate negotiation.

Tests cannot guarantee that nothing will go wrong in production. But they can give teams a much stronger basis for making a change. Practiced recovery procedures help them handle the cases where something does go wrong.

Exploitation doesn’t wait for your change window

Finding a bug, producing a reliable exploit, and successfully attacking an environment are different steps. Improvements in any of them can reduce the time available to defenders.

The October 21 PHP disclosures made the operational problem concrete. The UK’s NCSC advised organizations to consider taking affected systems offline where immediate remediation wasn’t feasible. NCSC advisory

Taking a service offline can be the correct decision. It still interrupts a service the business depends on.

SituationDecision the team needs to makeA patch is availableHow quickly can we validate and deploy it?The patch fails testingHow do we address the failure while managing the exposure?No patch is availableCan mitigations sufficiently reduce exposure, or must the service go offline?

None of these situations is helped by discovering during the incident that nobody knows who owns the component.

I believe organizations should work toward deploying changes during peak hours. You can document change requests all day, but documentation doesn’t establish that the application will work afterward. Confidence has to come from the engineering and testing behind it.

There are exceptions. Manufacturing, healthcare, and pharmaceutical environments have certification requirements and business risks that can make rapid changes much more complicated.

For organizations with more flexibility, though, it’s worth asking: does your change window reflect a real constraint, or a lack of confidence in your deployment process?

Start with the outcome you need to prevent

An organization with a vulnerability backlog and unclear ownership cannot build all of these capabilities tomorrow.

My advice is to start with the outcome you want to prevent and work backward through the attack. For ransomware, look at what prevents an attacker from encrypting files after gaining access. Defenders need protection for the point at which earlier controls have failed.

That’s the approach behind SecuritySnares:

• Its minifilter driver evaluates file activity to determine whether encryption is occurring.
• If the process performing that encryption isn’t trusted to do so, SecuritySnares terminates it.

An attacker may use AI to develop variants or change how they gain access. The encryption behavior is what SecuritySnares evaluates.

That protection belongs alongside reducing exposure and improving patch deployment. It addresses the outcome we’re trying to prevent while teams continue the broader work of improving their environments.

Better software is coming. We still have systems to protect today.

I’m optimistic that AI will help us produce better, more secure software. I also expect a long, painful transition as development becomes accessible to more people and security practices catch up.

The practices that make patching less frightening are available today. Adopting them means understanding what customers need, testing those requirements, and building a deployment process the organization can trust.

When the next critical patch arrives, can you deploy it when it’s needed?

Are you confident?

10:51 PM

Just Patch It is great advice! Organizations should be able to push patches automatically, with confidence the moment it comes out. The e2e tests should show that.

10:53 PM

I mistook your frustration with organizations’ ability to patch for disagreement with the advice itself. “Just patch it” is exactly the capability you want organizations to build. That should be the central argument.

I’d replace that section with:

“Just patch it” should be how we operate

Organizations should be able to take a patch as soon as it becomes available, run it through their pipeline, and automatically deploy it when the tests pass. The confidence to do that comes from knowing the application still meets its users’ requirements.

I’ve worked in an environment where a change could go from a developer’s laptop to production in roughly 90 minutes. The most important part was automated user acceptance testing. They understood what customers needed to accomplish and tested those workflows end to end.

Imagine a document-upload application with a vulnerable parsing library. When the patch comes out, the pipeline updates the library and tests the complete workflow. Can the customer still upload the document and accomplish what they need? Those tests should establish whether the patched application is ready for production.

```mermaid
flowchart LR
    A["Patch released"] --> B["Pipeline applies update"]
    B --> C["Automated end-to-end tests"]
    C --> D{"User requirements met?"}
    D -- Yes --> E["Automatically deploy"]
    D -- No --> F["Hold deployment and investigate"]
```

Shared dependencies and multiple application owners make this more complicated, but those relationships should be accounted for in the pipeline before an emergency. A standardized container image used by ten applications should trigger the relevant tests for those applications when it changes.

“Just patch it” is great advice. If following it makes your organization nervous, that tells you where the engineering work needs to happen.