Security Awareness in the AI Era (1): Personal Prevention

Security incidents have been making frequent headlines across the software industry. The problems extend beyond individual products: widely used programming languages, runtimes, and frameworks have also been affected. PHP and Node.js, for example, have both had serious vulnerabilities.

When Ilya Sutskever left OpenAI to found SSI (Safe Superintelligence), with safety as its mission, the news sparked widespread discussion. To be honest, we found it hard to grasp the urgency at the time. But as AI capabilities have grown and attack techniques have evolved, we have begun to understand why security in the AI era deserves so much attention.

In the past, an attacker with the skills to exploit vulnerabilities was still constrained by their own time. There were only so many hours they could spend finding weaknesses and carrying out attacks. Today, that same person can direct dozens or even hundreds of AI agents to search for vulnerabilities, dramatically accelerating the process.

Another observation from recent software security discussions deserves attention. The companies behind models such as GPT and Claude invest heavily in safety alignment, training their models to follow safety guidelines and avoid assisting harmful behavior. When an attacker tries to use these models to conduct an attack, the models tend to refuse.

Some open-weight models, however, have not received comparable investment in safety alignment. This makes it easier for attackers to bypass safety restrictions. As these models become more capable, the barrier to obtaining powerful AI tools may fall further. Against this backdrop, we can expect attacks to become more frequent.

We plan to explore this topic in a three-part series. This first article focuses on prevention: what individual engineers can do in their day-to-day work to reduce their exposure. The second will cover incident response, including how to react quickly and limit the damage when something goes wrong. The final article will look at the team level, discussing the processes and practices senior engineers can introduce so that security does not depend entirely on individual vigilance.

What Security Habits Can Engineers Build?

Recent incidents offer plenty of lessons that software engineers can apply to personal projects and at work. If your company has not adopted these practices yet, you could be the person who gets the conversation started. Let's go through them.

Pin Dependency Versions

Many recent software security incidents have had such a wide reach because they occurred upstream in the software supply chain. In our earlier article on avoiding reinventing the wheel through APIs, we discussed the industry's long-standing habit of reusing existing work. Much like a physical supply chain, software development does not require making every component yourself. Some components come from upstream providers.

In this environment, keeping dependencies up to date has long been considered a best practice. It helps teams avoid outdated versions with known vulnerabilities. Tools such as Dependabot and Renovate, which many engineers have used at work, became popular for precisely this reason.

If a vulnerability is discovered in a version you use, and you have not kept up with updates, jumping straight to a patched release can be difficult. Many developers know how painful that catch-up work can be.

Several major supply chain attacks in recent years have taken a different approach. Instead of exploiting weaknesses in older releases, attackers have gained publishing access and released new versions containing malicious code. Users who update without noticing the compromise then become exposed. In the Laravel-Lang supply chain attack in the PHP ecosystem, attackers even rewrote Git tags for existing releases, replacing the code behind an already published version with malicious code.

In either case, pinning dependency versions is a useful habit. Unless an update addresses an urgent security issue, it also makes sense to wait for a cooldown period before adopting it. For example, the earlier Axios incident involved version 1.14.1, which was identified as malicious shortly after its release. Users who did not update immediately were generally spared the immediate impact.

In July 2026, GitHub announced that Dependabot would apply a three-day cooldown to routine version updates by default. GitHub studied widely reported supply chain attacks between 2018 and 2026 and concluded that waiting three days could avoid most of the malicious releases that were quickly detected and removed. Three days is no guarantee, of course. But given how quickly community security researchers currently identify these threats, a cooldown can reduce the chance of being among the first victims. Some research recommends waiting longer: Google Cloud's security research, for example, recommends a seven-day cooldown.

Version pinning should also be paired with a lockfile. Depending on the package manager's design, a lockfile records integrity hashes for the corresponding Git commits. With PHP's Composer, for example, running composer install against an existing lockfile avoids resolving dependency versions again, reducing the risk of unknowingly fetching a replaced package.

If an attacker modifies a published release so that the same version number points to different code, the recorded Git commit hash can help distinguish the replacement from the original. This reduces the risk of an unintended update.

Reduce Third-Party Dependencies and Maintain Your Own Forks When Needed

The previous section covered precautions for using dependencies. A more radical view has also been gaining attention: reconsider how much you rely on third-party packages in the first place. Mitchell Hashimoto, a well-known engineer in the open source community, argues that a better approach is to fork dependencies, maintain them yourself, and remove the functionality you do not need. Under this approach, you only update when users are actually affected, and every update should be justified by a specific code change you need.

This challenges some familiar assumptions about the software supply chain. Installing a large dependency for one small feature may cost more than it is worth. More fundamentally, the goal is to regain control over the code you depend on. If the version you maintain already meets your needs, there is no reason to upgrade or add features. In Hashimoto's view, doing so can reduce exposure to vulnerabilities.

This position has often been criticized as impractical. Maintaining a fork takes work, and for complex packages, it can seem almost impossible. But with AI agents taking on a growing share of implementation work, that cost is becoming lower than it once was. As a result, more teams have begun exploring this approach.

Support ExplainThis

If you found this content valuable, please consider supporting our work with a one-time donation of whatever amount feels right to you through this Buy Me a Coffee page.

Creating in-depth technical content takes significant time. Your support helps us continue producing high-quality educational content accessible to everyone.