--- title: "Package Rules | Workshop" description: "Automatically allow or block software from popular package managers as it" doc_version: "1" last_updated: "2026-05-22" canonical: "https://northpole.security/features/package-rules" --- ![](https://northpole.security/images/workshop/figma/hero-bg.png) # Livable allowlisting for developers Workshop's Package Rules let you automatically allow or block software from popular package managers as it's released. Keep your developers happy by automatically approving software from Homebrew, npm, GitHub, and more. [Book a demo](https://northpole.typeform.com/to/SG9jCi0v) [View documentation](https://northpole.security/docs/workshop) ![Package Rules in Workshop](https://northpole.security/_astro/hero.Cf4rSFX0_mpYe3.png) ![](https://northpole.security/images/workshop/figma/snow-corner-tr.png) ![](https://northpole.security/images/workshop/figma/snow-floor.png) The problem ## The allowlist maintenance problem Hash-based allowlisting falls apart the moment a package updates. Multiply by every ecosystem and every developer and the work never stops. ### Developer needs Teams rely on a steady stream of tools from public ecosystems, and those ecosystems update constantly. - Homebrew: wget, jq, git, and hundreds more, sometimes shipping multiple times per day - npm: typescript, eslint, and the rest of the JavaScript and TypeScript stack - Cargo: ripgrep, bat, and other Rust packages from crates.io - VS Code extensions used across Cursor and other VS Code forks ### Security challenge Every release ships a new binary, which means a new hash. Allowlisting on hashes alone turns routine updates into security work. - Hashes change with every release - Manual review of every version - Bottleneck for routine updates The old way ## Without Package Rules Hours to days of delay, multiplied across your fleet. 1 Developer updates An engineer runs brew upgrade or npm install and pulls in the latest version of a tool. 2 Santa blocks Santa sees a new, unknown hash and blocks execution. The developer is dead in the water. 3 Ticket filed The developer files an approval ticket and waits, often with no idea how long it will take. 4 Manual approval Security manually reviews and approves the new hash, then pushes the rule to the fleet. 5 Repeat forever Every package, every version, every developer. The same loop, on every routine update. The new way ## Package Rules: set and forget Point Workshop at the ecosystems your team uses, and allowlists stay current on their own. 1 Add a Package Rule Tell Workshop which packages your team uses across each ecosystem. Pin versions, allow latest, or filter by version pattern. 2 Workshop fetches signing identity Workshop pulls Team ID, Signing ID, and CDHash from each release. We unpack zip files, disk images, and tarballs to extract identifiers from the binaries inside. 3 Auto-syncs and audits When a package updates, Workshop fetches the new identifiers and pushes the rule to your fleet. Every sync is logged in the Events view. Ecosystems ## Supported ecosystems Many package managers distribute source code, but plenty also ship prebuilt binaries that trip up allowlisting the moment a new version lands. Package Rules handles both, across every ecosystem Workshop supports. ### Homebrew Formulas and casks. The full package manager, including bottles, app bundles, and command line tools. ### npm JavaScript and TypeScript packages from the npm registry, including packages that ship prebuilt native binaries. ### Cargo Rust packages from crates.io. Workshop fetches releases and extracts identifiers as new versions are published. ### GitHub Releases Any public GitHub release in owner/repo format. Workshop watches the release feed and pulls in new artifacts on schedule. ### VS Code Extensions Extensions from the Open VSX Registry, used by Cursor and other VS Code forks. Keep IDE plugins approved without manual triage. ### Terraform Providers HashiCorp and community providers from the Terraform registry, with automatic identifier extraction across versions. ### Bazel Build system dependencies and rulesets, so your build tooling stays approved as it evolves. ### Arbitrary URLs Point to any URL serving signed binaries. Workshop scans zip files, disk images, and tarballs to extract identifiers automatically. Visibility ## Full visibility into every package rule Every sync, identifier update, and applied rule is logged with package, version, identifier type, and timestamp. Review them in Workshop's Events view alongside the rest of your fleet activity. - Package, version, identifier type, and timestamp on every event - Sync runs, identifier updates, and applied rules all logged - Filter and search alongside every other Workshop event ## Package Rules are part of Workshop Pair Package Rules with the rest of Workshop to cover the full software lifecycle. [Book a demo](https://northpole.typeform.com/to/SG9jCi0v) [ ### Approval workflows Self-service approvals, designated approvers, and social voting so requests resolve in minutes, not days. ](https://northpole.security/features/approval-workflows)[ ### Risk engine Automated risk assessment for every binary. Approvers make faster, safer decisions when every request is pre-screened. ](https://northpole.security/features/risk-engine)[ ### AI Chat Ask Workshop anything about your fleet in plain English. Investigate incidents and answer compliance questions in seconds. ](https://northpole.security/features/ai-chat) ## Sitemap - [Home](https://northpole.security/index.md) - [Workshop](https://northpole.security/workshop.md) - [Santa](https://northpole.security/santa.md) - [Features](https://northpole.security/features.md) - [Cookbook](https://northpole.security/cookbook.md) - [Docs](https://northpole.security/docs.md) - [Blog](https://northpole.security/blog.md) - [Glossary](https://northpole.security/glossary.md) - [About](https://northpole.security/about.md) - [Contact](https://northpole.security/contact.md)