Hello!
Lately, I have been seeing far more reports about software vulnerabilities.
In October 2026, reports of a PHP vulnerability affected many websites around the world. There have also been numerous reports of vulnerabilities in Node.js and Linux.
▼ Report on the php2shell vulnerability
▼ Report on Node.js vulnerabilities
▼ Report on Linux vulnerabilities
AI-assisted cyberattacks have attracted particular attention recently. With developments such as the release of open-weight models by Chinese AI companies, powerful AI is becoming available at relatively low cost. If attackers can use AI to investigate vulnerabilities and explore attack techniques more efficiently, it is entirely plausible that the scale and speed of attacks will grow further.
Looking at these developments, I feel that the cybersecurity landscape is entering another phase of change.
In my own day-to-day work, I have also had more opportunities to think about security. Protecting systems seems to be becoming an even more important area in which software engineers can apply their expertise.
So what do companies really need to protect their own systems?
Security specialists and the people and systems that detect vulnerabilities are certainly important. But I believe it is even more important to have a development organization capable of continuously changing its systems quickly.
The Asymmetry Between Attackers and Defenders
Once attackers find a vulnerability in a target system, they can launch attacks at scale and in parallel. Defenders, on the other hand, need to change or fix their systems to address those vulnerabilities.
Making those changes often involves the following steps, especially in large organizations:
- Investigating the vulnerability
- Identifying the affected areas
- Planning and implementing a fix
- Checking that existing functionality still works
- Checking for problems after the release
Each step may also require approval across departments. In practice, even applying a single security patch can involve a great deal of coordination.
Development Organizations Need Agility
Ideally, development teams should own their systems and be able to investigate the impact, make the necessary changes independently, and release quickly with automated tests. They should be able to carry out this sequence continuously. What does it take to build that kind of organization?
Based on my experience, I believe the following are important:
- Establishing automated tests
- Building CI/CD pipelines
- Maintaining internal software quality and accumulating knowledge
- Creating an organizational culture that gives development teams autonomy
Let’s look at each of these in turn.
Establishing Automated Tests
First, I consider automated tests the most important foundation.
The larger a system becomes, the more testing is needed to check that changes do not break existing functionality. Without adequate automated tests, even a library version update requires people to check existing features manually.
With appropriate unit, integration, and end-to-end tests, however, the effects of a change can be checked automatically.
This is particularly valuable when using dependency update tools such as Dependabot or Renovate.
These tools automatically create pull requests to update dependencies. But if every update requires manual verification, that work becomes a major bottleneck. A system may get built successfully, yet end up poorly maintained. With appropriate automated tests, passing results provide confidence that existing functionality still works, allowing teams to apply security patches and update dependencies quickly.
Simply having automated tests is not enough, though. They also need to be maintained properly.
For example, if tests rely heavily on mocks, the behavior of those mocks can drift away from the actual implementation. Tests may pass while problems occur in production, leaving the test suite ineffective. Likewise, if tests are not maintained as requirements change, they can no longer verify the system’s current behavior accurately.
I think it is important to see automated tests as executable documentation that expresses the system’s specifications, as well as a means of checking quality.
Such tests give development teams confidence that they can change their systems safely, helping them respond to security issues with greater agility.
The following book offers an accessible explanation of how to think about and write automated tests, if you are interested:
Building CI/CD Pipelines
The next important foundation is CI/CD.
Even with a comprehensive automated test suite, teams cannot achieve sufficient agility if developers must run it manually every time, or if releases require many procedural steps.
Once CI has passed, teams should be able to move quickly through the production release process. Automating deployment procedures also makes a rapid response possible.
Beyond automating deployment itself, I think it is essential to make gradual rollouts, rollback mechanisms, and post-release monitoring part of everyday development work.
Recently, AI agents working with MCP and APIs have made forms of automation possible that would have been difficult just a few years ago. Putting these capabilities in place appropriately also matters for protecting systems.
Maintaining Internal Quality and Accumulating Knowledge
Automated tests and CI/CD can only work effectively when the software has sufficient internal quality.
Imagine spaghetti code with tangled dependencies between modules, where changing a single feature affects the entire system. In such a system, even writing automated tests becomes difficult. Testing a feature independently may be hard, or running a test may require a large number of mocks.
By contrast, software with appropriate modularity and separation of concerns makes it easier to understand the scope of a change and write tests for individual responsibilities.
In my own work, I find it difficult to write effective automated tests for large functions or classes with complex dependencies. To make tests serve as executable documentation of the system’s specifications, it helps greatly to write tests for implementations designed with the SOLID principles in mind.
Building software that is easy to change requires deliberate attention to design in everyday work, together with continuous refactoring. That ease of change improves agility in feature development. It also helps teams keep their systems secure by adapting quickly as circumstances change.
Another important element is accumulating knowledge about the system.
Organizations need to continuously record their architecture, design decisions, and the knowledge required to operate their systems. I feel that implementation by AI agents has recently become a foundation of development. To support their implementation decisions, we also need to organize and accumulate knowledge in forms those agents can reference. That knowledge matters both for helping AI maintain security appropriately and for enabling the organization to close security gaps more quickly.
Creating a Culture That Gives Development Teams Autonomy
Finally, there is the organizational side.
Even with all the technical foundations described above, I do not think an organization can fully benefit from them unless its development teams can act autonomously.
When a serious vulnerability is discovered, can the team investigate its impact, decide what action is needed, and carry the fix through to release? Or must it wait for instructions from a manager or another department?
The former is clearly preferable. In my everyday work, I often say that we need to change systems, organizations, and people together. Building a clear, effective organizational structure is a crucial part of that.
Of course, security responses require appropriate risk assessment and oversight. Development teams should not make every decision entirely on their own. But organizations can define authority and responsibility in advance, allowing teams to independently decide on and execute changes that meet agreed conditions.
To achieve this, I think it is important to break down organizational silos and minimize the number of communication handoffs.
If development, operations, security, and business departments operate independently, and every change requires coordination across several departments, the response will inevitably be slower.
I think this problem becomes even more complicated when development depends heavily on external vendors.
Outsourcing itself is not the problem. But when the people managing vendors lack sufficient technical knowledge, how well can they assess the software’s internal quality? It is possible to maintain sufficient development agility while drawing on external expertise, provided that vendors are expected to establish automated tests and CI/CD, and that the organization can continuously assess internal quality. If those considerations are missing and decisions focus solely on reducing development costs, investment in internal quality is likely to be cut.
When every library update requires manual QA, or even a minor fix requires extensive release coordination, teams may be unable to apply patches quickly when a serious vulnerability is discovered.
These issues make me think it is important to establish some in-house development capability and give the company’s own development teams a degree of ownership over its systems.
As AI makes system security increasingly important, we need to pay closer attention to how the entire development cycle is organized and improve it.
Closing Thoughts
Looking at these points, we can see that the ideas considered important for building modern software development organizations remain important in the AI era.
If an organization takes weeks to deliver even a minor feature change, is it realistic to expect it to suddenly respond quickly only when a serious vulnerability is discovered?
Security specialists and mechanisms for detecting vulnerabilities are certainly necessary. But even if excellent specialists discover vulnerabilities and propose appropriate countermeasures, those efforts do little to resolve the underlying problem unless the organization can apply the changes to its actual systems.
We need both the ability to discover security problems and the ability to change systems to resolve them.
The recent wave of vulnerability reports prompted me to organize these thoughts. I hope to keep working toward even small improvements as we face this changing world.