Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Gig-economy / Workforce SaaS Platform |
| Cloud Environment | AWS |
| Code & CI | Bitbucket for SCM, Jenkins for CI |
| Org Size | ~300-person company; lean DevOps / platform function |
| Requested By | Tech lead driving the security program |
| Focus Area | Software Risk Register / component inventory |
The Situation: “I Want to Know Every Library We Ship”
The tech lead driving this team’s security program made a specific, forward-looking request. He wanted a Software Risk Register — a way to know, at any moment, every code library that is part of their platform. Not just the components that currently have a flagged issue, but the full inventory. His framing was exact:
“Show me if we have log4j — or simply which repositories use log4j, which versions, and whether those versions have any CVE or EPSS score.”
His frustration with the tooling he had seen was equally specific: security tools tend to show you only the components that have problems right now. There was no “Components” view — a first-class way to browse the software bill of materials the way you can browse repositories or SAST findings. When the next Log4Shell-style disclosure lands, the question every security lead asks in the first hour is “are we affected, and where?” A tool that only lists currently-flagged components cannot answer that for a package that was considered safe yesterday.
The Core Tension
A vulnerability-centric view answers “what is wrong today.” A risk register has to answer “what do we have” — because the most urgent question during a zero-day is about a component that had no CVE until an hour ago. Those are different data models: one is a findings list, the other is a complete, queryable component inventory that exists independent of whether any given package is currently vulnerable.
Where the Gaps Were
Only Problem Components Are Visible
When the inventory is derived from the findings list, a package with no current CVE is effectively invisible. The moment a new advisory drops for that package, the team is blind — they cannot query “who uses it” because it was never surfaced as a component in its own right.
No Way to Pivot From Component to Repositories
Security leads think in components during an incident: “where is log4j?” But a repo-first tool makes you open each repository and inspect its dependencies one at a time. For a platform with many repositories across Bitbucket, that is an afternoon of manual spelunking at exactly the moment speed matters most.
SBOMs Trapped Per-Repo, Never Aggregated
Even when a scanner generates a software bill of materials per repository, if those SBOMs are not aggregated into one searchable inventory, the “register” only exists as scattered fragments. There is no single place to ask a question across the whole estate.
How Cloudanix Addresses This
A CycloneDX SBOM for Every Bitbucket Repository
Cloudanix Code Security connects to Bitbucket and, through SCA, generates a CycloneDX SBOM per repository — cataloguing direct and transitive dependencies across the ecosystems the team uses. This is the raw material of a risk register: a structured, machine-readable list of every component the platform ships, not just the ones currently flagged.
Filter and Search by Package Name and Version
The capability the tech lead asked for maps directly to Cloudanix’s package-level view: filter the component inventory by package name and version, so “which repositories use log4j, and which versions” is a filter, not a code audit. When a new disclosure names a specific package and version range, the team scopes their exposure in seconds.
CVE and EPSS Attached to Each Component
Each component in the inventory carries its vulnerability status — matched against Cloudanix’s 28-feed vulnerability database with KEV and EPSS context — so the register is not just “what we have” but “what we have, and how exposed each piece is.” A clean component stays in the inventory as a known-good entry; the instant a CVE is published against its version, the register reflects it. (See what EPSS is and how to prioritize which CVEs to fix.)
Export for Compliance and Ownership
The per-repo SBOM can be exported — useful for compliance evidence and for establishing ownership of components across teams. For an organization that fields customer security questionnaires, “here is our software bill of materials” is a far stronger answer than “we think we are fine.”
Platform Impact
| Dimension | Findings-Only View | Component Inventory / Risk Register |
|---|---|---|
| What’s visible | Only currently-flagged packages | Every component, flagged or not |
| Zero-day response | Blind until a CVE exists | Filter by package/version instantly |
| Pivot model | Repo → dependencies, one at a time | Component → all repositories at once |
| SBOM | Scattered per repo | Aggregated and queryable |
| Compliance | Assertions | Exportable SBOM evidence |
Why a Register Beats a Findings List
A findings list is reactive by construction — it can only show you what some feed has already flagged. A Software Risk Register is proactive: it is the inventory you query the moment a new threat is named, before any scanner has caught up for your specific versions. The log4j example the tech lead used is the canonical case — organizations that had a current, searchable component inventory answered “are we affected?” in minutes during Log4Shell, while those relying on findings lists spent days manually auditing repositories. Building the register in calm times is what makes the crisis-time answer fast.
Key Outcomes
- ✅ Per-Repo SBOM: CycloneDX bill of materials for every Bitbucket repository.
- ✅ Component-First View: Filter by package name and version across the estate.
- ✅ CVE + EPSS Per Component: Exposure attached to every entry, flagged or not.
- ✅ Instant Zero-Day Scoping: “Who uses this package and version?” answered in seconds.
- ✅ Exportable Evidence: SBOM export for compliance and component ownership.
Want a Live Inventory of Every Library You Ship?
If your tooling only shows you components that already have a problem — and you want to answer “which repos use this package, and which versions?” the moment the next disclosure lands — Cloudanix builds a searchable component inventory from a per-repo SBOM.
Book a Free Assessment to see your component inventory across Bitbucket in under 30 minutes, or explore the interactive demo on the Code Security page.
Related Resources
- What is Software Composition Analysis (SCA)?
- What is Software Supply Chain Security?
- What is EPSS?
- How to Prioritize Which CVEs to Fix
- Prioritizing High and Critical Dependency CVEs With KEV and EPSS for Bitbucket Repos
- Code Security for Bitbucket: SAST, SCA, Secrets, and Real-Time Workspace Threat Monitoring
