[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fQCVtXGeJmt4JuymrbAw54nvuLHghU1MDyyjMOj4R-l4":3},{"lesson":4},{"id":5,"slug":6,"article_id":7,"title":8,"body":9,"prevention":10,"framework_refs":11,"framework_notes":17,"status":23,"created_at":24,"published_at":25,"article":26,"tags":30,"podcasts":43,"controls":44},"d3f9e730-11b6-42c1-9a7e-069d5daa5115","open-source-package-registries-require-active-threat-filtering-not-just-policy-checks","8c2c4acc-9dfd-45f0-a23d-8adeb3422f56","Open-Source Package Registries Require Active Threat Filtering, Not Just Policy Checks","Organizations that rely on public package registries like npm expose themselves to supply chain attacks when malicious packages are published or when developers install unvetted dependencies without inspection. GitHub's new package firewall helps enforce enterprise policies, but policy-based checks alone are insufficient if they lack real-time threat intelligence and broad ecosystem coverage. StepSecurity's approach of combining SOC-backed threat intelligence, rapid blocking (within an hour), installation logging with source attribution, and coverage across eight ecosystems illustrates the depth of control required. Without proactive registry filtering and logging, a single malicious package pulled during a CI\u002FCD build or on a developer machine can compromise an entire software supply chain before the threat is even identified.","**Immediate actions:**\n- Enforce an approved, proxied package registry (private or curated) for all developer machines and CI\u002FCD runners so raw public registry traffic is never trusted directly.\n- Enable logging of all package installation events, including package name, version, source URL, and the identity of the requesting pipeline or user.\n\n**Long-term improvements:**\n- Subscribe to real-time threat intelligence feeds for the package ecosystems your organization uses and automate blocking of flagged packages within a defined SLA (e.g., under one hour).\n- Implement package version cooldown or quarantine periods before newly published packages are permitted in production builds.\n- Extend registry protection beyond npm to cover all ecosystems in use (PyPI, Maven, NuGet, RubyGems, etc.) to avoid blind spots.\n\n**Detection measures:**\n- Alert on any package installation that bypasses the approved registry or references an unexpected source URL.\n- Periodically audit CI\u002FCD pipeline dependency manifests against a known-good inventory to detect unauthorized or unexpected additions.",[12,13,14,15,16],"MITRE ATT&CK T1195.001: Supply Chain Compromise: Compromise Software Dependencies and Development Tools","CIS Control 16: Application Software Security (v8)","NIST SP 800-53 SR-4: Provenance","NIS2 Article 21(2)(d)","NIST CSF 2.0 DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events",{"NIS2 Article 21(2)(d)":18,"NIST SP 800-53 SR-4: Provenance":19,"CIS Control 16: Application Software Security (v8)":20,"MITRE ATT&CK T1195.001: Supply Chain Compromise: Compromise Software Dependencies and Development Tools":21,"NIST CSF 2.0 DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events":22},"NIS2's supply chain security point requires entities to address security risks arising from relationships with suppliers and service providers, including third-party software components pulled from public registries.","SR-4 requires organizations to document and verify the provenance of components in their supply chain, which registry logging with source attribution directly supports.","CIS Control 16 requires organizations to manage the security of software they use, including vetting third-party components and libraries before they are introduced into the environment.","This technique describes adversaries inserting malicious code into open-source packages, exactly the threat that registry firewalling and threat-intelligence blocking are designed to detect and prevent.","Logging every package installation with source attribution and triggering alerts on anomalous registry access is precisely the continuous monitoring this category mandates.","published","2026-11-11T04:20:24.910823+00:00","2026-11-11T04:20:24.893+00:00",{"id":7,"url":27,"slug":28,"title":29},"https:\u002F\u002Fwww.stepsecurity.io\u002Fblog\u002Fgithub-package-firewall-vs-stepsecurity-secure-registry-protection-beyond-npm","github-package-firewall-vs-stepsecurity-secure-registry-protection-beyond-npm-26f75d","GitHub Package Firewall vs. StepSecurity Secure Registry: Protection beyond npm",[31,37],{"id":32,"name":33,"slug":34,"description":35,"color":36},"05757c8d-6b93-4194-b35d-7359e7d33b0e","Vulnerability Management","vulnerability-management","Missing scans, no risk prioritization","#fb923c",{"id":38,"name":39,"slug":40,"description":41,"color":42},"f0c2a0af-58aa-4128-87c9-6acd30f2dc48","Supply Chain","supply-chain","Third-party risk, compromised dependencies","#8b5cf6",[],[45],{"slug":46,"name":47,"problem":48},"software-supply-chain","Software supply chain security","Malicious and vulnerable open-source packages are caught before they ship."]