text: ( ) NPM, https://www.npmjs.com/, accessed 28 November 2025. 2 ( ) PyPI, https://pypi.org/project/pip/, accessed 28 November 2025. 3 ( ) Maven, https://maven.apache.org/repositories/index.html, accessed 28 November 2025. 4 ( ) Palo Alto Networks, ‘Breakdown: Widespread npm supply chain attack puts billions of weekly downloads at risk’, 10 September 2025, https://www.paloaltonetworks.com/blog/cloud-security/npm-supply-chain-attack/, accessed 28 November 2025. ( ) Aikido, ‘XRP supply chain attack: Official NPM package infected with crypto stealing backdoor’, 22 April 2025, https://www.aikido.dev/blog/xrp-supplychain-attack-official-npm-package-infected-with-crypto-stealing-backdoor, accessed 28 November 2025. 6 ( ) Wiz, ‘Shai-Hulud 2.0 supply chain attack: 25K+ repos exposing secrets’, 24 November 2025, https://www.wiz.io/blog/shaihulud-2-0-ongoing-supply-chain-attack, accessed 28 November 2025. 7 ( ) European Union Agency for Cybersecurity, ENISA threat landscape for supply chain attacks, 2021, https://data.europa.eu/doi/10.2824/168593, accessed 28 November 2025. 8 ( ) ENISA, ‘Call for feedback: Advancing software supply chain security together!’, press release, 17 December 2025, https://www.enisa.europa.eu/news/call-for-feedback-advancing-software-supply-chain-security-together, accessed 11 February 2026.

text: Table 1: List of common package managers

text: npm Node.js/JavaScript https://docs.npmjs.com yarn Node.js/JavaScript https://yarnpkg.com Pip/PyPI Python https://pip.pypa.io/en/stable/ Conda Python/R https://docs.conda.io Maven Java https://maven.apache.org/ Gradle Java https://docs.gradle.org SPM Swift https://docs.swift.org/package-manager/ CocoaPods Swift/Obj-C https://guides.cocoapods.org NuGet .NET https://learn.microsoft.com/nuget RubyGems Ruby https://guides.rubygems.org Composer PHP https://getcomposer.org CPAN Perl https://www.cpan.org CRAN R https://cran.r-project.org Cargo Rust https://doc.rust-lang.org/cargo

text: Figure 1: Package publishing and consumption

text: Action Example

text: Developer writes a simple Node.js

text: app.

text: Developer adds the express package to the Node.js project using npm install express.

text: (npm downloads the package from the registry).

text: The package express itself depends on other packages (e.g. router, qs, depd).

text: NB: the command npm view <package> dependencies shows the direct dependencies.

text: A lockfile (package-lock.json) records the exact versions of all installed dependencies, including transitive dependencies (packages that your project relies on indirectly).

text: Figure 2: Package dependencies

text: Figure 3: Reachability in packages

text: ( ) Basic routing endpoints: these are the fundamental paths and handlers (functions) that allow a web application to respond to specific web requests, such as a GET request to retrieve data from the /users path or a POST request to submit a form. They represent the core, essential functionality of a web framework.

text: Figure 4: Categories of security risks

text: 16 The recent TARmageddon incident ( ), which stemmed from the abandoned Rust tokio-tar library ( ), illustrates how unmaintained packages can resurface as attack vectors even several years later. Similarly, the previously mentioned node-serialize package remains available on the npm registry in its vulnerable version (0.0.4 – released 11 years ago) and continues to receive weekly downloads. Even widely used projects are not immune to this. For example, the popular crypto-js library ( ), although not currently affected by known vulnerabilities, is listed as discontinued on its repository page, yet it continues to record millions of downloads each week.

text: ( ) NIST, National Vulnerability Database, CVE-2021-22931 Detail, https://nvd.nist.gov/vuln/detail/cve-2021-22931, accessed 28 November 2025. 11 ( ) NIST, National Vulnerability Database, CVE-2025-27210 Detail, https://nvd.nist.gov/vuln/detail/CVE-2025-27210, accessed 28 November 2025. ( ) NIST, National Vulnerability Database, CVE-2023-45143 Detail, https://nvd.nist.gov/vuln/detail/cve-2023-45143, accessed 28 November 2025. 13 ( ) NPM, ‘node-serialize’, n.d., https://www.npmjs.com/package/node-serialize, accessed 28 November 2025. 14 ( ) ENISA, EU Vulnerability Database, EUVD-2018-0297, 8 May 2024, https://euvd.enisa.europa.eu/vulnerability/CVE-2017- 5954, accessed 28 November 2025. 15 ( ) Edera, ‘TARmageddon (CVE-2025-62518): RCE Vulnerability Highlights the Challenges of Open Source Abandonware’, 21 October 2025, https://edera.dev/stories/tarmageddon, accessed 28 November 2025. 16 ( ) ENISA, EU Vulnerability Database, EUVD-2025-35176, 16 January 2026, https://euvd.enisa.europa.eu/vulnerability/CVE- 2025-62518, accessed 28 November 2025. 17 ( ) NPM, ‘crypto-js’, n.d., https://www.npmjs.com/package/crypto-js, accessed 28 November 2025.

text: ( ) Beamon, B. M. (1998), ‘Supply chain design and analysis: Models and methods’, International Journal of Production Economics, Vol. 55, Issue 3, pp. 281–294, https://doi.org/10.1016/S0925-5273(98)00079-6. 19 ( ) ENISA, ENISA threat landscape for supply chain attacks, 2021, https://data.europa.eu/doi/10.2824/168593, accessed 11 February 2025. 20 ( ) Sonatype, ‘Open Source Malware Index Q2 2025: Data Exfiltration Remains a Leading Threat’, 8 July 2025, https://www.sonatype.com/blog/open-source-malware-index-q2-2025, accessed 28 November 2025. 21 ( ) Hack Read, ‘npm Malware Targets Crypto Wallets, MongoDB; Code Points to Turkey’, 1 May 2025, https://hackread.com/npm-malware-crypto-wallets-mongodb-turkey-code/, accessed 28 November 2025.

text: ( ) The Hacker News, ‘GlassWorm Malware Discovered in Three VS Code Extensions with Thousands of Installs’, 10 November 2025, https://thehackernews.com/2025/11/glassworm-malware-discovered-in-three.html, accessed 28 November 2025. 23 ( ) NPM, ‘Details about the event-stream incident’, 27 November 2018, https://blog.npmjs.org/post/180565383195/detailsabout-the-event-stream-incident, accessed 28 November 2025. 24 ( ) Palo Alto Networks, ‘Breakdown: Widespread npm Supply Chain Attack Puts Billions of Weekly Downloads at Risk’, 10 September 2025, https://www.paloaltonetworks.com/blog/cloud-security/npm-supply-chain-attack/, accessed 28 November 2025. 25 ( ) Sonatype, ‘Popular npm Project Used by Millions Hijacked in Supply-Chain Attack’, 25 October 2021, https://www.sonatype.com/blog/npm-project-used-by-millions-hijacked-in-supply-chain-attack, accessed 28 November 2025. 26 ( ) Snyk, ‘Open source maintainer pulls the plug on npm packages colors and faker, now what?’, 9 January 2022, https://snyk.io/fr/blog/open-source-npm-packages-colors-faker/, accessed 11 February 2026. 27 ( ) NPM, ‘crossenv’, n.d., https://www.npmjs.com/package/crossenv, accessed 28 November 2025.

text: 31 Namespace ( ) or dependency ( ) confusion is another package distribution attack that exploits differences between internal and public repositories. In environments where both internal and public registries are configured, package managers may automatically resolve dependencies from either source based on the name and version. Attackers publish packages with the same names as private packages with a much higher version number, thus tricking package managers into fetching the malicious public version instead of the private package. The attack succeeds as a result of permissive version ranges and lack of internal repository enforcement. This attack vector was demonstrated in practice in 2021, showing how dependency confusion attacks can lead to unintended installation of externally published packages ( ).

text: Figure 5: Propagation of vulnerabilities

text: ( ) NPM, ‘cross-env’, n.d., https://www.npmjs.com/package/cross-env, accessed 28 November 2025. 29 ( ) NPM, “‘crossenv’ malware on the npm registry”, 2 August 2017, https://blog.npmjs.org/post/163723642530/crossenvmalware-on-the-npm-registry, accessed 28 November 2025. 30 ( ) Sonatype, ‘Namespace Confusion Protection’, 29 January 2025, https://help.sonatype.com/en/namespace-confusionprotection.html, accessed 28 November 2025. 31 ( ) Blaze, ‘Dependency Confusion: An exploitation overview’, 26 February 2023, https://www.blazeinfosec.com/post/dependency-confusion-exploitation/, accessed 28 November 2025. 32 ( ) Medium, ‘Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies’, 9 February 2021, https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610, accessed 1 February 2026.

text: ( ) Palo Alto Networks, ‘Breakdown: Widespread npm Supply Chain Attack Puts Billions of Weekly Downloads at Risk’, 10 September 2025, https://www.paloaltonetworks.com/blog/cloud-security/npm-supply-chain-attack/, accessed 28 November 2025. ( ) React, ‘Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies, 3 December 2025, https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components, accessed 11 December 2025. ( ) HackerOne, ‘CVE-2025-55182: Unauthenticated React Exploit Affects Millions of Sites’, 5 December 2025, https://www.hackerone.com/blog/cve-2025-55182-react-exploit, accessed 11 December 2025.

text: Stage Threats Security objectives

text: Selecting packages with inherent vulnerabilities (3.1) Select Choosing trustworthy, verified, and well-maintained packages Selecting malicious packages distributed through supply chain attacks (3.2) Integrating packages with inherent vulnerabilities (3.1) Integrate Ensuring secure integration of selected packages Integrating malicious packages distributed through supply chain attacks (3.2) Integrated packages contain newly detected vulnerabilities (3.1) Monitor Detecting vulnerabilities or compromised packages Integrated legitimate packages are compromised (3.2) Integrated packages contain newly detected vulnerabilities (3.1) Applying patches, or isolating, or removing affected packages in a timely

text: manner to maintain a secure state Integrated legitimate packages are compromised (3.2)

text: Selection Related Description recommendation threats

text: Use only official and verifiable package registries, and prefer packages published Trusted source through secure workflows such as Trusted Publishing, which provide provenance 3.2 metadata to verify the publisher’s identity.

text: Existing known Check vulnerability databases and scanning tools, such as npm audit, Snyk and OSV, 3.1 vulnerabilities for existing issues before use.

text: Package signing and

text: Use packages and repositories that provide cryptographic signing to verify integrity. 3.2.2, 3.2.4

text: integrity verification

text: Select packages maintained by reputable or verified organisations/publishers with a 3.1, 3.2.1,

text: Maintainer reputation

text: consistent record. 3.2.3

text: Consider community adoption and recent update activity as indicators of reliability and Popularity and ongoing support. Examples include project stars, downloads and commits. 3.1, 3.2.1, maintenance 36 3.2.3 NB: Popularity metrics can be misleading or artificially inflated ( ) and should not be relied upon in isolation.

text: Usage of secure Evaluate package build practices to ensure they avoid unnecessary or insecure 3.1, 3.2 practices installation behaviours.

text: ( ) He, H., Yang, H., Burckhardt, P., Kapravelos, A., Vasilescu, B. and Kästner, C. (2026), ‘Six Million (Suspected) Fake Stars on GitHub: A Growing Spiral of Popularity Contests, Spam, and Malware’, Proceedings of the 48th International Conference on Software Engineering (ICSE 2026), Rio de Janeiro, Brazil, 12–18 April 2026.

text: Selection Examples recommendation

text: Several package managers allow developers to publish using provenance statements ( ) to prove that a package was built by a trusted publisher ( ). • Verify the package’s provenance to confirm where and how it was published, and that it was released by a trusted and authorised publisher ( ):

text: Trusted source

text: o look for a green check mark on the dedicated npm package web page; o npm audit signatures. • Prefer packages that include valid provenance metadata. • Verify package names carefully to avoid malicious imitations or naming collisions.

text: • Run scans prior to installation or during dependency review: o npm audit --json; o osv-scanner -r.; Existing known 40 o dependency-check --project “My Project” --scan./ ( ). vulnerabilities 41 42 43 44 • Consult public databases such as EUVD ( ), OSV.dev ( ), Snyk ( ) or NVD ( ) to check the package’s vulnerability history. • Avoid or postpone adoption of packages with unresolved high/critical severity issues.

text: • Check that the ecosystem supports integrity metadata, such as SHA-512 hashes in npm (packagelock.json) or enforceable hashes in pip (pip install --require-hashes). • Prefer package managers and packages that support provenance verification. • Avoid packages that bypass registry verification, such as direct installs from GitHub or tarball URLs, which lack provenance and integrity checks. Package signing and • Verify that packages include provenance metadata: integrity verification o npm audit signatures reports ‘missing provenance’. • Avoid packages that use pre-install or post-install scripts to download additional code or binaries from external URLs: o npm view <package> scripts; o grep -R ‘curl\|wget\|git clone” node_modules/*/package.json. • grep -R ‘curl\|wget\|git clone” node_modules/.

text: • Review maintainer metadata, for example: o npm view <package> contributors; o npm view <package> maintainers; o check npm and/or code repository (e.g. github/gitlab) webpage info; o npm info express -json (maintainers, author, contributors, publisher – most recent publisher). Maintainer reputation • Be cautious of packages owned by newly created, single project accounts with no additional contributors: o https://registry.npmjs.org/-/v1/search?text=maintainer:<enter maintainer ID here>. • Prefer packages from verified publishers (Github/npm) and those that include valid provenance metadata. • Where feasible, consider maintaining an internal ‘allowlist’ of approved packages or maintainers, potentially informed by trusted industry stakeholders or open-source foundations.

text: ( ) NPM, ‘Generating provenance statements’, 4 August 2025, https://docs.npmjs.com/generating-provenance-statements, accessed 28 November 2025. ( ) NPM, ‘Trusted publishing for npm packages’, 10 February 2026, https://docs.npmjs.com/trusted-publishers, accessed 28 November 2025. ( ) NPM, ‘Viewing package provenance’, 7 July 2025, https://docs.npmjs.com/viewing-package-provenance, accessed 28 November 2025. ( ) OWASP Dependency-check supports Node.js but is primarily designed for Maven/Java projects. ( ) ENISA, ‘EU Vulnerability Database’, https://euvd.enisa.europa.eu/, accessed 28 November 2025. ( ) OSV, ‘Vulnerabilities’, https://osv.dev/list?ecosystem=npm, accessed 28 November 2025. ( ) Snyk, ‘Vulnerabilities’, https://security.snyk.io/vuln/npm, accessed 28 November 2025. ( ) NIST, ‘National Vulnerability Database’, https://nvd.nist.gov/, accessed 28 November 2025.

text: • Check for recent community engagement: o check github insights tab (contributors, commits, etc.); o check CHANGELOG.md and SECURITY.md on repository webpage; o check open or recently closed issues and pull requests on repository webpage; o curl -s ‘https://api.github.com/repos/<owner>/<repo>/issues?state=all&per_page=100”

text: Popularity and

text: | jq ‘.[] |.state,.created_at,.closed_at’.

text: • Prefer active projects with frequent commits and tagged releases, for example: o git shortlog -sne; o npm info <package> -json (time, versions). • Review documentation and security contact details to confirm openness and accountability. • Prefer dependencies maintained by verified and known active organisations or foundations.

text: • Inspect the package’s life cycle scripts for potentially unsafe commands such as pre-install or postinstall: Usage of secure o npm view <package> scripts. practices • Review dependency trees to confirm the package introduces only necessary dependencies and no excessive or nested components: o npm ls --all.

text: Integration Related Description recommendation threats

text: Generate a software bill of materials (SBOM) to document all dependencies SBOM creation 3.1 for future security and compliance tracking.

text: Enforce security policies in CI/CD pipelines to prevent builds from proceeding Vulnerability checks 3.1 with known vulnerable components.

text: Enforce hash or lockfile verification to confirm that installed packages match Integrity enforcement 3.2.2, 3.2.4 approved versions.

text: Package source 3.2.1, 3.2.3, Restrict installations to trusted package registries and validate source URLs. enforcement/verification 3.2.4

text: Inspect and disable or restrict scripts executed during installation to reduce Installation script attack surface. 3.1, 3.2 prevention NB: Disabling scripts may impact packages and functionality. This control may be more suited for high-security or isolated environments.

text: Fix dependency versions to prevent unverified updates from introducing new 3.1, 3.2.2,

text: Pinning versions

text: vulnerabilities. 3.2.4

text: Integration Examples recommendation

text: Generate an SBOM during build: SBOM creation 45 • syft. -o spdx-json > sbom.json ( ); • @cyclonedx/cyclonedx-npm --output-file sbom.json ( ).

text: Block build/install when vulnerabilities are found: Vulnerability checks 47 • npm audit --omit=dev --audit-level=high ( ); • grype sbom:./sbom.json --fail-on High ( ).

text: npm automatically enforces integrity by verifying SHA-512 hashes stored in packagelockfile.json. Other ecosystems may explicitly require enforcement, for example with pip:

text: Integrity enforcement

text: • pip install --require-hashes -r requirements.txt ( ).

text: Use a local package registry or proxy (e.g. Verdaccio, Nexus Repository, JFrog Artifactory, AWS CodeArtifact, GitHub Packages or Google Artifact Registry) to ensure packages are sourced only from approved and verified repositories.

text: Configure.npmrc file to restrict installations to the trusted registry:

text: Package source

text: enforcement/verification echo ‘registry=https://<registry>“ >>.npmrc. •

text: NB: A local package registry or proxy with caching capabilities can also support business continuity by retaining previously retrieved packages, even if they are removed from the upstream registry or if the registry itself is temporarily unavailable.

text: Disable the execution of installation scripts from third-party packages: • run installs with scripts disabled: o npm install --ignore-scripts <package> ( ). Installation script • set this as a project or global policy: prevention o echo ‘ignore-scripts=true’ >> .npmrc; o npm config set ignore-scripts true -g.

text: NB: Disabling scripts may impact packages and functionality. This control may be more suited for high-security or isolated environments.

text: • Use a lockfile (package-lock.json ( ), yarn.lock, etc.) to maintain exact dependency versions. Pinning versions • Commit both package.json and the lockfile to source control. • Enforce lockfile usage in CI/CD ( ): o npm ci. • Review changelogs and release notes before upgrading dependencies.

text: ( ) Github, ‘anchore/syft’, https://github.com/anchore/syft, accessed 28 November 2025. ( ) Github, ‘CycloneDX/cyclonedx-node-npm’, https://github.com/CycloneDX/cyclonedx-node-npm, accessed 28 November 2025. ( ) NPM, ‘npm-audit’, 26 October 2022, https://docs.npmjs.com/cli/v8/commands/npm-audit, accessed 28 November 2025. ( ) Github, ‘anchore/grype’, n.d., https://github.com/anchore/grype, accessed 28 November 2025. ( ) PyPA, ‘Secure installs’, n.d., https://pip.pypa.io/en/stable/topics/secure-installs/, accessed 28 November 2025. ( ) OWASP Cheat Sheet Series, ‘NPM Security best practices’, n.d., https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html, accessed 28 November 2025.

text: ( ) NPM, ‘package.json’, 26 October 2022, https://docs.npmjs.com/cli/v8/configuring-npm/package-json, accessed 28 November 2025. ( ) OWASP Cheat Sheet Series, ‘NPM Security best practices’, n.d., https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html, accessed 28 November 2025.

text: • Optional and situational: install packages at a specific date to avoid newly published versions: o npm install express --before="$(date -d ‘-7 days’)’.

text: NB: Pinning versions can prolong exposure to known vulnerabilities if updates are not regularly reviewed and applied.

text: Package monitoring Related Description recommendation threats

text: SBOM-driven Leverage SBOM data to automate vulnerability correlation and streamline 3.1, 3.2.1, monitoring monitoring workflows. 3.2.2

text: Automate vulnerability 3.1, 3.2.1, Continuously scan dependencies to identify new or resurfacing vulnerabilities. scanning in CI/CD 3.2.2

text: Monitor vulnerability databases regularly to stay informed about newly reported 3.1, 3.2.1,

text: Track CVEs/advisories

text: issues. 3.2.2

text: Monitor for outdated 3.1, 3.2.1, Monitor existing packages for the availability of newer versions. version release 3.2.2

text: Set alerts on specific events deemed risky for your organisation, for example: • on new CVEs affecting locked versions; • on deprecated or unmaintained releases; 3.1, 3.2.1,

text: Set alerts

text: • on lack of maintainer activity. 3.2.2 • on maintainer ownership change;

text: Package monitoring Examples recommendation

text: Use SBOM data for periodic/continuous vulnerability checks: SBOM-driven monitoring 53 • grype sbom:./sbom.json ( ); • osv-scanner scan --sbom.json ( ).

text: ( ) Github, ‘anchore/grype’, n.d., https://github.com/anchore/grype, accessed 28 November 2025. ( ) Github, ‘google/osv-scanner’, n.d., https://github.com/google/osv-scanner, accessed 28 November 2025.

text: Integrate dependency scanning commands into pipeline stages: Automate vulnerability • npm audit --omit=dev --audit-level=high; scanning in CI/CD • osv-scanner -r.

text: Schedule periodic scans and fail builds if new high-severity vulnerabilities are detected.

text: Subscribe to and monitor public vulnerability feeds: 55 56 57 58 • EUVD ( ), OSV.dev ( ), Snyk ( ) or NVD ( ); 59 60 • use GitHub Dependabot ( ) or npm audit ( ) to monitor and notify of new Track CVEs/advisories issues affecting dependencies; • vendor-published machine-readable advisories, such as the Common Security Advisory Framework (CSAF) ( ), could support automated ingestion and processing.

text: Monitor offset between installed and available versions:

text: Monitor outdated version release

text: • npm outdated.

text: Define items to monitor for alerts, for example: • new CVEs affecting locked versions: o GitHub Dependabot alerts ( ); o grype sbom:./sbom.json; o osv-scanner scan --sbom.json. • deprecated or unmaintained releases: o npm view <package> deprecated; o npm info <package> time.modified;

text: Set alerts

text: • lack of maintainer activity o certain commands mentioned in section 4.1.2 can be performed over time to monitor the maintainer activity (or lack thereof) on a specific package • maintainer or ownership changes: o npm view <package> maintainers --json. Configure alerts using internal notification process (e.g. email, Slack or Teams) and integrate alerting into CI/CD.

text: ( ) ENISA, ‘EU Vulnerability Database’, https://euvd.enisa.europa.eu/, accessed 28 November 2025. ( ) OSV, ‘Vulnerabilities’, https://osv.dev/list?ecosystem=npm, accessed 28 November 2025. ( ) Snyk, ‘Vulnerabilities’, https://security.snyk.io/vuln/npm, accessed 28 November 2025. ( ) NIST, ‘National Vulnerability Database’, https://nvd.nist.gov/, accessed 28 November 2025. ( ) Github, ‘About Dependabot alerts’, n.d., https://docs.github.com/en/code-security/dependabot/dependabot-alerts/aboutdependabot-alerts, accessed 28 November 2025. ( ) NPM, ‘npm-audit’, 23 October 2023, https://docs.npmjs.com/cli/v9/commands/npm-audit, accessed 28 November 2025. ( ) CSAF, ‘Common Security Advisory Framework (CSAF)’, n.d., https://www.csaf.io/, accessed 1 February 2026. ( ) Github, ‘About Dependabot alerts’, n.d., https://docs.github.com/en/code-security/dependabot/dependabot-alerts/aboutdependabot-alerts, accessed 28 November 2025.

text: Vulnerability mitigation Related Description recommendation threats

text: Assess reported vulnerabilities, retrieving data and metrics relating to their Assess 3.1, 3.2.1, 3.2.2 exploitability, relevance and reachability within the current system context.

text: Define risk appetite and prioritise vulnerabilities based on severity, Prioritise 3.1, 3.2.1, 3.2.2 exploitability and potential impact.

text: Apply the appropriate remediation action such as upgrading, Mitigate 3.1, 3.2.1, 3.2.2 mitigating/isolating or rolling back.

text: Record actions taken, update the SBOM and communicate changes as Document and notify 3.1, 3.2.1, 3.2.2 part of regulatory or organisational compliance obligations.

text: Vulnerability mitigation Examples recommendation

text: For identified vulnerabilities: • Retrieve and record vulnerability metrics (CVSS, EPSS, KEV, VEX): o CVSS: Severity score and vector (e.g., OSV.dev, NVD, Snyk or EUVD); o 63 EPSS ( ): Probability of exploitation score; o KEV ( ): Check if CVE is listed in CISA’s Known Exploited Vulnerabilities catalogue; Assess 65 o VEX ( ) data: Vulnerability Exploitability eXchange format used by software suppliers to describe whether vulnerabilities affect a product. • Retrieve and assess vendor-provided advisory information. Machine-readable formats (e.g. CSAF) could help to automate vulnerability information processing. 66 67 • Perform reachability/context analysis (e.g. CodeQL ( ), Semgrep ( ), call graph/static analysis tools or other commercial tools like snyk ( ) code) to confirm if vulnerable code is actually used.

text: • Define risk thresholds (e.g. ‘treat CVSS ≥ 7.0 or EPSS ≥ 0.3 as high priority”). • Focus remediation on exploitable and reachable vulnerabilities with high severity or

text: exploitation scores above risk threshold. • Prioritise vulnerabilities affecting dependencies in production environments.

text: ( ) FIRST, ‘EPSS Data’, n.d., https://www.first.org/epss/data_stats, accessed 28 November 2025. ( ) CISA, ‘Known Exploited Vulnerabilities Catalog’, https://www.cisa.gov/known-exploited-vulnerabilities-catalog, accessed 28 November 2025. ( ) CycloneDX, ‘Vulnerability Exploitability eXchange (VEX)’, n.d., https://cyclonedx.org/capabilities/vex, accessed 28 November 2025. ( ) Github, ‘CodeQL’, n.d., https://codeql.github.com/, accessed 28 November 2025. ( ) Github, ‘semgrep’, n.d., https://github.com/semgrep/semgrep, accessed 28 November 2025. ( ) Snyk, ‘Reachability analysis’, n.d., https://docs.snyk.io/manage-risk/prioritize-issues-for-fixing/reachability-analysis, accessed 28 November 2025.

text: • Patch or upgrade: o npm update <package>; o npm install <package>@<version>.

text: • Use temporary mitigating controls (e.g. WAF rules, feature flags) to limit exposure until a fix is applied. • Remove, roll back or isolate if no patch is available.

text: • Categorise vulnerabilities as exploitable, non-exploitable or mitigated by configuration: o VEX Product Statuses: known_affected, known_not_affected, under_investigation, and fixed. • Generate/update a VEX mitigation statement. Document and • Update SBOM: notify o syft. -o spdx-json > sbom.json; o @cyclonedx/cyclonedx-npm --output-file sbom.json. • Update release notes. • Notify relevant internal/external stakeholders (e.g. impacted customers, relevant authorities, DevSecOps, risk management, compliance teams).

text: ( ) OpenSSF, ‘npm Best Practices for the Supply-Chain’, 1 September 2022, https://openssf.org/blog/2022/09/01/npm-bestpractices-for-the-supply-chain/, accessed 1 February 2026. 70 ( ) OWASP Cheat Sheet Series, ‘NPM Security best practices’, n.d., https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html, accessed 1 February 2026. 71 ( ) OpenSSF, ‘Concise Guide for Evaluating Open Source Software’, 28 March 2025, https://best.openssf.org/Concise-Guidefor-Evaluating-Open-Source-Software.html, accessed 1 February 2026. 72 ( ) CISA, ‘Software Acquisition Guide for Government Enterprise Consumers: Software Assurance in the Cyber-Supply Chain Risk Management (C-SCRM) Lifecycle’, 1 August 2024, https://www.cisa.gov/resources-tools/resources/softwareacquisition-guide-government-enterprise-consumers-software-assurance-cyber-supply-chain, accessed 1 February 2026. 73 ( ) Anchore, ‘Generating SBOMs for JavaScript Projects: A Developer’s Guide’, 28 March 2025, https://anchore.com/blog/javascript-sbom-generation/, accessed 28 November 2025.

text: ( ) CSAF, ‘Common Security Advisory Framework (CSAF)’, n.d., https://www.csaf.io/, accessed 1 February 2026. 75 ( ) Mend.io, ‘The Hallucinated Package Attack: Slopsquatting’, 15 August 2025, https://www.mend.io/blog/the-hallucinatedpackage-attack-slopsquatting/, accessed 1 February 2026.

identifier: ENISA Technical Advisory for Secure Use of Package Managers

amnesord:
Certification and Standards
Product Security

title: ENISA Technical Advisory for Secure Use of Package Managers

text: TLP - CLEAR

text: ENISA Technical Advisory for Secure Use of Package Managers

text: MARCH 2026

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

text: About ENISA

text: 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.

text: CONTACT

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

text: AUTHORS

text: ENISA

text: LEGAL NOTICE

text: 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

text: Regulation (EU) 2019/881

text: . 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.

text: COPYRIGHT NOTICE

text: © European Union Agency for Cybersecurity (ENISA), 2026

text: 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.

text: 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

text: Table of Contents

text: 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

text: 2.1.1 Core elements 5

text: 2.1.2 Example flow 6

text: 2.1.3 Package import and usage 7

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

text: 3.1.1 Poor coding or design practices and misconfigurations 11

text: 3.1.2 Discontinued or unmaintained packages 11

text: 3.2 Supply chain attacks 12

text: 3.2.1 Insertion of malicious packages/dependencies 12

text: 3.2.2 Compromised legitimate packages 13

text: 3.2.3 Typosquatting 13

text: 3.2.4 Namespace/Dependency Confusion 14

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

text: 4.1.1 Selection recommendations 17

text: 4.1.2 Cheat Sheet 17

text: 4.2 Package integration 19

text: 4.2.1 Integration recommendations 19

text: 4.2.2 Cheat sheet 20

text: 4.3 Package monitoring 21

text: 4.3.1 Package monitoring recommendations 21

text: 4.3.2 Cheat sheet 21

text: 4.4 Vulnerability mitigation 22

text: 4.4.1 Vulnerability mitigation steps 23

text: 4.4.2 Cheat sheet 23

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

text: 1. Scope and context

text: 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:

text: • 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.

text: 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.

text: 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.

text: 1.1 Note on the current version of the document

text: 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.

text: 2. Solution architecture and data flows

text: 2.1 How package managers work

text: 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.

text: 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.

text: Package manager Ecosystem Official link

text: 2.1.1 Core elements

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

text: • 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

text: 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.

text: 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.

text: 2.1.2 Example flow

text: 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.

text: 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.

text: 2.1.3 Package import and usage

text: 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.

text: 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.

text: 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.

text: 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.

text: 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.

text: 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

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

text: 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.

text: 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.

text: 2.2 Package manager benefits

text: Packages and package managers bring significant benefits to software development.

text: • 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.

text: 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.

text: 3. Security risks in package consumption

text: 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.

text: 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:

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

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

text: 3.1 Packages with inherent vulnerabilities

text: 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.

text: 3.1.1 Poor coding or design practices and misconfigurations

text: 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.

text: 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).

text: 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.

text: 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.

text: 3.1.2 Discontinued or unmaintained packages

text: 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.

text: 3.2 Supply chain attacks

text: 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:

text: • 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

text: 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.

text: 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.

text: 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.

text: 3.2.1 Insertion of malicious packages/dependencies

text: 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.

text: 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.

text: 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

text: 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.

text: 3.2.2 Compromised legitimate packages

text: 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.

text: 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.

text: 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.

text: 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 ( ).

text: 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.

text: 3.2.3 Typosquatting

text: 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.

text: 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

text: 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 ( ).

text: 3.2.4 Namespace/Dependency Confusion

text: 3.3 Consequences

text: 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.

text: 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

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

text: 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.

text: 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

text: 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.

text: 4. Best practices – secure package consumption

text: 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.

text: 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.

text: 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.

text: 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.

text: 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

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

text: 4.1 Package selection

text: 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.

text: 4.1.1 Selection recommendations

text: 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

text: 4.1.2 Cheat Sheet

text: 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.

text: 4.2 Package integration

text: 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.

text: 4.2.1 Integration recommendations

text: 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.

text: 4.2.2 Cheat sheet

text: 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.

text: 4.3 Package monitoring

text: 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.

text: 4.3.1 Package monitoring recommendations

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

text: 4.3.2 Cheat sheet

text: 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.

text: 4.4 Vulnerability mitigation

text: 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.

text: 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.

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

text: 4.4.1 Vulnerability mitigation steps

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

text: 4.4.2 Cheat sheet

text: 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.

text: 5. Future considerations

text: 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.

text: 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 ( ).

text: 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.

text: 5.1 Automation

text: 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.

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

text: • 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.

text: 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

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

text: 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.

text: 5.2 AI-assisted development and “vibe-coding”

text: 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.

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

text: • 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.

text: TP -01 -26 -005 -EN -N

text: ABOUT ENISA

text: ENISA

text: European Union Agency for Cybersecurity

text: Athens Office

text: Agamemnonos 14 Chalandri 15231, Attiki, Greece

text: Brussels Office

text: Rue de la Loi 107 1049 Brussels, Belgium

text: enisa.europa.eu