ENISA advisory examines package manager security risks
Developers install external libraries with a single command, and that step can introduce more code than expected into a project environment. Dependency resolution inside package managers extends software supply chains across large collections of external components. ENISA’s Technical Advisory for Secure Use of Package Managers, released in March 2026, examines how this development practice expands exposure across software ecosystems.
Package managers retrieve libraries from public repositories and integrate them into applications. Tools such as npm, pip and Maven allow teams to add functionality by installing prebuilt components. Applications inherit layers of dependencies that development teams did not write or review.
Installing one package can introduce many additional components once direct and transitive dependencies resolve. Each package becomes part of the project’s dependency graph and remains present in the development environment after installation. Projects may contain modules that remain unused during execution, yet each component still carries vulnerabilities, maintenance history and trust assumptions.
“This document focuses on how developers can securely use package managers as part of their software development life cycle. In particular, the document outlines common risks involved in the use of third-party packages, presents secure practices for selecting, integrating and monitoring packages, and describes approaches for addressing vulnerabilities found in dependencies,” ENISA said.
Widely used libraries create large ecosystems
Popular packages appear in tens of thousands of projects and form large dependency ecosystems across software development. Dependency relationships extend across applications, frameworks and supporting components that rely on shared packages.
Weaknesses in widely adopted components can propagate across many downstream applications through these relationships. Vulnerabilities in common frameworks or libraries can spread across large portions of the web application landscape.
Supply chain attacks and vulnerable packages
Security risks within package ecosystems fall into two categories. One category includes vulnerabilities in package code, configuration or design. Another category includes attacks that target the software distribution process.
Vulnerable packages can remain available long after maintainers abandon them. Projects that rely on outdated or unmaintained components can inherit vulnerabilities that remain unresolved for long periods.
Propagation of vulnerabilities (Source: ENISA)
Supply chain attacks introduce additional paths for malicious code to reach development environments. Attackers may publish malicious packages, compromise maintainer accounts or manipulate dependency resolution processes to insert harmful code into software projects.
Compromised packages can distribute malicious code across downstream applications through automated installation and update processes. Development environments that retrieve packages from public repositories may install compromised components without direct review of their internal code.
Security practices follow the dependency lifecycle
Managing dependency risk requires security controls across the package lifecycle. Practices fall into four stages: selecting packages, integrating them into projects, monitoring their security status and mitigating vulnerabilities.
Package selection begins before installation. Developers review the origin of libraries, maintainer activity, vulnerability history and repository reputation. Verification of cryptographic signatures and use of trusted registries support trust decisions during this stage.
Integration introduces controls that preserve integrity during installation and build processes. Software bills of materials record the components included in a project. Dependency lockfiles and hash verification maintain consistency across environments. Continuous integration pipelines include vulnerability scans that identify known issues during builds.
Monitoring continues after dependencies become part of the application environment. Teams track vulnerability disclosures, maintainer activity and new releases that address security flaws. Alerts for new CVE entries, deprecated versions and ownership changes support awareness of dependency risk.
Mitigation begins when a vulnerability appears inside a dependency. Developers assess exploitability and reachability within their systems. Remediation includes updating packages, replacing vulnerable libraries or applying patches.
Future considerations for dependency management
Growing dependency ecosystems increase the need for automation across security practices. Automated tools support dependency tracking, vulnerability monitoring and remediation workflows across complex software environments.
Development workflows also change as AI tools assist with programming tasks. LLMs generate code and recommend libraries during development. These systems can introduce new dependencies into projects and may select packages that developers did not evaluate.
Projects that integrate AI-assisted development workflows require oversight to ensure that new packages introduced into the codebase receive the same verification and security review applied to manually selected dependencies.
Dependency chains created by package managers remain a core feature of software development. Each installation expands the software supply chain behind an application. Security practices follow those dependencies from selection through monitoring and remediation across the lifecycle.