ENISA on Package Managers: The Hidden Security Risks Behind Modern Software Dependencies

In March 2026, ENISA (the European Union Agency for Cybersecurity) published its first Technical Advisory on the secure use of package managers. Package managers such as npm, pip, Maven, and NuGet help developers build software faster and more efficiently, but they also introduce important software supply chain risks.

The ENISA advisory explains that while package managers make development faster, more collaborative, and more consistent, they also create new security challenges. Third-party packages may contain vulnerabilities, become abandoned over time, or even be intentionally abused by attackers targeting the software supply chain.

You can read the full advisory here:
ENISA Technical Advisory for Secure Use of Package Managers .

A simple npm example

Consider a typical Node.js application. A developer might start a project by installing the popular Express web framework using npm:

npm install express

At first glance this seems simple. One command installs one package. But in reality, installing Express brings in multiple additional libraries. These are known as direct dependencies. Those dependencies often rely on other libraries themselves, creating transitive dependencies.

The result is that a single installation command may introduce dozens of external components into a project.

And most projects continue to grow. Developers may install additional packages such as:

npm install express helmet dotenv mongoose

Over time, more libraries are added for logging, authentication, security headers, database connections, or analytics. Eventually the application may depend on hundreds of third-party components, each maintained by different developers or organizations around the world.

Many teams rarely examine this dependency tree in detail. Yet all of these components run inside the application environment and become part of the trusted software stack.

Why attackers target package ecosystems

This is exactly why ENISA warns that package managers are increasingly becoming targets for attackers.

One attack method involves malicious packages. An attacker publishes a package that appears useful but contains hidden malicious code. If developers install it, the code may run automatically during installation or runtime.

Another technique involves compromising package maintainers. If attackers gain access to a maintainer's account, they can publish a new version of an otherwise legitimate library containing malicious changes. Because the package already has a trusted reputation, many projects will automatically install the update.

There are also simpler attacks such as typosquatting. In this case, attackers publish packages with names that closely resemble popular libraries. A developer who mistypes a package name might accidentally install the malicious version instead of the real one.

ENISA also highlights dependency confusion, where attackers publish packages that share the same name as internal corporate libraries but use higher version numbers. Package managers may then download the malicious public version instead of the intended internal package.

All of these attacks exploit the same reality: modern software ecosystems rely heavily on third-party code.

Understanding what is inside your software

One of the biggest challenges organizations face is simply visibility. Developers often know the main frameworks they installed, but not the full list of components now running inside their applications.

Fortunately, package ecosystems already generate useful information that can help.

Most package managers create lock files, such as:

• package-lock.json
• yarn.lock
• requirements.txt

These files record the exact versions of installed dependencies, including indirect ones. They provide a snapshot of the software components used by a project.

Another increasingly important concept is the Software Bill of Materials (SBOM). An SBOM lists the software components inside an application, including libraries, versions, and relationships between dependencies.

Both lock files and SBOMs help transform a vague dependency stack into a clear inventory of software components.

Turning dependency data into security insight

Having a list of components is useful, but the real value comes from analyzing those components against known vulnerabilities.

By correlating dependency data with vulnerability intelligence sources such as CVE databases, organizations can identify:

• vulnerable libraries
• outdated dependencies
• abandoned packages
• components affected by newly disclosed security issues

This approach allows development and security teams to understand which parts of their software environment may introduce risk.

How BaseFortify can help

This is where BaseFortify can support organizations.

BaseFortify allows users to input dependency information such as package lock files, dependency lists, or SBOM data. The platform then analyzes this information and correlates it with vulnerability intelligence, including enriched CVE reports.

Instead of manually reviewing long dependency lists, users gain practical insight into which software components may introduce security risks.

For smaller teams and SMBs in particular, this visibility can be extremely valuable. It helps organizations move from guessing about dependency risks to understanding exactly which components are present in their software environments.

Getting started with BaseFortify

Registration for BaseFortify is completely free. You can create an account here:

https://basefortify.eu/register

The Starter plan includes features such as device grouping, an asset watch list, vendor monitoring, enriched CVE reports, and the AI assistant.

For professional users, a Premium plan is also available. This plan includes unlimited nodes or device grouping, an unlimited watch list, advice reports on devices, configurable notifications, and OAuth API access.

A growing software security priority

ENISA’s first advisory on package managers highlights an important reality: modern software development relies heavily on third-party components. While these tools accelerate development, they also expand the software supply chain and the potential attack surface.

Organizations do not need to stop using package managers. Instead, they need better visibility into the dependencies their software relies on.

In today’s interconnected development ecosystem, understanding the components inside your software is no longer optional. It is becoming a core part of effective cybersecurity.