You Probably Didn’t Write Most of Your Application, And That’s Okay

When developers talk about building software, we often imagine writing code from scratch. But modern software development doesn’t really work that way anymore.

Perhaps you installed packages from PyPI, npm, or Maven. Maybe you pulled a Docker image, used GitHub Actions to automate deployments, or integrated APIs from Paystack, Stripe, Twilio, or OpenAI.

Now ask yourself this question:

How much of that application did you actually write?

Probably far less than you think.

In fact, most modern applications are built using thousands of lines of code written by people we’ve never met. And that’s not a bad thing.

Open source has transformed software development. Instead of solving the same problems repeatedly, developers build on work that already exists. We can launch products faster, innovate more quickly, and focus on solving the problems unique to our applications rather than writing every library ourselves.

Modern software is less about writing every line of code and more about assembling trusted building blocks. But that convenience comes with a trade-off.

Every dependency we install, every container image we pull, every GitHub Action we use, and every third-party service we integrate becomes part of something much larger.

Our software supply chain.

What Is a Software Supply Chain?

When people hear the phrase software supply chain, they often think it refers only to open-source packages. It is much bigger than that. Your software supply chain includes every component involved in building, testing, packaging, and delivering your application.

That includes:

• The open-source libraries you install from repositories like PyPI, npm, and Maven.
• The dependencies those libraries depend on.
• Your source code repositories.
• Your CI/CD pipelines.
• Build scripts and automation workflows.
• Container images.
• Artifact repositories.
• Secrets used during deployment.
• Third-party APIs and cloud services.

If any one of these components is compromised, the security of your application may also be compromised.

Security is no longer just about protecting your own code. It is about protecting everything your code depends on.

Why Attackers Are Changing Their Strategy

Years ago, attackers often focused on breaking into organizations directly. Today, many have realized there is a much more efficient approach. Instead of attacking one company at a time, why not compromise something that thousands of companies already trust?

Imagine maintaining a popular open-source package downloaded millions of times every month. If an attacker successfully injects malicious code into a single release, every developer who installs that version may unknowingly bring the attack into their own environment.

One compromise, thousands of victims.

This is exactly why software supply chain attacks have become one of the fastest-growing security threats.

We’ve Seen This Before

Software supply chain attacks are no longer theoretical. Several high-profile incidents have demonstrated just how far a single compromise can spread.

The SolarWinds attack showed how compromising a trusted software update could affect thousands of organizations downstream. The event-stream incident in the Node.js ecosystem demonstrated that even a small open-source package could become an attack vector after a malicious update. More recently, the xz Utils backdoor reminded the industry that attackers are willing to spend years building trust before attempting to compromise critical software used across systems.

Different attacks. Different techniques. The same lesson.

Trust can become an attack surface.

Common Ways Software Supply Chains Are Attacked

Attackers don’t always exploit vulnerabilities in your application.

Sometimes, they simply exploit your trust.

Dependency Confusion

Imagine your company has an internal package called payments-utils. If an attacker publishes a package with the same name to a public package registry, a misconfigured package manager may download the malicious version instead of the private one.

The attacker never touched your source code. They simply exploited how dependencies are resolved.

Typosquatting

Sometimes attackers rely on something even simpler.

Human error.

Suppose you intend to install Instance. Instead, you accidentally type a package with a nearly identical name 1nstance. If that package contains malicious installation scripts, your development environment may be compromised before you’ve written a single line of code.

One missing letter can become a security incident.

Compromised Maintainer Accounts

Developers trust package maintainers.

Attackers know this.

If they gain access to a maintainer’s account through credential theft or the absence of multi-factor authentication, they can publish malicious updates under the name of a trusted project.

To everyone else, it looks like a routine software update.

CI/CD Pipeline Compromise

Modern software doesn’t go directly from a developer’s laptop into production.

It passes through build pipelines.

If an attacker compromises that pipeline, they can inject malicious code during the build process, even when the source code itself appears completely legitimate.

The software reaches customers carrying code that reviewers never saw.

Building a More Secure Supply Chain

No organization can eliminate every risk.

But we can make the supply chain significantly more resilient.

1. Know What You’re Shipping

You cannot protect what you cannot see.

A Software Bill of Materials (SBOM) is essentially an inventory of everything included in your application. Just as food products list their ingredients, an SBOM lists the software components that make up your application.

When a new vulnerability is discovered, an SBOM allows organizations to quickly identify whether they are affected.

2. Scan Dependencies Continuously

Open-source software evolves rapidly.

A dependency that was considered safe six months ago may contain a newly discovered vulnerability today. Tools such as Dependabot, Snyk, Trivy, and other Software Composition Analysis (SCA) tools help identify vulnerable dependencies before they reach production.

Security should become part of the development pipeline rather than an afterthought.

3. Pin Versions

Allowing package managers to automatically install the latest version of a dependency may seem convenient. It can also introduce unexpected changes.

Using lock files such as package-lock.json, poetry.lock, or similar mechanisms ensures every environment installs the exact versions that were tested.

Predictability is an important part of security.

4. Protect the Build Pipeline

Your CI/CD pipeline deserves the same level of protection as your production environment.

Enable multi-factor authentication for maintainers. Protect sensitive secrets. Use short-lived credentials where possible. Restrict permissions using the principle of least privilege.

Because once attackers control your build pipeline, they control what your users eventually install.

Whats hapening

Software supply chain security continues to evolve.

Organizations are increasingly adopting frameworks such as SLSA (Supply-chain Levels for Software Artifacts) to strengthen build integrity and improve the security of software artifacts.

At the same time, Zero Trust principles are expanding beyond users and networks into software delivery pipelines, treating every stage of the build process as something that must be verified rather than automatically trusted.

The goal isn’t to stop using open source. Quite the opposite. Open source has made modern software development possible.

The goal is to understand what we depend on, verify what we install, and reduce the amount of trust we place in any single component.

Final Thoughts

Modern software isn’t built in isolation.

Every application we develop is connected to thousands of other components maintained by developers, communities, and organizations across the world.

That collaboration is one of the greatest strengths of today’s software ecosystem. It is also one of its biggest security challenges.

Software supply chain security reminds us that protecting an application isn’t just about securing the code we write. It is about understanding everything that helped build it.

Because sometimes the most dangerous vulnerability isn’t hiding in your own code at all. It’s hiding in code you trusted without ever reading.

Keep learning, keep building, and remember, I’m always rooting for you.