AI and vulnerabilities: php2shell, Massive Patch Batch, Mythos and more

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:

• More software can be built with fewer resources. More applications may reach production without security review.
• Existing vulnerabilities become easier to discover. More findings need validation, prioritization, and remediation.
• Attackers get assistance developing exploits. Defenders 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” 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.

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.

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.

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

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.

Each situation forces a different decision:

• A patch is available. How quickly can we validate and deploy it?
• The patch fails testing. How do we address the failure while managing the exposure?
• No patch is available. Can 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?