I've been examining code with Claude Security and making improvements based on the results. I'm no security specialist, but I now have another way to inspect what I've built, from an angle different from everyday implementation and review. Writing code every day doesn't mean seeing its weaknesses every day. I'm glad to have the help.

Then a critical PHP vulnerability named "PHP2Shell" was disclosed. Although I don't normally write PHP, I ended up investigating the impact on our company's corporate site and responding to it. A company's systems rarely arrange themselves neatly around the languages you know best. A technology you thought you didn't use may be running quite happily just beyond your usual field of view.

I also read reports that AI had helped discover the vulnerabilities, and thought about the same possibility for the languages and frameworks I use daily. AI-assisted discovery must, however, be distinguished from AI use in an attack (Wiz: PHP2Shell write-up). Around the same time, GMO Internet Group disclosed unauthorized access to its "Onamae.com Desktop Cloud" service. Its disclosure described the intrusion route as under investigation; neither a connection to PHP2Shell nor AI use in the attack had been confirmed (GMO: second report). These facts cannot simply be joined into one story, but they gave me plenty of reason to reconsider our own preparation.

My day job is designing, building, and running web applications. Without a dedicated security person, developers also take on defense alongside that work. Reducing insecure code and limiting the damage from an intrusion both belong in that responsibility. Once a problem is known, there is also the work of getting a fix out. The more useful code inspection tools become, the more I find myself thinking about whether we can carry the work forward from there.

The work after a finding

According to its official documentation, the Claude Security plugin for Claude Code maps the codebase, builds a threat model, and searches for vulnerabilities. Separate agents then verify the findings, and it can also propose patches based on the results. I've already been using it to make improvements, but what it gives me is evidence to investigate the code. Accumulating a record of having run a tool doesn't fix the code by itself.

Cloudflare's security-audit-skill is interesting too. Its README gives coding agents a procedure for mapping code structure, trust boundaries, and input paths, then searching for problems while recording the scope covered. A separate agent subsequently tries to disprove the findings. The report distinguishes confirmed findings, those needing further verification, and refuted ones. I haven't tried this tool myself, but having the investigation and verification procedures published is useful.

When reading such results, I care about how far a finding has been verified, beyond the number of findings. Are there areas that haven't been examined? Does a claim need further investigation, or does it hold up? Even an empty report describes only a limited scope of inspection. It is too early to turn that into a verdict of safety. Claude Security's documentation likewise describes using it alongside static analysis, dependency scanning, and code review (official documentation).

That is why I want to connect AI audits to everyday development. CI can repeat checks for known vulnerabilities and rule-based issues, while AI investigates problems involving code context and combinations of operations. Manual inspection alone gets missed when things are busy, and different people bring different perspectives. Running checks both on PRs and on a schedule should be easier to sustain than inspecting things whenever we happen to remember.

What to inspectExample toolsWhat to look for
DependenciesDependency Review, npm auditDependencies with disclosed vulnerabilities
Our own codeCodeQL, SemgrepInsecure implementations
Secrets in the repositoryGitleaksCommitted API keys and private keys
Containers and infrastructure configurationTrivyPackage vulnerabilities and misconfigurations
Running applicationsZAPProblems visible in responses, HTTP headers, and similar behavior

GitHub's Dependency Review, for instance, inspects dependency changes in a PR and can fail a check when a vulnerable dependency is introduced. CodeQL analyzes source code, while Trivy and ZAP inspect other targets. The tool depends on what needs examining, and a new vulnerability disclosure can change the results without a code change. That is why I don't want to limit these checks to PRs.

More opportunities for detection also mean more results to read. Someone needs to own the notifications, the conditions for blocking merges, false positives, and findings that cannot be fixed immediately. Otherwise, the main thing growing may be an impressive unread count. What I want is a process in which valid findings become fixes, rather than a particularly substantial report.

Can we get the fix out?

Once a finding holds up, fix it and preserve it as a test. The tests I want here extend beyond checking that a newly built feature works. I also want to confirm that unauthorized operations are rejected. For an application managing data per organization, supplying another organization's data ID must not allow reading or writing that data.

Can a read-only user update data by calling the API directly? Can extra request fields be used to rewrite organization membership or permissions? AI can help identify these cases and implement tests. OWASP's testing guide likewise treats authentication, authorization, and session management as distinct areas to examine (Web Security Testing Guide). This broadens the scope beyond the operations we usually check during feature development.

Of course, inferring the expected behavior entirely from the current implementation would be a problem. If that implementation is wrong, the tests may faithfully preserve its mistake. A person needs to confirm the permission rules and specifications before supplying them. Before celebrating passing tests, I want to check what we decided the correct answer was.

There are also cases like PHP2Shell, where a vulnerability is disclosed in the technology we use. Auditing our own code alone cannot address that. We need to know what is used where, including dependencies, runtimes, container base images, CMSs, and plugins. For systems operated by another company, not knowing whom to ask or who performs updates slows us down from the impact assessment onward.

Even with the impact understood, deciding on an update is difficult without a way to verify behavior afterward. Automated checks for login and core business flows reduce the burden of tracing everything by hand each time. Tests help us apply patched versions as well as find implementation mistakes. Passing them doesn't establish that nothing is wrong, but it makes an update much easier to judge than having no evidence at all.

Then we need a way to get the change into production. We should also consider rollback, taking the service offline when necessary, and revoking or rotating credentials. Investigating logs and restoring backups belong here too: reduce the work we would otherwise research for the first time when it becomes necessary. AI can help organize architecture and procedures, but we still have to confirm that we can actually carry them out. A runbook existing is not the same as being able to recover.

Seen this way, code audits, CI checks, tests, and understanding architecture and operations form a continuous piece of work. Find a problem, verify the finding, fix it, check the behavior, and get it into production. Roll back if it fails, and limit the impact when necessary. An unknown step can stop the response there. A patch being ready on my machine has not yet changed the system our users depend on.

Finding time for quiet work

If this preparation always took priority, it wouldn't be much of a problem. Updating a library or runtime doesn't brighten the interface like a new feature, and doesn't necessarily increase revenue. Why spend time on something that works now? Explaining that to people outside engineering takes effort. The engineer doing the update also faces compatibility issues and verification work.

Meanwhile, feature development and support requests are waiting. Those jobs matter too, so updates gradually move down the queue. That is especially likely without a dedicated owner, and I'm doing this work alongside normal development myself. I have little appetite for dismissing all that accumulated work as laziness.

Over time, the original engineer may leave while the system keeps running, with nobody remaining who understands its specifications or architecture. Nobody knows quite what it does, but everyone knows stopping it would be a problem. At that point, each update starts with archaeology. Time passes while we rediscover where things are used, who owns them, how to verify a change, and how to undo it.

This doesn't explain the root cause of PHP2Shell itself. It is about how accumulated circumstances on the user side affect the time it takes to apply a fix after a major vulnerability is disclosed. The UK's NCSC assesses that AI will improve the ability to exploit known vulnerabilities and further shorten the interval between disclosure and exploitation (Impact of AI on cyber threat from now to 2027). Time spent on routine updates, tests, and records of architecture and procedures also shortens the investigation we will need then.

That's how PHP2Shell led me to reconsider the improvements I'm already making and the preparation needed beyond them. I'm already using Claude Security and acting on the results. I want to connect that work to CI checks and tests, and stay able to get updates out. I don't expect to make every judgment on my own as a non-specialist, but there is work I can take on in everyday development.

Now that we have more tools for finding problems, I want us to remain capable of fixing what they find.

References