## Overview The **Dependency Firewall (DFW)** enables organizations to proactively secure their software supply chain by preventing malicious or vulnerable packages from entering their development workflow. It provides policy-based control over package downloads and uploads at the registry layer, allowing security teams to enforce thresholds and block high-risk dependencies **before** they reach production — not after. DFW is shipping as a **standalone GitLab offering**, available as an add-on on **Premium and Ultimate** (not available on the Free tier). ## Problem Statement Organizations face critical supply chain security threats that current GitLab capabilities don't address: * **Registry-level vulnerability prevention.** Dependency Scanning only detects issues after packages are already in the codebase. Security teams need to block vulnerable packages at the registry level, preventing them from entering the supply chain at download time. * **Malicious package attacks.** Dependency confusion, typosquatting, and malicious packages bypass current defenses. * **Manual policy enforcement.** Teams manually review dependencies — unsustainable at scale (one customer reviews 10,000s of dependencies). * **Toolchain fragmentation.** Customers use separate tools (Nexus Firewall, JFrog XRay, Snyk Open Source) for this capability, preventing GitLab consolidation. ## Business Value ### Customer Impact Significant enterprise customer demand for registry-level supply chain controls, particularly from regulated industries — Financial Services, Healthcare, Defense, Aerospace, and Retail. Customers in these segments consistently cite Nexus Firewall, JFrog XRay, and Snyk Open Source as the standalone tools they would consolidate onto GitLab if DFW were available. ### Strategic Value 1. **Toolchain consolidation** — primary driver for displacing Nexus Firewall, JFrog XRay, and Snyk Open Source. 2. **Standalone offering revenue** — DFW unlocks a new add-on SKU layered on top of Premium / Ultimate. 3. **Retention risk mitigation** — absence creates churn risk as customers look to competing tools for this critical capability. 4. **Competitive requirement** — Azure Artifacts has this capability; customers evaluating alternatives. ## Roadmap & Phased Scope DFW ships in two phases. | Phase | Target | What it proves | |-------|--------|----------------| | **Beta** — [gitlab-org&5133](https://gitlab.com/groups/gitlab-org/-/epics/5133) | **19.5** (milestone due 2026-10-09, ships mid-October 2026) · FY27::Q3 | The enforcement engine works end to end for a real customer, on GitLab-hosted **and** external registries, with a path from zero policy to visible coverage. | | **GA** — [gitlab-org&22126](https://gitlab.com/groups/gitlab-org/-/epics/22126) | **19.7 / 19.8** (2026-12-11 / 2027-01-08) · FY27::Q4 | DFW is a commercially sellable, enterprise-grade product: richer policy rules, broader artifact coverage, and the trial-to-paid motion. | ### What changed, and why Two scope decisions reshaped this roadmap: 1. **Beta absorbed the "meet customers where they are" work.** Customers rarely migrate off an incumbent registry before they will trial a security control on top of it. Shipping Beta without external-registry support would have meant asking design partners to change their registry topology first — so **external registry support, the organization-level enable/disable toggle, and rule scoping / exclusion moved from GA into Beta**. Beta is now a self-sufficient product rather than a demo of one path. 2. **GA got leaner to protect the date.** GA is roughly two milestones after Beta. Rather than hold the commercial launch for the full original scope, GA carries a **prioritized, ordered feature list** with an explicit stretch tail. Anything below the line becomes a fast follower rather than a launch blocker — most notably Organizations / Artifact Registry support, which depends on external teams. The Beta also picks up a set of experience enhancements driven by the **Transcend customer demo on 6 October 2026** — nine days before Beta ships. These are not a separate milestone; they are additions to Beta scope, tracked under [gitlab-org&23293](https://gitlab.com/groups/gitlab-org/-/epics/23293). ### Beta — in progress · [gitlab-org&5133](https://gitlab.com/groups/gitlab-org/-/epics/5133) **Enforcement core** * Admission control for **Maven, npm, PyPI, Gem** packages (upload + download) * Policy rules: severity thresholds (including per-severity vulnerability counts), license rules (with `UNKNOWN` handling), malicious-package blocking * `policies.yaml` configuration, built on **Security Policies v1** — no new policy framework * Warn / block modes, audit events for blocks and bypasses, bypass path for a named user or token * Evaluation performed in the `glab` CLI via an embedded proxy, rather than routing all package traffic through the Package Registry — a pivot taken to avoid the network egress cost of registry-side interception **Coverage and control surface** * **External registries** — evaluate packages pulled from any registry DFW does not host: Artifactory, Nexus, a self-hosted mirror, and GitLab **Artifact Registry**. A customer can adopt DFW without first migrating registries, and AR consumption is covered from Beta rather than waiting for GA. * **Top-level Organization toggle** to enable / disable DFW, and **scoping / exclusion** of rules across project / group / organization / registry * Policy-aligned registry scoping at **project** and **top-level group** levels * Package Registry + Package Forwarding — supported; Virtual Registry + Dependency Proxy — experimental **Experience (includes the Transcend enhancements)** * DFW dashboard, extended with value metrics and blocked-package investigation * Guided onboarding — zero policy to understandable coverage, including policy creation and DFW's presence in the security inventory * Duo-assisted project enablement (POC) * `glab package_check` CLI for pre-pipeline checks ### GA — [gitlab-org&22126](https://gitlab.com/groups/gitlab-org/-/epics/22126) GA scope is **ordered by priority**. The list is deliberately short; the GA epic's checklist is the authoritative, linked version. 1. **Package Age rule** — block versions that are too young (the typosquatting window) or too old / unmaintained 2. **Allow / Deny lists** — deny or allow a specific package at a specific version or range, with reason and expiry 3. **Trial & Paid flow** — credit-metered trial, Monitor mode when enforcement stops, in-app conversion 4. **CI cached dependencies** — close the gap where a package cached before a policy existed is reused unchecked 5. **Container image support** — evaluate images at registry push and at build output 6. **Dashboard UX / UI upgrades** — building on the Transcend enhancements delivered in Beta 7. **`glab` full manifest check** — evaluate a whole manifest against the effective policy set, before a pipeline runs **Stretch for GA** (ship if the date holds; otherwise fast followers): * **Dedicated** distribution * **Organizations** support — policy authored once at the Organization and inherited downward. Gated on Non-isolated Organizations, Virtual Registry maturity, and an SPP framework change, all owned by other teams. _Artifact Registry is no longer part of this — it is reached through the Beta external-registry path._ * **Upstream-enforcement header** — `glab` stamps a header on forwarded traffic so an enterprise can configure its network to accept only requests that passed the firewall, making DFW unbypassable from a developer machine GA also carries the non-feature launch bar: operational readiness (HA, SLOs, runbooks, load and performance testing), GA pen test, legal review, distribution to .com and Self-Managed, pricing and SKU enforcement, PMM launch, documentation, support enablement, and the product analytics dashboard. ### Post-GA · [gitlab-org&20527](https://gitlab.com/groups/gitlab-org/-/epics/20527) * **Frictionless onboarding** — enforce DFW without requiring a `glab df` wrapper in `.gitlab-ci.yml`. This is the single largest adoption tax in the current design, and solving it natively is a competitive-advantage opportunity (JFrog has not). * **Package quarantine** — hold a package pending review rather than only allow or block * **Extended permissions model** — the full role-separation table, if Beta and GA feedback show the current model is insufficient * **Remediated vulnerabilities** — account for vulnerabilities that have already been remediated when evaluating a package, to reduce false blocks * Duo agent integration ("fix this for me" remediation) * Pipeline UI surfacing of DFW results (beyond console job trailer) * Periodic registry scanning * JWT authentication for container registry API calls * Transitive container risk + container malware * Additional package ecosystems beyond Maven / npm / PyPI / Gem * **Git-clone based packages** — separately tracked in [gitlab-org&20365](https://gitlab.com/groups/gitlab-org/-/epics/20365) ### Moved to GitLab Trust (out of DFW scope) * Container image attestation * Container Registry attestation verification rules * Integrity checks — cryptographic hash verification ## Success Metrics Strategic outcomes tracked across Beta + GA. Detailed M1–M14 instrumentation lives on the [GA epic](https://gitlab.com/groups/gitlab-org/-/epics/22126); top-line targets: * **Reliability** — 99.9% DFW enforcement availability * **Performance** — \<100 ms p95 registry latency overhead * **Adoption (customers)** — 5+ paying top-level groups within 90 days post-GA * **Commercial** — 25%+ trial-to-paid conversion * **Coverage** — 10,000+ dependencies evaluated per week within 6 months post-GA * **Attach rate (post-GA roadmap)** — % of Premium + Ultimate customers purchasing the DFW add-on ## Target Audience * **Primary:** Large Enterprise customers (1,000+ users) in regulated industries — Financial Services, Healthcare, Defense, Aerospace. * **Personas:** Security Engineers, DevSecOps leads, Platform Engineers, Compliance Officers, Developers (via IDE shift-left). ## Packaging & Positioning * **Offering model:** DFW as a standalone GitLab product, available as an add-on on **Premium and Ultimate**. **Not available on Free.** * **Pricing:** consumption-based direction agreed with Fulfillment; final decision tracked as GA checklist item **C1**. * **Displacement target:** Nexus Firewall, JFrog XRay, Snyk Open Source. * **Target Beta:** **19.5** · **Target GA:** **19.7 / 19.8** (FY27::Q4). ## DRIs & Group * **PM:** @ashalem * **EM:** @mikeeddington * **UX:** @mifinch * **Product Design Manager:** @mhenri (Marissa Henri) * **Group:** ~&quot;group::pipeline security&quot;