Skip to main content

The code you did not write — the invisible risk in modern software

Your website rests on thousands of open building blocks you never see. In 2026 they are under attack as never before. Here is what a developer owes you.

By Lars Henrik Netland

Produced with AI tools, edited and fact-checked by the author

Last updated: 25 June 2026

A modern website or web application typically consists of a few thousand lines of code the developer wrote themselves, and hundreds of thousands of lines from open libraries other people wrote. That is not cheating. It is how all modern software is built, and it is the reason a small business today can get solutions that would have cost millions to build from scratch.

But it also means something very few people think about: most of the code your business runs on has been read by neither you nor your developer.

What has happened over the past year

Until recently, attacks on these open building blocks were mostly an irritation for developers. That has changed. The security company Sonatype has now blocked more than 1.2 million malicious packages in open code libraries in total. Over 450,000 of them came in 2025 alone, an increase of 75 per cent from the year before.

And 2026 has been worse. Some examples from recent months:

  • In March, axios, one of the world's most used JavaScript libraries with around 100 million weekly downloads, was hijacked via a single compromised maintainer account. For about three hours, everyone who installed the library got malware thrown in.
  • In May, node-ipc, a foundational library with over 10 million weekly downloads, was published in three poisoned versions designed to steal passwords and keys.
  • In June, 32 packages in Red Hat's official namespace were compromised, via an employee's hijacked account, bypassing all code review.

The common denominator: attackers no longer go after your business directly. They poison the building blocks everyone uses, and let the software itself carry the infection onwards. Several of this year's attacks have been self-replicating: malware that automatically spreads to new packages.

Why this concerns a small business in Norway

It is tempting to think this is a problem for the big players. It is not, for a simple reason: the attacks are automated. A poisoned building block does not distinguish between a global web shop and a local business on Haugalandet. It runs wherever it lands.

The consequences land with you regardless. If your web shop is built on a compromised component, payment details can be skimmed at the checkout. If your contact form has a poisoned dependency, customer data can leak. And responsibility for the personal data sits with your business, not with an anonymous code library.

An average commercial codebase today contains over 900 open components, and nine out of ten have components that are more than four years old. That is a lot of code nobody is watching.

What a responsible developer actually does

The good news is that the defence is not magic. It is discipline, and it looks roughly like this:

  • Locked versions. The project installs exactly the versions that have been tested and approved, never "the latest version, whatever that may be". Then it does not matter if a poisoned version is published tomorrow; it does not come along.
  • Review before updating. Dependencies are updated deliberately and under control, not automatically and blindly. New versions are allowed to mature a little before being taken into use.
  • As few dependencies as possible. Every building block that is not needed is removed. Less code from others means less attack surface.
  • Install scripts turned off where possible. It is precisely these scripts that most of this year's attacks use to run malware the moment the package is installed.
  • Regular security audits. Automated checks that raise an alert when a component in the solution gains known vulnerabilities.

These are not exotic measures. They are craft. We use them ourselves on everything we build and operate, and they are part of the reason we security-test solutions before they launch.

This is not an argument against open source

Let it be perfectly clear: open source is the foundation of modern software development, and it is a good thing. The alternative, where every developer writes everything themselves, would give more expensive, worse and less secure software. The problem is not the open building blocks. The problem is using them without discipline.

The questions you can ask your supplier

You do not have to be technical to take this seriously. Three questions go a long way:

  1. How do you handle dependencies in our solution? A good answer mentions locked versions and controlled updates. A bad answer is "it updates itself".
  2. Are we told if a component in our solution gains a known vulnerability? The answer should be yes, and preferably automatically.
  3. Who is responsible for keeping this up over time? If the answer is unclear, in practice nobody is.

A supplier who takes these questions in their stride probably takes the rest of the craft seriously too. One who gets vague is worth following up.