Dependency and Software Supply Chain Security: Watching for Risk in the Code You Use

Modern business applications are almost never written entirely from scratch. Developers use hundreds, even thousands, of third party libraries and components: for the interface, payments, sending email, image processing, and much more. This approach saves time and cost, but carries a consequence rarely discussed outside technical circles: you inherit the security risk of every component you use.

In recent years, attacks targeting the software supply chain have become more frequent. Attackers no longer break into your system directly; they infiltrate popular libraries, build services, or developer accounts, then wait for the tainted component to reach thousands of applications. Businesses that were never a target can be affected.

This article explains dependency and software supply chain security for business owners and decision makers. The aim is not to make you a security expert, but to help you ask the right questions of your team or vendor, understand sensible basic practices, and avoid the most common oversights.

Summary

• Every third party library is part of your application's attack surface
• Risk comes from known vulnerabilities and from deliberately tainted components
• A list of the components in use is the basis for all further security steps
• Routine, controlled updates are safer than postponing until they pile up
• Supply chain security involves people, process, and tools, not just one product

Why dependencies are a business issue

An ordinary web application might directly load only a few dozen libraries, but each library itself depends on other libraries, and so on. When all layers are counted, the number can reach hundreds or thousands of components written by people you do not know, maintained by volunteers, and updated without your involvement.

Each of those components is code that runs with the same access rights as your application. A problematic library can read customer data, steal access keys, or open a back door. What makes it hard is visibility: without tools and process, most businesses do not know exactly which components run in their systems.

From a business viewpoint, the impact is real: customer data leaks, service outages, reputational damage, legal obligations, and recovery costs. All of this happens not because you were careless in the code you wrote, but because of other people's code that you trusted.

Types of supply chain risk

Risk in dependencies is not uniform. Understanding the types helps determine suitable defences, because dealing with an old vulnerability differs from dealing with a deliberately tainted component.

• Known vulnerabilities: flaws in published library versions that can be exploited
• Malicious packages: libraries deliberately made to steal data or run harmful code
• Maintainer account takeover: an attacker gains control of a legitimate library developer's account and releases a tainted version
• Typosquatting: malicious packages named like popular libraries installed through a typing mistake
• Dependency confusion: the build system pulls a malicious public package in place of an internal one
• Compromised build: build and publishing tools or services are infiltrated
• Abandoned libraries: components without maintainers so vulnerabilities are never fixed

The last category is often underestimated. A library that was once popular and is now unmaintained still runs in many applications, and when a new vulnerability is found, nobody fixes it. Recognising abandoned components is an important part of risk management.

First step: know what you use

You cannot protect what you do not know. The most valuable first step is to have a complete list of the components the application uses, including version and origin. This list is often called a software bill of materials, or SBOM, and is increasingly requested by corporate customers and regulators.

This list should be generated automatically from the build process, not compiled by hand where it quickly goes stale. With the list, when a major vulnerability is announced, you can answer within minutes: do we use that component, in which application, and which version? Without a list, the answer takes days of tracing.

1. 01Automatically generate a list of direct and indirect components for every application
2. 02Record the version, source, and licence of each component
3. 03Store the list with each release so it can be traced backwards
4. 04Connect the list to continuously updated vulnerability information sources
5. 05Flag components that are critical, unmaintained, or have problematic licences

Vulnerability scanning and fix priorities

Scanning tools can compare your component list against databases of known vulnerabilities and warn if there is a match. This is cheap and automatic, so it should be part of the build process. But these tools can also produce many warnings, and this is where human judgement is needed.

Not all vulnerabilities are equally dangerous to you. A severe flaw in a function you never call may not be exploitable, while a moderate flaw in an internet facing component can be very dangerous. Prioritise by severity, whether the component faces the public, and whether there is a known active exploit.

Also determine who is responsible. An alert without an owner will not be resolved. Each application should have a clear person or team that receives, assesses, and closes findings, along with agreed timeframes for each severity level.

Updates: a small discipline with a big impact

Many major incidents occur not because of new vulnerabilities, but because fixes were available for months and not applied. Postponing updates for fear of breaking something feels safe, but actually piles up risk and makes the next update larger and more frightening.

A healthier approach is small, frequent updates, supported by automated tests that give confidence changes do not break important functions. Small updates are easier to test, easier to roll back, and easier to trace the cause if there is a problem.

• Security updates applied promptly after testing, not waiting for a big window
• Major version updates scheduled regularly with time for testing
• Enough automated tests so changes can be validated quickly
• A rollback plan if an update causes problems
• Tools that propose updates automatically for human review

Choosing and assessing components before using them

The cheapest prevention happens before a component enters your application. Before using a new library, ask a few simple questions that can be answered in minutes: is it actively maintained, how many people use it, is there a history of security problems, and what is its licence. These checks matter even more when code is written with an AI assistant, which sometimes suggests outdated or even non existent libraries, as discussed in AI assisted software development.

• Maintenance activity: last release, response to issues, and number of maintainers
• Popularity and usage: widely used components get more scrutiny from others
• Vulnerability history and the speed of fixes
• The number of dependencies it brings, because each addition enlarges the attack surface
• A licence compatible with your business model
• Whether its function is truly needed or could be written simply yourself

The last question is often overlooked. Pulling in a large library for one small function adds risk needlessly. Sometimes writing a few lines of code yourself is safer than adding a new dependency, as long as the function is simple and does not involve sensitive matters such as cryptography.

Securing the build and release process

The supply chain is not only about the libraries you pull in, but also how your own application is built and delivered. If your build system is compromised, an attacker can slip malicious code into your own product, then have it distributed to your customers with a signature that looks legitimate.

• Access to code repositories and build systems with multifactor authentication
• Minimum access rights for accounts and tokens used by automated processes
• Secrets and keys stored in dedicated places, not in code
• Code review by a second person before changes are merged
• Pinning dependency versions so builds are repeatable and consistent
• Recording who changed what and when across the whole release flow

Secrets embedded in code are a classic mistake. Access keys stored in a repository, especially a public one, can be found and abused within minutes. Use a secrets manager, and scan repositories automatically to detect secrets accidentally stored.

The supply chain beyond code: vendors and services

Your business's supply chain also includes third party services connected to your systems: payment providers, analytics services, customer support tools, and more. A script loaded from an outside service into your online store pages can steal payment data if its provider is compromised.

Control what is allowed to run in your systems. Limit third party scripts to those truly needed, use a content security policy that restricts script sources, and periodically review connected external services. Every integration is trust you grant; make sure it is deserved.

For software vendors you buy or rent from, ask about their security practices: how they manage dependencies, how quickly they fix vulnerabilities, whether they provide a component list, and how they notify customers during an incident.

Licences and compliance of open source components

Besides security, dependencies carry a legal aspect: licences. Every open source component comes with terms that determine how it may be used, modified, and distributed. Some licences are very permissive, others require opening derivative code or including attribution. Ignoring them can lead to disputes or force product changes at an inconvenient time.

The same component list used for security can also be used to check licences. Set a simple policy on which licence types are accepted, which need review, and which are prohibited for your product. That way developers can decide quickly and the legal team only handles cases that truly need attention.

This matters especially if you sell applications to customers, offer software as a service, or are preparing for investment or acquisition. Whoever assesses your business will almost certainly check licence compliance, and a tidy list speeds up the process.

Balancing speed and security

There is a natural tension between moving fast and being careful. Product teams want new features released quickly, while security controls feel like a brake. The way to resolve it is not to pick one, but to make security controls an automatic part of the workflow so they add almost no friction.

Automatic scanning on every change, automatically proposed updates, and licence checks that run in the background give protection without adding large manual work. Only exceptions and high risk findings need human decisions, so the team's attention goes to what matters most.

Readiness for incidents

However good the prevention, incidents can still happen. Preparation determines whether the incident is controlled or becomes a crisis. Plan in advance: who is contacted, how to assess impact, how to isolate affected systems, and how to notify customers and authorities if needed.

An accurate component list helps greatly during incidents. When a major vulnerability is announced, a team with a list can quickly know whether it is affected and where, then fix it before attackers get a chance to exploit it. A team without one must grope around while time keeps running.

Practise this plan like a fire drill. Simulate a scenario, for example a popular library is announced to be tainted, and trace what would be done. A simple one hour exercise often reveals gaps that are invisible on paper.

Realistic first steps

1. 01Ask your team or vendor to generate a component list for your most important application
2. 02Enable automatic vulnerability scanning in the build process
3. 03Set owners, priority thresholds, and fix timeframes for each severity level
4. 04Adopt a routine update habit supported by automated testing
5. 05Move secrets from code to dedicated storage and enable secret scanning
6. 06Review third party scripts and services running in your systems and remove those not needed
7. 07Draw up a short incident plan and practise it once a year

Questions worth asking your team or vendor

The following questions do not require technical expertise to ask, but the answers reveal a lot about a team's maturity. A clear and confident answer is a good sign, while a vague or defensive one points to areas that need improving before an incident occurs.

• Do we have a complete list of the components our application uses, and how current is it?
• How are we told when there is a vulnerability in a component we use?
• What is the average time from a critical vulnerability announcement until the fix is applied?
• Who can change our code and release process, and how is that access protected?
• Where are secrets and keys stored, and who can access them?
• What would we do if a popular library we use turned out to be tainted?

Closing

Software supply chain security is not a problem to be solved once and forgotten. It is an ongoing discipline: knowing what you use, monitoring vulnerabilities, updating routinely, choosing components carefully, and securing the build process.

For business owners, the most important step is asking the right questions and making sure there is an accountable owner. With a few consistent basic habits, you can enjoy the benefits of third party components without carrying uncontrolled risk.