The first major prompt for thinking about security was the unauthorized access to Times Car. Its first report, published on September 25, 2026, disclosed that members’ personal information might have leaked externally. The cause and scope of the incident were still under investigation.

The potentially affected group included former members as well as current ones. The information listed included names, addresses, driving-license details, and identity documents. The handling of information entrusted to a service can remain an issue after someone stops using it. That belongs in the responsibilities we consider when building applications.

More data-breach announcements followed. On October 19, LIXIL disclosed unauthorized access to L-Pocket and L-Pocket Lite and the leakage of registration information for 3,379 people, including members, employees, and former employees. The information included business details such as company names, addresses, and departments, as well as names and email addresses. This extends beyond services aimed at individual consumers.

On October 20, NEC disclosed information leakage following a cyberattack on a subcontractor. Stolen credentials for legitimate accounts were used to access customer systems, and files in cloud storage shared among the parties were also confirmed to have leaked. Those files contained personal information and system-related information. Inspecting our own application does not finish the job of examining the contractors handling it or the environments used to share information.

When we build services that hold information, finding and fixing vulnerabilities is only part of the work. What do we retain, and for how long? Who can access it, and how much? Can we investigate the impact and respond when something happens? Times Car and these other incidents are starting points for thinking back through those questions in our own everyday development.

In my own work, 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.

Another concern was the disclosure of a critical PHP vulnerability named "PHP2Shell." 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). There is no basis here for treating these incidents, including Times Car, as having the same cause. I want to keep the facts separate while using them 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.

What to keep, and when to let it go

Later, the fifth report, published on October 23, 2026, described traces of external transmission involving 6,628,007 records containing names, addresses, driving-license information, and other details, plus 1,464,800 encrypted identity-document images. External transmission of encrypted images does not by itself mean their contents were viewable. Even with that distinction, the figures give weight to the information a service holds.

The Times Car report says identity-document images had been retained throughout membership and for seven years after withdrawal. It announced a new rule of not retaining the images after registration verification. Retention periods themselves belong in security decisions.

For our own systems, I want to be able to explain why each item is collected and how long it is needed. Data kept because it might be useful later still carries a responsibility to protect it. If storage is implemented but deletion conditions are undecided, keeping it becomes the default behavior. It is difficult when the people securing a system inherit every field added for convenience.

Deletion extends beyond removing a database row. If the same information remains in image storage, logs, or backups, their purposes and retention periods need to be considered too. The aim is to decide why records are kept and how they will be removed, while preserving records that remain necessary. Encryption should not become a reason to ignore retention.

For information that must be kept, limit access to what applications and operators need for their work. Consider how far a compromise of one part could affect another. The code audits and authorization tests that follow are ways to implement and check those decisions.

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 does not explain Times Car's internal circumstances or 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.

Starting with announcements of information leaks and unauthorized access at Times Car and elsewhere, this is how I think about the security work an application engineer can take on. Reviewing retained data and permissions belongs alongside finding problems and getting fixes out. 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 take responsibility from deciding how entrusted information is handled through fixing what those tools find.

References