Enisa Technical Advisory on Secure Use of Package Managers

ENISA Publishes Technical Advisory on Secure Use of Package ... You're Invited: Meet the Socket Team at RSAC and BSidesSF 2026, March 23–26 . RSVP → Back Security News ENISA Publishes Technical Advisory on Secure Use of Package Managers ENISA’s new package manager advisory outlines the dependency security practices companies will need to demonstrate as the EU’s Cyber Resilience Act begins enforcing software supply chain requirements. Sarah Gooding March 19, 2026 In less than six months, European software manufacturers will face the first hard deadline under the Cyber Resilience Act . Starting September 11, 2026, companies will be required to report actively exploited vulnerabilities and security incidents affecting their products. The broader obligations of the law do not fully apply until December 2027, but the reporting requirement marks the point where software supply chain visibility stops being a best practice and starts becoming a legal obligation. Against that backdrop, the European Union Agency for Cybersecurity (ENISA) has published a technical advisory on the secure use of package managers . The document itself covers familiar territory: malicious packages, compromised maintainers, typosquatting, dependency confusion, and the defensive practices developers use to manage third-party dependencies. Source: ENISA - Security Risks in Package Consumption Anyone who has followed open source security over the past decade will recognize the standard set of risk management controls outlined in ENISA's recommendations: tracking dependencies, generating SBOMs, monitoring for vulnerabilities, verifying package provenance, and documenting remediation steps. The new compliance expectations shift dependency security from periodic checks to continuous monitoring, requiring organizations to track changes across their dependency graph and identify new risks as they are introduced. ENISA Defines a Lifecycle for Package Manager Security # This advisory provides a structured version of those practices. ENISA organized the guidance around the lifecycle of dependency consumption: selecting packages, integrating them into projects, monitoring them over time, and responding to vulnerabilities when they appear. That lifecycle maps closely to the processes organizations will need in place once the Cyber Resilience Act’s reporting obligations take effect. When a vulnerability is disclosed in a widely used library, companies will be expected to determine whether their products include the affected component, assess whether the vulnerable code is reachable in their implementation, and document any remediation or mitigation steps. Processes such as SBOM generation, dependency monitoring, and reachability analysis make those determinations possible. Non-Compliance Can Lead to Fines and Product Removal # The Cyber Resilience Act entered into force in December 2024. Companies that fail to comply can face penalties of up to €15 million or 2.5 percent of global annual turnover . The Open Regulatory Compliance Working Group (ORCWG), an industry working group focused on CRA implementation, describes this shift as follows: Full supply chain compliance has never been required before the CRA. … The CRA impacts the entire supply chain, including open source dependencies, in every product. Compliance used to be internal policies and legal agreements with vendors. Now, the whole open source supply chain compliance will have to be brokered. The fines are severe . … products will be removed from retail shelves until compliance is met. Enforcement extends beyond fines. Regulators can require non-compliant products to be withdrawn or restricted from the EU market, turning compliance into a prerequisite for continued distribution rather than just a legal obligation. Penalties are paired with the ability to limit market access, reducing the likelihood that companies can treat fines as a cost of doing business. The CRA Has Triggered Pushback From the Open Source Ecosystem # The legislation has drawn mixed reactions across the software ecosystem. Many security experts support its goal of forcing vendors to take responsibility for insecure products, but parts of the open source community warned early drafts could have unintended consequences for volunteer-maintained software projects. Organizations including the Eclipse Foundation , the Open Source Initiative , and the Python Software Foundation argued the regulation risked treating open source contributors as commercial suppliers, potentially creating a chilling effect on open source development. Subsequent revisions narrowed the scope and clarified that non-commercial open source developers are generally exempt, though the law still places obligations on companies that ship products built on open source components. Guidance like ENISA’s advisory helps translate those legal obligations into operational practices companies can implement. For organizations preparing for CRA compliance, dependency governance programs, SBOM inventories, and continuous monitoring of third-party packages are likely to become part of the baseline security posture. Open Source Projects Are Being Pulled Into Downstream Compliance Efforts # The open source ecosystem has already started preparing for that shift. Industry groups such as the Open Source Security Foundation (OpenSSF) have published guidance and training materials to help developers and maintainers understand how the regulation affects projects that may end up inside commercial software products. Downstream compliance requirements are expected to increase pressure on upstream projects to improve vulnerability disclosure processes, documentation, and release practices. Many of these controls are already standard for development teams. For companies shipping software in Europe, the expectation that they are in place, and can be demonstrated, will soon carry regulatory weight. The package manager advisory is unlikely to be the last piece of guidance tied to the law. ENISA has been tasked with translating the Cyber Resilience Act’s high-level requirements into technical practices companies can implement. This advisory focuses on dependency consumption through package managers, with additional guidance on other areas of the software supply chain and vulnerability handling expected as the 2026 reporting deadline approaches. Subscribe to our newsletter Get notified when we publish new security blog posts! Enter your email Subscribe Try it now Ready to block malicious and vulnerable dependencies? Install GitHub App Book a Demo Questions? Call us at (844) SOCKET-0 Related posts Back to all posts Research / Security News Trivy Under Attack Again: Widespread GitHub Actions Tag Compromise Exposes CI/CD Secrets Attackers compromised Trivy GitHub Actions by force-updating tags to deliver malware, exposing CI/CD secrets across affected pipelines. By Philipp Burckhardt - Mar 20, 2026 Research / Security News GlassWorm Sleeper Extensions Activate on Open VSX, Shift to GitHub-Hosted VSIX Malware We identified over 20 additional malicious extensions, along with over 20 related sleeper extensions, some of which have already been weaponized. By Philipp Burckhardt , Peter van der Zee - Mar 18, 2026 Security News TC39 Advances Temporal to Stage 4 Alongside Several ECMAScript Proposals TC39’s March 2026 meeting advanced eight ECMAScript proposals, including Temporal reaching Stage 4 and securing its place in the ECMAScript 2026 specification. By Sarah Gooding - Mar 16, 2026