The Self Defending Computer

We have spent decades building better security software. We can detect malware, spot suspicious behavior, isolate a compromised machine and alert the security team when something goes wrong.

We still have one basic problem. When a vulnerability is found, the fix depends on a chain of people and hand offs. Someone investigates the incident, identifies the software, contacts the vendor, reproduces the problem, writes a patch, tests it, releases it, and then waits for administrators to deploy it. Meanwhile the vulnerability stays exploitable on thousands or millions of computers.

The computer that detected the problem did so in seconds. The permanent fix can take weeks. Why does the machine that found the problem have to wait for everyone else to catch up?

I have been thinking about a different approach. I call it the self defending computer. It rests on three ideas.

Every computer runs a trusted security agent. When it detects a vulnerability or an attempt to exploit one, it does not just raise an alert and wait. It applies an authorized countermeasure: block the execution path, restrict the application’s permissions, disable the exposed feature, isolate the process, or disconnect the machine from the network. The response depends on severity, confidence and the organization’s policies.

It then notifies the Security Operations Center with the evidence needed to investigate and find other affected systems. At the same time it sends a sanitized technical report to the software vendor through an authenticated channel: the component involved, the behavior observed, the evidence and the countermeasures already applied.

The agent does not rewrite the operating system or modify applications on its own. It contains the threat, gathers evidence and starts the process that leads to a permanent fix.

This is where AI changes vulnerability management. Once the vendor receives a credible report, automated systems reproduce the vulnerability in an isolated environment, find the defect and propose a correction. AI helps engineers examine the code, suggest changes and generate tests that prove the hole is closed. Security, regression and compatibility tests run before anything ships.

Simple vulnerabilities could move through most of this without a person. Complicated ones still need engineers to investigate and approve. The point is not to remove developers. It is to remove the dead time between finding a defect and starting work on it.

The vendor signs the patch and releases it through its trusted update channel. Affected computers verify the signature, test the update where practical, install it according to policy and confirm the vulnerability is gone. If anything fails, the computer stops, keeps its protective measures in place and reports the failure to the SOC.

A CVE identifier is the common reference the whole industry uses for a vulnerability. A CVE Numbering Authority, or CNA, can assign those identifiers within its authorized scope.

Here is my question: if a company builds and maintains a product, why shouldn’t it take direct responsibility for identifying, documenting and disclosing vulnerabilities in that product?

CNA status does not prove a vendor writes secure software, and its absence does not prove the opposite. But every organization should ask its vendors whether they are a CNA, which products that covers, how they handle reports and how fast they can coordinate a fix. A vendor that is not a CNA should have a defined process for working with one. Customers should never have to guess who is responsible for documenting a vulnerability.

I would go further and make vulnerability response part of procurement. When two products otherwise meet the requirement, the vendor that can identify vulnerabilities, coordinate CVE assignment, ship patches and report remediation status should win.

In the self defending computer model, that documentation stops being a separate administrative chore. When a CNA vendor confirms a vulnerability, its workflow checks for an existing CVE, determines whether the issue qualifies, reserves an identifier under the CVE Program rules and coordinates publication with the patch. The patch fixes the defect. The CVE record gives everyone the same reference. Both move together, with disclosure timing set by the circumstances and with the safeguards the program requires: confirm the vulnerability, avoid duplicates, stay within scope.

The SOC stays essential. The difference is visibility across the full lifecycle: when the vulnerability was detected, what countermeasures were applied, whether the vendor acknowledged the report, whether a patch is in development, and which computers have installed and verified it.

That last point matters most in a large organization. A released patch is not a remediated environment. Some machines are offline, some are incompatible, some are under change freeze, some fail the install. The SOC needs to know the difference between a vulnerability the vendor has fixed and one that is actually gone from every system it owns. Every endpoint reports its status, and the SOC can see exactly which systems remain at risk.

A system that automatically modifies software and pushes updates to millions of computers is a prize for attackers. Compromise the vendor’s update infrastructure and the defense becomes the delivery mechanism for an attack. A false positive could take down a business process. A bad AI generated patch could open a new hole.

So the model needs strong authentication, cryptographic signatures, protected channels and controls that stop unauthorized parties from filing trusted reports or distributing updates. Deployments are staged and reversible. The agent has clear limits on what it may do without a human: routine, low risk countermeasures automated, high impact changes approved. No endpoint installs a patch because the update claims to fix something. It installs because the patch is verified. And no automated system turns an unverified alert into an authoritative CVE record.

Automate the work. Keep the controls that make the work trustworthy.

None of this is science fiction. Endpoint products already take automated defensive actions. SOC platforms already correlate and orchestrate. AI already assists with code analysis and test generation. Vendors already sign and distribute updates. The CVE Program already exists.

What is missing is the connection between them: trusted interfaces for endpoints to report, vendors equipped to act on those reports quickly, secure pipelines to build, validate, sign and ship patches, CVE assignment inside that pipeline, and a SOC that can see the outcome. Procurement should reward the vendors that get there first.

No system prevents every attack, and not every vulnerability can be fixed by a machine. The goal is to make vulnerabilities less dangerous by shrinking the time between discovery, containment, correction and verification. Today we treat those as four separate problems. They should be one continuous process.

Every computer should be able to defend itself. Every vendor should be equipped to fix what it ships. Every organization should be able to verify the fix worked. That is the self defending computer, and it is worth building.