What Is Dependency Intelligence?

Dependency intelligence is the ability to understand every dependency in your software supply chain—what's included, what versions, what vulnerabilities, how they're connected, and whether they're actually used.

CleanStart maintains a 281M+ dependency graph across 7 ecosystems and correlates it with 809,425+ known security advisories in real time.

The Dependency Problem

Modern Software Is Built on Dependencies

Modern software development operates on a foundation of dependencies. When you build a Python FastAPI application, your direct request for FastAPI naturally cascades into a tree of transitive dependencies. FastAPI depends on Uvicorn for the application server, Uvicorn depends on Starlette for web framework utilities, and Starlette depends on Click for command-line interface support. These transitive dependencies continue to branch downward, eventually including over fifty distinct packages. The critical challenge is that most of these dependencies are transitive—you never explicitly requested them. Your requirements.txt may list only three or four packages, but your container image actually includes dozens or hundreds of transitive packages that were pulled in automatically by your direct dependencies. Each of these packages represents a potential source of security vulnerabilities, yet they remain largely invisible to most development and security teams.

The Blind Spot

When a security team asks the simple question—"How many CVEs are in your Python 3.12 plus FastAPI image?"—the traditional answer requires running a scanner and hoping for a comprehensive result. But even when a scanner runs, it returns a list of CVEs without context about whether those vulnerabilities are actually exploitable in the specific application's usage pattern.

CleanStart's approach is fundamentally different. Because the system maintains tracking for over 281 million dependencies across all major ecosystems, it can immediately answer: "Your FastAPI image includes 203 dependencies. Seventeen of those dependencies have known CVEs. Three of those CVEs are actually exploitable in your specific application's usage patterns."

This shift from "we found CVEs" to "we found CVEs, and here's which ones actually matter" is the transformative capability of dependency intelligence.

The Scale Problem

Consider the scale challenge facing typical enterprise organizations. A medium-sized company maintaining a production portfolio might deploy fifty distinct container images across their infrastructure. Each image pulls in somewhere between 100 and 500 direct and transitive dependencies, meaning the total supply chain includes between 5,000 and 25,000 dependencies across the portfolio. Tracking which CVEs matter across this scale—without automated dependency intelligence—becomes practically impossible. A security team that manually reviews each image finds themselves drowning in vulnerability reports without a clear way to distinguish critical issues from false positives. Without understanding the dependency relationships, false positives multiply and genuine threats get lost in the noise. Dependency intelligence transforms this manual, error-prone process into an automated, continuous intelligence system that makes sense of the dependencies at enterprise scale.

Seven Ecosystems Supported

Dependency intelligence is only valuable if it covers the ecosystems where your organization actually develops software. CleanStart maintains comprehensive dependency tracking across the seven major programming language ecosystems, ensuring that whether your applications are built with Go, Rust, JavaScript, Java, Python, Ruby, or C++, the dependency intelligence system provides complete visibility. The coverage extends far beyond simple package counting. For each ecosystem, CleanStart maintains real-time correlation with known vulnerability databases, continuously updates its package information, and maintains historical data that allows it to correlate vulnerabilities published months or even years after a package version was released.

Go modules support 238M+ packages with 90%+ vulnerability coverage and real-time updates. Crates (Rust) support 16.6M+ packages with 95%+ vulnerability coverage and real-time updates. npm (JavaScript) support 12.5M+ packages with 100% vulnerability coverage and real-time updates. Maven (Java) support 7.2M+ packages with 95%+ vulnerability coverage and real-time updates. PyPI (Python) support 3.4M+ packages with 100% vulnerability coverage and real-time updates. RubyGems (Ruby) support 3.1M+ packages with 95%+ vulnerability coverage and real-time updates. C++ (vcpkg, Conan) support 18.7K+ packages with 90%+ vulnerability coverage and real-time updates.

This scale of coverage means that organizations developing in multiple languages can rely on a single, unified dependency intelligence system rather than maintaining separate vulnerability tracking processes for each language and ecosystem.

The Dependency Graph

Structure

A dependency graph is a visual and conceptual model that maps the relationships between packages, showing how packages depend on each other in a hierarchical tree structure. The graph starts with your application as the root and branches downward, revealing every direct and transitive dependency.

In the concrete example of a FastAPI application, the dependency graph reveals a complex web of interconnections. Your application directly depends on FastAPI version 0.104.1, which brings with it a dependency on Starlette 0.27.0. Starlette further requires the Anyio 4.1.1 package, which itself depends on both Idna 3.6 and Sniffio 1.3.0. The FastAPI package also independently depends on Pydantic 2.5.0, which in turn brings in Annotated-types and Pydantic-core. Meanwhile, your application may also depend on Uvicorn 0.24.0, which requires Click 8.1.7 and H11 0.14.0. Click has its own dependencies, such as Colorama 0.4.6, which on some platforms (Windows) becomes part of the dependency tree while on others (Linux, macOS) may be excluded.

When this entire tree is fully expanded, the FastAPI application ends up pulling in over 200 distinct packages, both direct and transitive. This interconnected web of dependencies makes managing the security posture of the application extraordinarily complex without automated tools. A single vulnerability in a deeply-nested transitive dependency can affect dozens of applications, and tracking this impact manually is practically impossible.

CleanStart addresses this core challenge through continuous monitoring of all these interconnected packages and automated analysis that correlates vulnerabilities against the entire dependency tree.

Types of Dependencies

Understanding the different types of dependencies is crucial for proper dependency management and security assessment. Each type has different implications for vulnerability management and application behavior.

Direct dependencies are explicitly requested in your package manifest, such as fastapi==0.104.1 specified in requirements.txt. Transitive dependencies are pulled in automatically by a direct dependency, such as starlette pulled in because FastAPI needs it. Optional dependencies are only needed for specific use cases or features, such as testing-library only needed during development. Peer dependencies are expected to be provided by the consumer, such as python >= 3.7 (your environment must have Python). System dependencies are OS-level packages required at runtime, such as openssl and curl system libraries.

Direct dependencies represent packages that your application explicitly requests and is designed to use. Transitive dependencies are pulled in automatically but are equally important from a security perspective—a vulnerability in a transitive dependency is just as exploitable as a vulnerability in a direct dependency. Optional dependencies represent code that is only needed in certain scenarios, which may affect whether a vulnerability is actually exploitable in a production deployment. Peer dependencies represent packages that your application expects the installation environment to provide. System dependencies represent operating system packages that the application requires to function.

CVE Correlation

Real-Time CVE Correlation Engine

The most powerful capability of dependency intelligence is real-time CVE correlation. When a new CVE is published, CleanStart automatically correlates that vulnerability across your entire image fleet, determining which of your images are affected and prioritizing them for remediation.

To illustrate this capability with a concrete example: CVE-2024-1234 is announced as a critical Remote Code Execution vulnerability affecting OpenSSL versions 1.1.1 through 1.1.1v, with a CVSS severity score of 9.5. For an organization managing a production image fleet, this CVE announcement creates immediate questions: Which of our images contain vulnerable versions of OpenSSL? Which ones need to be rebuilt immediately?

CleanStart's correlation engine runs continuously, 24/7, and operates through a systematic verification process. First, it confirms that OpenSSL is tracked in the CleanStart dependency database (it is). Second, it analyzes the advisory to determine the exact affected version range—in this case, versions 1.1.1a through 1.1.1v. Third, it scans the entire image fleet, checking the OpenSSL version in each image.

The python-fastapi:3.12 image uses OpenSSL 1.1.1u, which falls within the affected range—this image requires immediate rebuild and redeployment. The node-express:18 image uses OpenSSL 3.0, which is outside the affected range—no action is required for this image. The go-api:1.21 image uses OpenSSL 1.1.1v, which is at the boundary of the affected range—this image also requires rebuild.

The system then automatically triggers rebuilds for the two affected images and generates notifications for the security and operations teams. Critically, this entire correlation and response process happens within minutes of CVE publication, typically completing before the security team has even seen the CVE announcement in their email.

Vulnerability Severity Scoring

Different severity scoring systems provide different perspectives on the risk posed by a vulnerability. CleanStart integrates multiple scoring approaches to give security teams a comprehensive view of vulnerability risk.

The CVSS (Common Vulnerability Scoring System) score represents the industry standard for assessing the severity of a vulnerability. CVSS is a numerical scale from 0 to 10, where higher scores indicate more severe vulnerabilities. CVSS scoring is based on factors such as the complexity of exploitation, the privileges required, the scope of impact, and the severity of impact on confidentiality, integrity, and availability. However, CVSS scoring is generic—it reflects the severity of the vulnerability as an abstract technical issue without considering whether attackers are actually exploiting the vulnerability in real-world attacks.

The EPSS (Exploit Prediction Scoring System) score provides a different kind of information: the empirical probability that a vulnerability will be exploited in real-world attacks, expressed as a percentage from 0 to 1 (or 0% to 100%). An EPSS score of 0.95 means there is strong evidence that the vulnerability is being actively exploited in the wild. An EPSS score of 0.05 means the vulnerability is rarely exploited in practice, despite potentially having a high CVSS score.

CleanStart's own Risk Score is tailored to your specific images and applications. Rather than a generic score, the CleanStart Risk Score is weighted by whether the vulnerability is actually exploitable in your specific application's usage patterns, whether you have any mitigations in place, and how frequently you deploy new versions of the affected component.

Example: CVE-2024-1234 shows CVSS of 9.5 (Critical—very severe from a technical perspective), EPSS of 0.35 (35% likelihood that attackers are actively exploiting this in real-world attacks), and CleanStart Risk (your image) of 45 (moderate risk—the vulnerability is present and somewhat likely to be exploited, but your specific application has architectural mitigations that reduce the actual risk).

Prioritization Algorithm

Not all CVEs are equally important, and security teams working with limited resources must prioritize their remediation efforts. CleanStart's prioritization algorithm considers multiple factors to compute a composite risk score that reflects the actual threat to your specific organization, rather than relying purely on generic CVSS scores.

Factors

The algorithm balances multiple inputs to produce a prioritized remediation list. The composite risk score is calculated by weighting CVSS score at 0.4, EPSS score at 0.3, exploitability in your specific code path at 1.0, public exploits available at 0.2, active attacks observed at 0.3, and time to patch at 0.1, then dividing by 6 for normalization.

The algorithm weights CVSS at 0.4, acknowledging that technical severity matters but is not the sole factor. EPSS is weighted at 0.3, because whether a vulnerability is actually being attacked matters significantly. Exploitability in your specific code path receives the highest weight of 1.0, because a highly exploitable vulnerability that your code doesn't actually use is less dangerous than a moderately exploitable vulnerability that your code directly invokes. The presence of public exploits available on the internet is weighted at 0.2, because public exploits lower the barrier to attack. Evidence of active attacks being observed in the wild is weighted at 0.3, because attacks in progress represent an immediate threat. Finally, the time to patch is weighted at 0.1, since vulnerabilities in packages you rarely update are less urgent than vulnerabilities in frequently-updated packages.

Real Example: Three CVEs in Your Image

To illustrate how this prioritization works in practice, consider three hypothetical CVEs present in your application image.

CVE-A has the highest CVSS score (9.5), suggesting it is technically severe. However, it has an extremely low EPSS score (0.02), meaning attackers are almost never exploiting it in practice. Moreover, it is not exploitable in your specific application code. As a result, the composite risk score comes back as LOW, and your security team can safely defer or even ignore this vulnerability.

CVE-B has a lower CVSS score (5.0), but an exceptionally high EPSS score (0.85), meaning there is strong evidence that attackers are actively exploiting this vulnerability in the real world. Additionally, it is exploitable in your application's code. The composite risk score returns as CRITICAL, and your security team immediately prioritizes this with a 12-hour SLA to rebuild the image.

CVE-C represents a middle ground: moderate CVSS severity (7.5), moderate likelihood of being exploited (0.40), and exploitability in your code. This returns a HIGH risk score with a 24-hour remediation SLA.

Result: By using this algorithm, the security team focuses on CVE-B and CVE-C, the vulnerabilities that actually pose risk in your deployment context, rather than investigating CVE-A which, despite its high CVSS score, represents minimal real-world risk to your organization.

Continuous Monitoring

Effective supply chain security requires continuous, automated monitoring, not periodic vulnerability scans that provide only a point-in-time snapshot. CleanStart implements library-level remediation—the ability to fix vulnerabilities at the individual library level rather than requiring wholesale rebuilds of entire images. This targeted approach enables faster, more efficient responses to newly discovered vulnerabilities.

24/7 Threat Intelligence Feed

CleanStart maintains continuous integration with multiple authoritative vulnerability databases, feeding a unified threat intelligence stream that runs around the clock. This multi-source approach ensures that important vulnerabilities are discovered quickly, before they can be exploited in production systems.

The National Vulnerability Database (NVD), maintained by NIST, is the authoritative source for published CVEs. The NVD processes approximately 14,000 CVEs and operates on a 24-hour update cycle. While the NVD is comprehensive and authoritative, it is not the fastest source of information—often taking several hours or days to fully catalog a newly-published vulnerability.

GitHub Security Advisories (GHSA) provide a faster alternative source of information for open-source vulnerabilities. GHSA typically publishes security information within hours of a responsible disclosure, ahead of the NVD's more formal documentation process. Because GHSA is package-specific and focused on open-source projects, it often includes richer metadata about remediation paths.

The Open Source Vulnerabilities (OSV) project aggregates vulnerability information from project-specific security feeds, collecting early warnings directly from upstream maintainers. OSV data is cross-referenced with NVD data to ensure consistency, but OSV often has information about vulnerabilities before the NVD's formal announcement process.

Finally, CleanStart's proprietary research team monitors early-stage vulnerability research, conducts supply-chain-specific threat analysis, and identifies zero-day vulnerabilities before they are publicly disclosed. This research feeds into the system as the most time-sensitive intelligence.

Alert Thresholds

The threshold configuration determines when the system escalates a CVE to different alert levels, triggering different remediation timelines and actions. Organizations can tune these thresholds to reflect their own risk tolerance and operational capacity.

Critical alerts require CVSS >= 9.0, exploitable true, and action of immediate rebuild (1-hour SLA). High alerts require CVSS >= 7.0, exploitable true, and action of rebuild within 12 hours. Medium alerts require CVSS >= 5.0, exploitable true, and action of rebuild within 24 hours. Low alerts require CVSS < 5.0, exploitable false, and action of review in next scheduled update.

Critical alerts require immediate action—the image must be rebuilt and redeployed within one hour. High-severity vulnerabilities must be addressed within 12 hours. Medium-severity vulnerabilities have a 24-hour remediation window. Low-severity vulnerabilities or vulnerabilities that are not exploitable in the specific application context can be bundled into the next scheduled maintenance window.

Supply Chain Visibility

Dependency Bill of Materials

Supply chain transparency has become a requirement in many regulatory frameworks and is essential for security teams to understand what they are deploying to production. Every container image built with CleanStart includes a complete Software Bill of Materials (SBOM) that documents every package, version, license, and known vulnerability present in the image. The SBOM serves multiple purposes: it provides an inventory for compliance audits, it enables rapid security assessment when new vulnerabilities are published, and it documents the exact supply chain that produced a particular image for forensic analysis if a security incident occurs.

An example SBOM shows components with type library, name fastapi, version 0.104.1, PURL pkg:pypi/fastapi@0.104.1, licenses MIT, supplier Sebastián Ramírez, and scope required. Another component shows type library, name starlette, version 0.27.0, PURL pkg:pypi/starlette@0.27.0, licenses BSD-3-Clause, supplier Tom Christie, scope required, and evidence with identity hash, property sha256, and value abcd1234.... The SBOM also includes vulnerabilities section listing component starlette with vulnerability CVE-2024-1234, CVSS score 5.3, exploitable false with evidence "Used in dev-only code path".

Transitive Dependency Tracking

Understanding the complete dependency chain from your application down to the leaf packages is critical for proper vulnerability assessment. The challenge is that transitive dependencies are often obscure—your developers may not even be aware they exist, yet they pose security risks just like direct dependencies.

Consider the specific example of Sniffio, an obscure utility library. Your application does not directly depend on Sniffio, so your developers have never heard of it. However, the application depends on FastAPI, which depends on Starlette, which depends on Anyio, which depends on Sniffio. If a critical CVE-2024-XYZ is discovered in Sniffio, that vulnerability reaches your image through this four-hop transitive chain.

Without dependency intelligence, when your security team discovers a CVE affecting Sniffio, they naturally ask: "Why is this obscure package Sniffio in our production image? We never requested it." The answer requires manual investigation of the dependency tree, which is time-consuming and error-prone for large applications with hundreds of transitive dependencies.

With CleanStart's dependency intelligence, the question is immediately answered with precision: "Sniffio is a transitive dependency of FastAPI. Your image includes it because FastAPI → Starlette → Anyio → Sniffio. This same dependency chain affects N images in your fleet." The system can immediately identify all affected images and prioritize their remediation based on the impact of the vulnerability.

Package-CVE Mappings

Correlation Database

At the heart of dependency intelligence lies a comprehensive correlation database that maps packages to the CVEs that have affected them over time. CleanStart maintains over 5,000 detailed package-to-CVE correlations, tracking not just which CVEs affect a package, but which specific versions are affected by each CVE, and whether patches are available.

Example: OpenSSL History

The history of OpenSSL's security vulnerabilities illustrates the complexity of version-specific CVE tracking. Version 1.1.1a contained CVE-2018-0732, a denial-of-service vulnerability in elliptic curve scalar multiplication. Version 1.1.1b inherited CVE-2018-0732 from its predecessor but added a new vulnerability, CVE-2018-12539, a crash vulnerability triggered by crafted curve parameters. Version 1.1.1c retained both previous vulnerabilities while adding another, CVE-2019-1010022, a memory leak in X509 certificate parsing.

The pattern continues through over 300 version-CVE combinations tracked for OpenSSL alone, documenting the evolution of the library's security posture over time. The picture dramatically improves at version 3.0.0 and later, where a major rewrite of the OpenSSL codebase eliminated many historical vulnerabilities, effectively resetting the vulnerability baseline.

This comprehensive mapping is what enables instant correlation when a new CVE is published. When the system encounters a claim that a new CVE affects OpenSSL, it can immediately check the package-CVE mapping to determine which versions are affected.

Concrete example: When you specify that your image should use "openssl 1.1.1u", CleanStart instantly consults the correlation database and returns detailed information: historically, 87 CVEs have affected the OpenSSL 1.1.1 branch. Of those 87, only 3 remain unfixed in version 1.1.1u (either because they are already patched in earlier versions that 1.1.1u built upon, or because the OpenSSL team decided not to backport fixes to the legacy branch). The remaining 84 CVEs are fixed in version 1.1.1u and will not affect your deployment using this version.

Vulnerability Analysis Report

Every container image built and analyzed by CleanStart includes a comprehensive vulnerability analysis report. This report documents the results of the four-layer analysis process and provides actionable intelligence to security teams about which vulnerabilities require attention.

A report example shows the image python-fastapi:3.12.1-amd64 scanned on 2024-01-15T10:30:00Z with 203 total packages and 156 total CVEs found. The analysis shows layer1_source_code with 156 CVEs present in source code. Layer2_binary shows 142 CVEs present and 14 CVEs not linked into binary. Layer3_runtime shows 89 CVEs reachable in code paths and 53 CVEs unreachable in code never executed. Layer4_usage shows 23 CVEs exploitable in code your app actually calls and 133 CVEs non-exploitable. The summary shows 23 true vulnerabilities, 133 false positives, 0.85 false positive rate, and 23 action items.

Integration with CI/CD

Automated Gate Enforcement

Dependency intelligence becomes most powerful when integrated into the continuous integration and deployment pipeline. Rather than treating security scanning as a separate, offline process, CleanStart integrates directly into your CI/CD workflow, enabling automated decisions about whether a newly-built image is safe to deploy.

The workflow proceeds through distinct phases. First, the image is built according to your build configuration. Second, CleanStart analyzes the image, scanning for dependencies and correlating them against known vulnerabilities. Third, a policy gate evaluates whether the image meets your organization's security standards by checking against predefined vulnerability thresholds.

You can build your image using clnstrt-cli build --config python-fastapi.yaml, then analyze dependencies and CVEs using clnstrt-cli analyze --image python-fastapi:3.12 --output report.json. The gate checks using clnstrt-cli gate --report report.json --policy policy.yaml validate no critical exploitable CVEs, no active security alerts, and no unresolved false positives, resulting in PASS → Deploy or FAIL → Stop, notify team.

If the gate passes, the image proceeds to deployment. If the gate fails, the build stops and the team is notified, preventing the vulnerable image from reaching production.

Policy Example

Security policies codify your organization's risk tolerance and remediation requirements. Rather than having security team members manually review each build, the policy engine makes consistent, repeatable decisions based on objective criteria.

Example policy specifies critical_cves: 0 (zero critical CVEs allowed), high_cves: 2 (max 2 high-severity CVEs), exploitable_rate: 0.05 (max 5% of CVEs are exploitable), false_positive_threshold: 0.85 (warn if >85% false positives), and dependencies with max_transitive: 500 (max 500 transitive deps) and require_pinned: true (all versions must be pinned).

This policy example specifies that no critical CVEs are allowed in production images. Up to 2 high-severity CVEs are acceptable, perhaps for older dependencies that are scheduled to be replaced. The policy also requires that at least 85% of detected CVEs be non-exploitable (false positives), which ensures that the image has undergone rigorous analysis rather than simple signature matching. Finally, the policy limits images to a maximum of 500 transitive dependencies, which helps control complexity, and requires that all dependency versions be pinned rather than using floating version specifiers.

Dependency Update Policies

Automated Dependency Updates

Rather than requiring security teams to manually manage dependency updates, CleanStart can automate the process according to policies that reflect your organization's risk tolerance and operational capacity. Automated dependency updates ensure that vulnerabilities are patched quickly while maintaining thorough testing before production deployment.

The update policy specifies a strategy that determines how aggressively the system pursues updates. A conservative strategy prioritizes stability and only applies critical security patches immediately, deferring regular updates to scheduled maintenance windows. A moderate strategy balances security and stability by applying security patches more quickly while still testing carefully. An aggressive strategy prioritizes security by rapidly applying all available updates.

Example policy shows strategy: "conservative" with critical_security_patches: "immediate" (apply within 24 hours), high_security_patches: "within_7_days" (apply within 7 days), and regular_updates: "monthly" (regular updates monthly). The allowlist specifies "fastapi" and "uvicorn" to always update. The blocklist specifies "some-experimental-lib" to never auto-update.

The allowlist specifies packages that the system should update automatically, while the blocklist specifies packages that should never be automatically updated (perhaps because they are experimental or have unpredictable upgrade paths).

Example: Automated Patching Flow

When a new security patch is released for a whitelisted package (such as FastAPI 0.104.2), CleanStart's dependency intelligence system automatically evaluates whether to apply the patch.

First, the system checks the policy: Is FastAPI in your organization's allowlist of packages that should be automatically updated? In this case, yes, so the process continues. Second, the system assesses whether this is a security fix or a routine update. The release notes indicate this is a security fix addressing a vulnerability, so it qualifies for immediate automated application.

Third, the system performs crucial compatibility verification: Does FastAPI 0.104.2 work correctly with all other pinned dependencies in your image? The dependency resolution algorithm verifies that no conflicts exist and that all transitive dependencies are satisfied.

If all checks pass, the system automatically initiates a comprehensive remediation workflow: A new branch is created with the updated FastAPI version (0.104.2). The image is rebuilt with the new version. The complete test suite (78 tests in this example) is run on the updated image to verify that the upgrade doesn't break functionality. Fresh SBOMs and SLSA provenance are generated for the updated image. If all tests pass, a pull request is created for human review, approved, merged back to the main branch, and the patched image is deployed to production.

This automated workflow eliminates the manual overhead of identifying, testing, and deploying security patches while maintaining rigorous testing to prevent regressions.

Performance at Scale

Dependency intelligence must operate at scale—tracking 281 million dependencies and correlating against 809,000+ CVEs requires significant computational and storage resources. CleanStart is engineered to provide instant feedback even when dealing with massive dependency graphs.

Query Performance

The system achieves fast query performance through aggressive caching, optimized data structures, and distributed processing. Dependency lookups complete in under 100 milliseconds through cached queries that are refreshed periodically. Real-time CVE correlation against the entire 281-million-dependency graph completes in under one second, enabling immediate feedback when a new CVE is published. Per-image vulnerability analysis takes under 5 seconds, fast enough to integrate into CI/CD pipelines without creating bottlenecks. Complete SBOM generation for an image completes in under 2 seconds.

These performance characteristics make dependency intelligence practical for continuous integration systems where developer feedback must be near-instantaneous.

Storage

The storage footprint reflects the scale of data maintained. The dependency graph itself, when compressed, occupies approximately 500 gigabytes. The CVE database and associated metadata requires approximately 50 gigabytes. For a typical organization, the accumulated SBOMs and analysis reports generated over a year occupies approximately one terabyte of storage, a manageable amount given modern cloud storage costs.

Regulatory Compliance

NIST SP 800-53

Modern regulatory frameworks increasingly require supply chain visibility and vulnerability assessment as core components of information security programs. CleanStart's dependency intelligence capabilities align with and satisfy multiple requirements from NIST SP 800-53, the framework most widely adopted by U.S. federal agencies and organizations seeking compliance with federal security standards.

Specifically, dependency intelligence satisfies the requirement SA-3(d) for supply chain risk management by providing visibility into the complete software supply chain. It satisfies RA-2, the risk assessment requirement, by identifying vulnerabilities present in your supply chain. The requirement CM-2 for configuration baselines is satisfied by the generation of comprehensive Software Bills of Materials that serve as authoritative baselines. Finally, the requirement SI-4 for information system monitoring is satisfied through continuous CVE monitoring that identifies new vulnerabilities in real-time.

SBOM Standards Compliance

To ensure interoperability with other security tools and to enable open-source software transparency, CleanStart generates SBOMs that comply with multiple industry standards, not a proprietary format that locks organizations into a single vendor.

CycloneDX, maintained by the OWASP community, is an industry-standard format for expressing software component information, with support for supply chain metadata and vulnerability information. SPDX, maintained by the Linux Foundation, is the most widely-recognized standard for software package information and is required by many regulatory frameworks. In-toto, developed by the secure supply chain community, provides a standard format for capturing supply chain metadata including provenance and attestations.

Next Steps

Understand deep code analysis by reading Deep Code Analysis Overview. Review the architecture in Architecture Overview. Configure images by reading YAML Image Configuration. Start building with Quick Start.

Key Insight

Dependency intelligence is not just tracking CVEs—it's understanding your entire supply chain in real time.

When a new vulnerability is published, you don't ask "does this affect us?" and wait for a manual analysis. You know instantly because the dependency intelligence system has already correlated it to your images.