ENISA Technical Advisory for Secure Use of Package Managers

TLP - CLEAR

ENISA Technical Advisory for Secure Use of Package Managers

MARCH 2026

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

About ENISA

The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU bodies, and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the Agency works together with its key stakeholders to strengthen trust in the connected economy, to boost resilience of the Union’s infrastructure, and, ultimately, to keep Europe’s society and citizens digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu.

CONTACT

To contact the authors, use product_security@enisa.europa.eu. For media enquiries about this paper, use press@enisa.europa.eu.

AUTHORS

ENISA

LEGAL NOTICE

This publication represents the views and interpretations of ENISA, unless stated otherwise. It does not endorse a regulatory obligation of ENISA or of ENISA bodies pursuant to Regulation (EU) 2019/881. ENISA has the right to alter, update or remove the publication or any of its contents. It is intended for information purposes only and must be accessible free of charge. All references to it or its use as a whole or in part must contain ENISA as its source. Third-party sources are quoted as appropriate. ENISA is not responsible or liable for the content of the external sources, including external websites, referenced in this publication. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication. ENISA maintains its intellectual property rights in relation to this publication.

COPYRIGHT NOTICE

© European Union Agency for Cybersecurity (ENISA), 2026

Unless otherwise noted, the reuse of this document is authorised under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence (https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed, provided appropriate credit is given and any changes are indicated.

Copyright for the image on the cover: © Shutterstock For any use or reproduction of photos or other material that is not under the ENISA copyright, permission must be sought directly from the copyright holders. ISBN 978-92-9204-788-7, ISSN 3094-600X doi:10.2824/6157993, Catalogue number TP-01-26-005-EN-N

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

Table of Contents

About ENISA 1 1. Scope and context 4 1.1 Note on the current version of the document 4 2. Solution architecture and data flows 5 2.1 How package managers work 5

2.1.1 Core elements 5

2.1.2 Example flow 6

2.1.3 Package import and usage 7

2.2 Package manager benefits 9 3. Security risks in package consumption 10 3.1 Packages with inherent vulnerabilities 10

3.1.1 Poor coding or design practices and misconfigurations 11

3.1.2 Discontinued or unmaintained packages 11

3.2 Supply chain attacks 12

3.2.1 Insertion of malicious packages/dependencies 12

3.2.2 Compromised legitimate packages 13

3.2.3 Typosquatting 13

3.2.4 Namespace/Dependency Confusion 14

3.3 Consequences 14 4. Best practices – secure package consumption 16 4.1 Package selection 17

4.1.1 Selection recommendations 17

4.1.2 Cheat Sheet 17

4.2 Package integration 19

4.2.1 Integration recommendations 19

4.2.2 Cheat sheet 20

4.3 Package monitoring 21

4.3.1 Package monitoring recommendations 21

4.3.2 Cheat sheet 21

4.4 Vulnerability mitigation 22

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

4.4.1 Vulnerability mitigation steps 23

4.4.2 Cheat sheet 23

5. Future considerations 25 5.1 Automation 25 5.2 AI-assisted development and “vibe-coding” 26

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

1. Scope and context

Modern software development relies heavily on external packages, libraries and tools obtained through 1 2 package managers such as the npm registry ( ), package installer for Python (pip) ( ) and Apache Maven ( ) repositories. These package managers support software development by providing quick and easy access to vast repositories of third-party code, and often open-source code. However, as recent 4 5 6 7 events have demonstrated ( ) ( ) ( ), they also introduce supply chain risks ( ). This document focuses on how developers can securely use package managers as part of their software development life cycle. In particular, this 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.

The scope of this document is limited to the security considerations involved in consuming packages and managing dependencies within software projects, primarily at the application level. Operating system package managers, secure package publication, security of the package manager distribution channel and secure coding practices, while important, are outside the scope of this document.

Examples listed in this document often reference popular ecosystems and tools like NodeJS's npm package manager and code repository platforms such as GitHub, but the main principles apply across package ecosystems and code repositories.

1.1 Note on the current version of the document

The current version (v1.1) of the document has been released after the ENISA call for feedback ( ) that ran between 17 December 2025 and 20 January 2026. As part of this process, ENISA received 15 additional contributions from public and private stakeholders, cybersecurity experts, software development practitioners and the open-source community. We would like to publicly thank all stakeholders that provided their views and feedback! All contributions have been reviewed and, to the maximum extent possible, the recommendations and observations have been addressed in this final version. This document may go through regular revisions.

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

2. Solution architecture and data flows

2.1 How package managers work

Package managers automate the process of installing, updating, configuring, and removing software libraries and their dependencies. They are an important part of modern software development, enabling code reuse, consistent builds and simplified updates.

While implementations vary across ecosystems, the underlying principles remain the same, i.e. package managers interact with package repositories to retrieve packages, resolve dependencies and integrate them into applications. The table below provides examples of common package managers, their associated ecosystems and links to their official documentation.

Package manager Ecosystem Official link

2.1.1 Core elements

At a high level, package managers work through a set of key elements that allow developers to share, distribute and consume software packages.

• Package. A bundle of code that provides a specific functionality. The code is then packaged and uploaded to a package manager for reuse. • Dependencies. Represent relationships between packages. Each package may rely on other packages, forming a dependency tree. Dependencies of dependencies are referred to as transitive dependencies. • Package developer. The author or maintainer who creates and publishes packages or libraries for reuse by other applications or packages. • Application. The end product or project that makes use of one or more packages to provide extended functionality. • Package repository. A central registry (e.g. npmjs.com, pypi.org, rubygems.org) that hosts published packages and their metadata, allowing developers to search for, download and

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

manage them. The package repository acts as a distributor of the package, making it available and discoverable. • Application developer. The consumer who integrates packages into their applications, relying on the package manager to resolve dependencies, manage versions and ensure consistency. • Package manager. The underlying tool that facilitates the installation, configuration, update and removal of packages and their dependencies. It acts as the intermediary between developers and the package repository.

The diagram below illustrates how package developers publish reusable code modules to a shared repository, allowing application developers to download and integrate these packages into their own projects.

2.1.2 Example flow

The table below shows what happens when an application developer writes a small piece of code that makes use of a package (express) downloaded through the popular Node.js package manager npm.

ENISA Technical Advisory for Secure Use of Package Managers

This process seems straightforward and simple, where with just 10 lines of code a developer can set up a web server by (re)using the popular express web-framework. However, it is important to understand what is happening in the background when the express package and dependencies are included in the project.

2.1.3 Package import and usage

Importing a package does not just add that single module. It also includes all of its direct and transitive dependencies. In our example, importing express brings in around 27 direct dependencies, but a total of 68 packages are installed once all transitive dependencies are resolved.

Ultimately, application developers need to accept that by installing a package and all of its dependencies, the project’s dependency graph increases, together with the potential attack surface. Although commonly referred to as ‘third-party’, once included in your source these components become part of the trusted codebase. As such, they should receive security scrutiny similar to first-party code.

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

However, it is important to note that importing a package does not mean all of its code is executed or even reachable at runtime. For example, when using express to only define a few basic routing endpoints ( ), the application might only execute a small fraction of the package’s total code.

Yet, even when only these basic routing features are used, the code and related dependencies for the unused components, like those handling cookies, sessions, or view engines, are still installed onto the developer's machine along with the express package.

For example, the image above illustrates how only specific parts of a dependency graph may be actually reachable at runtime. In this scenario, My app (index.js) directly invokes express.func1(). This call causes the qs module and the router module (along with its internal dependencies like depd, parseurl and path-to-regexp) to be loaded and become reachable (indicated by the green boxes). Notice that even though router contains other internal modules like debug and depd, these are shown as ‘not directly reachable’ (red) because func1()'s execution flow simply doesn't require them.

The image also shows func2(), which is a function within the express package that My app does not call. Because func2() is never invoked, certain modules it might use, such as content-disposition and

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

its dependency safe-buffer, remain entirely installed but not directly reachable by the application (also indicated by red boxes).

In this context, "not directly reachable" means that the application doesn't explicitly invoke those components. However, it is important to note that this does not guarantee they are entirely isolated. Vulnerable components could still be exposed through unexpected paths (e.g. reflection, misconfiguration, or crafted input). A reachability or exploitability assessment would eventually have to take such possibilities into account.

Ultimately, this distinction is the key to assessing security risk. We must separate installed code (the full content on disk) from reachable code (the portion active during execution). If a vulnerability exists in a module that is never executed, or in a function that is never invoked, the application is less likely to be exploitable.

2.2 Package manager benefits

Packages and package managers bring significant benefits to software development.

• Collaboration. They enable developers to share and reuse modules across projects. • Efficiency. They reduce the need to write functionality from scratch. • Consistency. They promote standardised components and practices. • Maintainability. They simplify updates by centralising dependency management. • Quality. They enable repeated use and testing across many projects, which can improve reliability.

However, this same interconnectedness means that a single vulnerable or compromised package can affect thousands of applications. For example, npm’s express package currently shows nearly 100 000 packages directly depending on it on the official registry. When factoring in transitive dependencies, the total number of projects relying on express can be estimated to be well over a million. This means that a vulnerability in express can potentially introduce a security flaw across a vast segment of the software supply chain, impacting hundreds of thousands of individual projects that rely on it.

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

3. Security risks in package consumption

This section examines the security risks that developers face when consuming third-party packages via package managers. Note that this analysis specifically excludes scenarios involving a compromise of the package distribution repository itself. It also excludes specific vulnerabilities that result from poor coding practices.

While package managers provide several advantages, they also introduce security risks that can affect both developers and downstream users. To better understand these risks, we group them into two main categories:

• packages with inherent vulnerabilities, and • supply chain attacks, as shown in the figure above.

The first category focuses on weaknesses within the packages themselves, whereas the second category covers threats arising from the software distribution process.

3.1 Packages with inherent vulnerabilities

Packages can contain vulnerabilities that result from flaws in their own code, design or configuration. These vulnerabilities may be introduced unintentionally by maintainers or intentionally by malicious actors. Developers making use of third-party packages must recognise that a vulnerability in an imported package can compromise the security of their entire application.

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

3.1.1 Poor coding or design practices and misconfigurations

Packages may include security flaws resulting from unsafe coding or design practices, such as weak input validation or insecure cryptographic implementations. Misconfigurations, like overly permissive defaults or exposed debug modes, can also increase the attack surface.

This document does not attempt to enumerate all vulnerability types introduced by insecure coding practices within third-party packages. Many such weaknesses fall under well-known CWE classes, 10 11 such as improper input validation (CWE-20) ( ), improper limitation of pathname (CWE-22) ( ), sensitive information exposure (CWE-200) ( ) and deserialisation of untrusted data (CWE-502).

When developers consume third-party packages, these vulnerabilities become part of their application’s attack surface, even if the developer did not introduce them directly.

For example, the latest available node-serialize package ( ) contains a known critical deserialisation of untrusted data (CWE-502) vulnerability ( ), with the recommended remediation being to simply not use this package. This issue is compounded by the fact that the project has been discontinued, which leads to the next risk.

3.1.2 Discontinued or unmaintained packages

Unmaintained or abandoned packages, sometimes referred to as open-source abandonware, can pose significant security risks. Without active maintainers, vulnerabilities remain unpatched and dependencies become outdated.

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

3.2 Supply chain attacks

A supply chain refers to the ecosystem of processes, people, organisations and distributors involved in the creation and delivery of a final solution or product ( ). The supply chain can be understood in terms of four key elements:

• suppliers, for example package maintainers; • supplier assets, for example source code, build pipelines, publishing credentials and released packages; • customers, for example application developers who consume the third-party packages; • Customer assets: e.g., the consuming application, its environment, data, and end-users

A supply chain attack typically consists of two linked stages: an attacker compromises a supplier or its assets, and then leverages that compromised supplier to attack the customer ( ). In this model, both the supplier and the customer become targets.

This model directly applies to the package ecosystems. Attackers can attack maintainer accounts, inject malicious code into a package’s build pipeline or manipulate distribution channels, all of which represent attacks on the supplier. Any developer consuming these affected packages becomes a downstream customer, inheriting the compromise at the customer level.

Supply chain attacks often exploit the interconnected nature of the package ecosystem, often targeting its weaker links, i.e. areas where defences may be limited because of their perceived insignificance in isolation, such as an obscure library that only performs only small remedial tasks within a complex software solution. An advantage for attackers is that compromising a single link can affect every application or developer who depends on that link within their chain, allowing the impact to cascade across multiple systems and, ultimately, end users. The following subsections describe common categories of supply chain attacks observed in package ecosystems.

3.2.1 Insertion of malicious packages/dependencies

Attackers can publish entirely new packages containing malicious code with the goal of having application or package developers include their malicious packages as dependencies. When these packages are installed directly or through transitive dependencies, the malicious code executes within these otherwise legitimate applications. As a result, the legitimate applications could end up exfiltrating data and credentials ( ), or performing other malicious activities like cryptocurrency mining.

An example of an inherently malicious package is crypto-encrypt-ts ( ). The npm registry has since flagged this package as malicious but unfortunately, detection is not always immediate, and some malicious packages may remain available for a long time before being discovered.

Malicious package insertion is not limited to traditional software dependencies. Malicious developer extensions, plugins and tooling packages can also serve as vectors to spread malware across

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

development environments. For example, several Visual Studio Code extensions were recently found to contain malware (GlassWorm), directly compromising developer machines through their IDE ( ). This approach follows a similar supply-chain distribution approach through the extension package marketplace instead of package repositories.

3.2.2 Compromised legitimate packages

Even well-established packages can be hijacked through malicious or compromised maintainer accounts, stolen credentials or social engineering. If an attacker manages to gain publishing rights, they can insert malicious code into one or more legitimate packages, which are then proliferated onto downstream projects that depend on these packages.

The event-stream incident ( ) was a notable case in which a malicious package (flatmap-stream) was added by a new maintainer to a widely used npm package, injecting malicious code that targeted a specific cryptocurrency wallet application.

In a more recent incident, multiple legitimate packages were compromised to deliver credentialstealing malware ( ). Instead of introducing the packages as a new maintainer, the attackers gained access to existing maintainers’ accounts through social engineering tactics, and proceeded to publish modified and malicious versions of popular packages.

Similarly, in another incident, attackers gained control of the maintainer’s account of the widely used ua-parser-js packages. The attackers proceeded to add malicious code to the pre-install and postinstall scripts, enabling automatic execution of the payload during installation ( ).

A compromise can also be introduced into previously legitimate and widely used packages. For example, in 2022 the maintainer of the colors and faker npm packages included intentionally disruptive code ( ) that caused dependent applications to fail.

3.2.3 Typosquatting

Package distribution attacks manipulate the way packages are retrieved or resolved by package managers. By exploiting weaknesses in naming, versioning or repository trust, attackers can force victim developers to download unintended or malicious package versions.

Typosquatting is a simple but effective package distribution attack, whereby an attacker publishes malicious packages with names similar to legitimate ones, with the hope that developers will install them by mistake. Examples such as the malicious crossenv package ( ), which purposely chose a

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

name similar to the popular legitimate cross-env package ( ), show how a single mistyped letter can lead to unintentional inclusion of malicious code through misleading package instances ( ).

3.2.4 Namespace/Dependency Confusion

3.3 Consequences

In both cases of inherent vulnerabilities or supply chain attacks, the advantages of package managers, that allow for code reuse and easy integration, can also become their greatest weakness.

As shown in the figure above, a single vulnerable or compromised package can propagate through thousands or even millions of projects and environments. What enables speed and collaboration also enables the proliferation of vulnerabilities, where one malicious dependency can rapidly cascade

ENISA Technical Advisory for Secure Use of Package Managers

across entire software ecosystems. For example, the recent npm supply chain attack, targeting 18

widely used packages with a combined download volume of over 2.6 billion downloads per week ( ), demonstrated how a single coordinated attack can impact a large portion of the Node.JS ecosystem.

Similarly, the recent critical React vulnerability ( ) (CVE-2025-55182), with a CVSS score of 10.0, demonstrates how vulnerabilities in highly adopted frameworks can create an exceptionally large blast

radius. Early analysis estimated that over 12 million websites may be affected ( ), highlighting the scale at which a vulnerability in a widely adopted dependency can propagate.

ENISA Technical Advisory for Secure Use of Package Managers

4. Best practices – secure package consumption

This section describes best practices that developers can follow when consuming third-party packages. For simplification, we describe the package consumption life cycle, as shown in the figure below, in which a developer selects suitable packages, integrates them into the project and subsequently monitors and mitigates any identified issues.

The risks and threats outlined in the previous section, along with the best practices described in this section, align with the stages of the package consumption life cycle.

In the first two stages (package selection and integration), developers should aim to embed secure-bydesign principles and controls, ensuring that security is considered from the outset when incorporating packages into a project. In the latter stages (monitoring and mitigation), developers should aim to implement security controls that sustain and enforce the security posture over time.

The following subsections provide best practice recommendations for each stage of the package consumption life cycle. This is meant to serve as practical guidance that begins with selecting trustworthy packages, continues through secure integration and extends into continuous monitoring and timely mitigation.

NB: The tools and commands included in this section are illustrative examples only and do not represent a recommendation of specific tools. Their suitability, applicability, and impact

ENISA Technical Advisory for Secure Use of Package Managers

depend on the specific environment and should be assessed, tailored, and managed by the implementor.

4.1 Package selection

This stage focuses on evaluating and choosing packages that demonstrate trustworthiness, active maintenance and transparent security practices before inclusion in a project. It is important to note that before evaluating the trustworthiness of a dependency, developers should first assess whether the dependency is actually needed. Reducing the number and scope of dependencies can lower the attack surface and simplify the eventual security management.

4.1.1 Selection recommendations

The following table lists recommendations that can be used to support the security objective of choosing trustworthy, verified and well-maintained packages. Each recommendation represents a specific aspect of package trustworthiness, helping developers evaluate integrity, reputation, maintenance activity and transparency before adoption

4.1.2 Cheat Sheet

The following table complements the selection recommendations by providing practical examples, tools and approaches for package selection. It outlines examples of checks, mainly focusing on npm and GitHub, that can help developers verify provenance, maintainer reputation, update activity and overall security posture when selecting packages. This list is not exhaustive but is intended to serve as a practical starting point for practical secure package selection.

ENISA Technical Advisory for Secure Use of Package Managers

ENISA Technical Advisory for Secure Use of Package Managers

4.2 Package integration

This stage focuses on securely integrating the selected packages into the development and build process. The goal is to maintain package integrity, provenance, and source trust throughout the software build life cycle.

4.2.1 Integration recommendations

The following table lists integration recommendations that support secure and verifiable package use. These recommendations focus on integrity, source verification and automation, ensuring that once packages are selected, they are installed and managed securely.

ENISA Technical Advisory for Secure Use of Package Managers

4.2.2 Cheat sheet

The following table complements the integration recommendations by providing practical examples and commands for their implementation. This list is not exhaustive and examples are primarily drawn from npm and Node.js, but equivalent approaches apply across other package manager ecosystems.

ENISA Technical Advisory for Secure Use of Package Managers

4.3 Package monitoring

This stage focuses on maintaining visibility over the security posture of integrated packages. Monitoring ensures that new vulnerabilities, deprecations, or maintainer changes are detected early, allowing for timely remediation before they can be exploited.

4.3.1 Package monitoring recommendations

The following table outlines controls for maintaining visibility and control over package security after integration.

4.3.2 Cheat sheet

The following table complements the monitoring controls by providing practical examples and tools for their implementation. The list is not exhaustive, and examples are primarily drawn from npm and Node.js, though equivalent practices apply across other package management ecosystems.

ENISA Technical Advisory for Secure Use of Package Managers

4.4 Vulnerability mitigation

This stage focuses on assessing, prioritising and addressing vulnerabilities detected in third-party packages. The detection of a vulnerability in a dependency typically means that under specific conditions, the package contains code that could be exploited. However, this does not necessarily mean that your application is vulnerable as a result of this vulnerability.

Many software composition analyses or static analysis tools tend to report vulnerabilities based on the presence of a specific version of a library that has a known CVE. While these findings indicate a potential risk, they may lack contextual awareness, for example whether the affected function described in the CVE is actually imported, reachable or executed in your codebase.

ENISA Technical Advisory for Secure Use of Package Managers

Effective vulnerability mitigation involves assessing findings to determine their relevance and exploitability before deciding on a prioritisation and remediation.

4.4.1 Vulnerability mitigation steps

The following table outlines the steps a developer can take to mitigate a vulnerability after detection.

4.4.2 Cheat sheet

The following table complements the vulnerability mitigation steps by providing practical examples and tools for their implementation. The list is not exhaustive, but rather serves to provide some practical examples of processes and tools that a developer could use.

ENISA Technical Advisory for Secure Use of Package Managers

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

5. Future considerations

This document is intended to serve as a starting point with concise guidance on package consumption within software projects, encouraging risk aware decision making when consuming and managing thirdparty packages. While many of the listed examples focus on npm, pip and GitHub, the recommendations are designed to apply across package manager ecosystems.

Existing resources, such as OpenSSF’s npm Best Practices for the Supply Chain ( ) and the OWASP NPM Security Cheat Sheet ( ), offer ecosystem-specific detailed implementation guidance. Organisations and developers are encouraged to consult and align with existing guidance and best practices in addition to this document. Activities such as third-party package selection can further benefit from related guidance, including resources from well-established industry organisations such as the OpenSSF Concise Guide for Evaluating Open Source Software ( ) and the CISA Software Acquisition Guide ( ).

The software supply chain landscape continues to evolve, with new tools, processes and risks emerging over time. Therefore, organisations should treat this subject as an ongoing activity and periodically review and update their practices to reflect changes in available tooling, threats and ecosystem-specific guidance. The following subsections provide insight into such evolutions and highlight opportunities like automation and risks like the ones introduced through AI-assisted development.

5.1 Automation

As projects grow in complexity, with hundreds of dependencies across multiple repositories, manual security practices do not scale. Automation, through CI/CD pipelines and dedicated tooling, becomes important to maintain a scalable and secure development workflow.

Most modern CI/CD platforms (e.g. GitHub Actions, GitLab CI, Jenkins) support integration of opensource tools, including:

• Syft or CycloneDX CLI for SBOM generation; • Grype or OSV-Scanner for vulnerability scanning; • native package manager commands such as npm ci --ignore-scripts for dependency integrity and install-script control.

Open-source tools like Syft and Grype have public examples illustrating how to integrate SBOM generation and vulnerability scanning into CI/CD workflows ( ). Similarly, other open-source and

ENISA Technical Advisory for Secure Use of Package Managers Version: 1.1

commercial solutions often include automation features that help enforce these controls at different stages of the software life cycle.

Moreover, initiatives like the CSAF ( ) promote the publication of machine-readable vulnerability advisories. The adoption of machine-readable advisories further enables automation and strengthens vulnerability monitoring and mitigation for third-party packages by allowing vulnerability data to be automatically ingested, correlated and acted upon.

5.2 AI-assisted development and “vibe-coding”

The use of AI-assisted development tools, particularly when most coding is delegated to AI with little or no human review (sometimes known as “vibe coding”), introduces new considerations in the secure use of package managers. With this approach, package selection and integration decisions may be partially or fully delegated to large language models. This can reduce the visibility or understanding on why specific packages were selected and how they are integrated. While AI-assisted development is increasingly used in practice, the implications for the potential introduction of insecure, unnecessary, outdated or vulnerable dependencies must be considered. Moreover, this approach also introduces new attack vectors like ‘slopsquatting’ ( ), where attackers publish packages matching hallucinated package names generated by AI tools.

As a starting point, to address potential risks introduced by AI-assisted software development, the following measures can be considered:

• maintain clear visibility over all packages that were selected and integrated through AIassisted or automatically generated code. • review the necessity and scope of these packages. • automate selection and integration controls, such as those presented in Sections 4.1 and 4.2, where possible (e.g. within CI/CD pipelines). • strengthen vulnerability assessment and mitigation processes, since detection and response become more critical when upfront scrutiny is reduced.

TP -01 -26 -005 -EN -N

ABOUT ENISA

The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU bodies, and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the Agency works together with its key stakeholders to strengthen trust in the connected economy, to boost resilience of the Union’s infrastructure, and, ultimately, to keep Europe’s society and citizens digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu.

ENISA

European Union Agency for Cybersecurity

Athens Office

Agamemnonos 14 Chalandri 15231, Attiki, Greece

Brussels Office

Rue de la Loi 107 1049 Brussels, Belgium

enisa.europa.eu