CI/CD Pipeline Protection
Check every package your pipelines install against the same rules. Only the registry URL on your runners changes, and each install is logged with the user or token that made it.
Today pipelines install whatever the public registries serve
Build jobs run npm ci, pip install and mvn package many times a day. Most fetch directly from npmjs.org, PyPI and Maven Central, and nothing checks what comes back.
- Checks are copied between pipeline files
- A check added to one pipeline is missing from the next project someone sets up.
- Bots update dependencies within hours
- Dependabot and Renovate open pull requests for new versions soon after release, and CI installs them to run the tests.
- Job logs are the only record
- When an incident involves a package, finding the builds that installed it means searching job logs across systems.
Check every package a pipeline installs
Pipelines install through a CI firewall that inherits its rules from a shared baseline firewall. Every job follows the same rules with no change to the pipeline file.
Give every pipeline the same rules
Centralize firewall rulesHold the versions bots pick up within hours
Release delayStop a malicious version before a job installs it
Malware blockingFail a job on a version above your threshold
Vulnerability blocking
- License enforcement
- Block packages under licenses that are not approved, for direct and transitive dependencies.
- Dependency confusion
- Internal package names resolve from your private registry only.
- Container firewalling
- Image pulls in a pipeline pass the same rules.
Only the registry URL changes. Nothing is installed on developer machines.Supported ecosystems
A rule change reaches every pipeline
Rules on the baseline firewall run before the CI firewall's own rules and cannot be weakened downstream. Change the baseline and every pipeline gets the change on its next install.
Find what a pipeline installed
Filter the logs by firewall, phase, status and user to see what a pipeline installed. The audit log exports to your SIEM.
Who works with it
- Platform engineers
- The registry URL sits in the runner image, so a new project gets the rules with no pipeline changes.
- Security teams
- Every pipeline follows the same rules, and the log shows what each one installed.
- Developers
- Local installs and CI use the same rules, so a build does not fail on a package that installed fine locally.
Questions
Does this require changes to our pipelines?
Only the registry URL. Pipelines and package managers keep working as they do today.
Can we have stricter rules for production pipelines?
Yes. Create a firewall per environment with its own rules, all inheriting the same baseline.
Can we manage firewall configuration in Git?
Yes. Firewall configurations are small JSON files. Deploy them through the API from your existing automation. Every change is tracked and can be rolled back.
Does it work with our existing repository manager?
Yes. Dependency Firewall runs as a proxy in front of JFrog Artifactory, Sonatype Nexus, GitLab, Azure Artifacts, GitHub Packages or the public registries.
More Dependency Firewall use cases
All use cases- Malicious PackagesBlock malicious packages and account-takeover payloads before anyone installs them.
- Vulnerable DependenciesStop packages with known CVEs at the firewall before they land in a build.
- AI Coding AgentsCheck every install an agent makes against the rules your security team sets.
- Policy GovernanceLet security set the dependency rules for every team and approve waivers for blocked packages.
Try it on one registry
Point one package manager at Dependency Firewall and check the log after the next install. The trial runs 14 days.