The Era of Attacking the “Process,” Not the Program
When people talk about software security, they usually think of vulnerabilities inside the program itself. Buffer overflows, authentication bypasses, and SQL injections are typical examples. For a long time, both security research and attacks have centered around these kinds of weaknesses. Attackers analyzed the internal structure of programs, crafted unexpected inputs, and tried to break systems or escalate privileges. Security practices evolved accordingly, focusing on discovering and patching these vulnerabilities.
However, a series of incidents over the past few years has made it clear that this traditional perspective is no longer sufficient. Attackers do not necessarily need to hack the program itself. In fact, there is a far more efficient approach: attacking the entire process through which software is created and distributed.
This approach is simpler than it sounds. Before the program is distributed, an attacker only needs to insert malicious code somewhere along the process. This can be done by compromising update servers, manipulating build systems, or injecting malicious code into developer tools. In this way, the attacker does not target just a single program—they can simultaneously compromise every user of that program.
This is the very essence of the rapid rise of software supply chain attacks in recent years.
The Target of Attacks Is Changing
Traditional hacking targets specific systems. A single server, a company, or the network of a particular organization becomes the focus of an attack. These attacks are dangerous, but at the same time, their scope is limited. Even when attackers succeed, the damage often remains confined within a relatively specific boundary.
Supply chain attacks, however, operate in a completely different way. The target is no longer the end user. Instead, the process that delivers software to those users becomes the primary objective.
This difference is larger than it might initially seem. If an attacker gains control of a program’s update server, they can distribute malicious code to countless computers using that program at the same time. Users believe they are installing a normal update, but in reality, they are executing code planted by the attacker.
In this structure, the efficiency of an attack increases dramatically. Attackers no longer need to hack numerous individual systems. Instead, they only need to take control of a single central point. That point is often the development environment, build system, distribution server, or developer tools.
And it is precisely at this point that the target of attacks begins to shift in a more interesting direction.
Why Developer Tools Become the Target of Attacks
Software is built with code, but that code is always written through tools. Text editors, IDEs, compilers, build systems, and package managers are typical examples. Developers use these tools to write, build, and distribute programs.
This implies an important fact: developer tools are the starting point of countless software systems.
If an attacker compromises the tools used by developers, they can influence every program those developers create. This is not merely an attack on a single program—it is an attack on the entire process of creating that program.
For example, imagine that an IDE or compiler has been manipulated to inject malicious code. Developers would believe they are writing normal code. However, the actual built program could include code planted by the attacker. Once that program is distributed to users, the attack spreads naturally.
In this structure, developers become both victims of the attack and unwitting distributors of it. Attackers do not need to hack developers directly. Instead, they only need to take control of the tools developers use.
The Invisible War
One of the reasons these attacks are particularly dangerous is that most users are not even aware of their existence. Vulnerabilities inside programs often leave visible signs—systems behave abnormally, data is leaked, or services are disrupted.
Supply chain attacks, however, proceed much more quietly.
Users install what appears to be a normal update. Developers use what seem to be legitimate tools. Programs appear to run as expected. Yet inside, malicious code inserted by an attacker may be hidden. In some cases, that code can remain undetected for months, or even years.
These attacks are also technically complex. Attackers are not simply looking for vulnerabilities; they must understand the entire software development and distribution process. Build systems, update mechanisms, code signing frameworks, and package management structures can all become targets.
But it is precisely this complexity that makes the impact of a successful attack far greater than one might imagine.
Why This Topic Matters
Most of the software we use today exists on top of a vast supply chain. A single program depends on dozens of libraries, and those libraries, in turn, rely on other projects. Developer tools, package repositories, build systems, and CI/CD environments are all interconnected, forming a massive ecosystem.
This structure has made software development remarkably fast. At the same time, however, it has created a new attack surface. Attackers no longer need to dig into the internals of a program. Instead, they can target the process through which the program is created.
Several incidents over the past few years have made this reality unmistakably clear. There have been cases where update systems were compromised, distributing malicious code to countless users. In other cases, developer tools themselves became channels for delivering malicious code. There have even been instances where state-level attacks were carried out through the software supply chain.
This series aims to examine those incidents one by one.
Emerging Threats Around Developer Tools
In the next article, we will look at several major real-world supply chain attacks. In some cases, it was not the program itself but the update system that was compromised. In others, developer tools became the very channel through which malicious code was distributed. In yet other cases, build systems were breached, leading to simultaneous attacks on organizations around the world.
These incidents are not merely isolated security breaches. They are signals that reveal how the nature of attacks in the software world is fundamentally changing.
In the past, hackers attacked programs. Now, attackers target the process of creating those programs.
And at the very center of that process, developer tools always exist.
