--- title: "Making the right thing the default | Cloudsmith for Capital One" description: "Capital One has built one of the most sophisticated engineering organisations in financial services. The artifact layer hasn't kept pace. Cloudsmith gives platform teams policy enforcement and developer experience without the tradeoffs they've accepted from JFrog." canonical_url: "https://cloudsmith.com/loves/capital-one" last_updated: "2026-06-08T11:11:24Z" --- # Making the right thing the default | Cloudsmith for Capital One Cloudsmith for Capital One ## Make the right thing the default behaviour. Capital One has built one of the most sophisticated engineering organisations in financial services. Cloudsmith gives platform teams policy enforcement at ingestion and developer experience without the tradeoffs. [Talk to the team](/company/contact-sales) [See how policy enforcement works](/product/software-supply-chain-security) ## Where JFrog leaves the platform team holding the problem At 15,000 developers, the gap between detection and enforcement becomes a full-time operational burden. Cloudsmith enforces policy at ingestion and closes the developer feedback loop. The right thing becomes the default behaviour. | With JFrog Artifactory | With Cloudsmith | | --- | --- | | X-Ray scans after the package is already in Artifactory. There is a gap between a package arriving and a vulnerability being flagged – during which developers can already pull it. | Policy runs at the point of ingestion. A package that violates the rules is quarantined immediately – before it is ever resolvable. Developers cannot pull it because it is never made available. | | X-Ray generates a report. A platform or security engineer reads it, identifies affected packages, traces every consuming team, and coordinates remediation manually. At Capital One's scale, this is a full-time operational burden. | Cloudsmith quarantines the package automatically. Security teams review the quarantine queue and decide to release or permanently block. The workflow is defined by policy, not improvised per incident and not dependent on engineer availability. | | When a package is blocked, developers get a resolution failure with no context. No explanation of why. No guidance on what to do next. No exception path. The platform team absorbs every support ticket. | When a package is quarantined, developers get a clear, actionable error. They know why the package was blocked, what the policy violation is, and how to request an exception if one is warranted. The audit trail captures every decision. | | ECR manages container images. GitHub Packages handles some dependencies. S3 holds binaries. Language-specific registries cover the rest. Multiple access models, multiple policy frameworks, no consistent enforcement across any of it. | One platform handles every format – Docker, npm, Maven, NuGet, PyPI, Helm, and more. Policy is defined once and applied consistently across all of them. One access model, one audit trail, one set of controls. Platform teams maintain one integration, not seven. | ## Policy enforcement that runs before a developer sees the package Rules run as code. When a package arrives on One Pipeline, policy runs before any developer can pull it. One definition, enforced everywhere. - Policies written in OPA Rego: version-controlled, reviewable, and consistently applied across every repository on the platform - Packages violating CVSS thresholds are quarantined automatically on arrival – before they are resolvable - Security teams manage the quarantine queue directly – release or block, with full context on why each package was flagged - License compliance violations are caught at ingestion, not discovered during a legal review six months later [Learn how policy enforcement works](/product/software-supply-chain-security) ## Quarantine closes the developer feedback loop When a build fails because of a quarantined package, the developer gets a structured error: what the policy violation is and what their options are. Exception requests follow a defined workflow. When a new CVE lands, Cloudsmith rescans existing packages and quarantines retroactively. The platform team stops fielding support tickets. Security and developer experience stop trading off against each other. - Quarantined packages cannot be resolved – developers cannot pull what the policy blocks - Developers get a structured, actionable error explaining why the package was blocked and what the path forward is - Exception requests follow a defined workflow – no informal escalations, no undocumented approvals - When a new CVE lands, Cloudsmith rescans existing packages and quarantines retroactively – no manual sweep required - Every quarantine event, every decision, and every actor lands in the audit log by default [See quarantine and blocking in action](/product/software-supply-chain-security) For AppSec and DevSecOps teams ## The controls your security team needs. Without the infrastructure. Cloudsmith gives your AppSec and DevSecOps teams the controls to enforce security consistently across your software supply chain — without adding operational overhead or requiring developers to change how they work. ### Dependency graph visibility Cloudsmith's dependency graph shows every package in every repository, what it depends on, and which teams are consuming it. When a CVE lands, you know the blast radius immediately. No manual investigation, no cross-team interviews. ### Full audit trail Every push, pull, policy trigger, quarantine event, and configuration change is logged with full context — who, what, when, from where. Client logs and audit trails export to your SIEM or S3. Compliance and incident response have the evidence they need. ### Continuous vulnerability scanning Cloudsmith scans against multiple vulnerability data sources, not just NVD. Continuous rescan means your repositories stay current as new CVEs are disclosed — no manual sweep required, and no reliance on a single feed with known backlog issues. Migration ## Migration is a solved problem. Cloudsmith's customer onboarding team runs a structured migration path that makes migrating off Nexus and Artifactory a smooth, predictable process. Other engineering organizations have run it in phases, without downtime, using our dedicated support team to design and manage the transition. [Talk to our team about migration](/company/contact-sales) ### Repository structure mapping Cloudsmith maps your existing Nexus and Artifactory repository structure format by format, with metadata preserved. ### Phased artifact transfer, no downtime Artifacts migrate in phases. Your teams continue resolving from existing registries until each repository is cut over. No big-bang migration, no forced downtime window. ### Pipeline and credential migration CI/CD pipelines, environment variables, and package manager configuration are updated to point to Cloudsmith endpoints. Upstream proxying means public dependencies resolve through Cloudsmith from day one. ### Dedicated onboarding support Cloudsmith's onboarding team works with your security and platform engineers through every stage. Named contacts, agreed deadlines, and regular check-ins — not self-serve documentation. ## Customers love Cloudsmith [Read reviews on G2](https://www.g2.com/products/cloudsmith/reviews) ## See what Cloudsmith looks like inside Capital One Policy enforcement at ingestion. Quarantine with a developer feedback loop. A full audit trail by default. One platform built for over 14,000 Capital One developers. Talk to our team and we'll show you exactly how it works at Capital One's scale. [Explore supply chain security](/product/software-supply-chain-security) [Talk to the team](/company/contact-sales)