The Problem with Shallow Scanning

Traditional vulnerability scanners find CVEs by matching package versions against a vulnerability database. They find that OpenSSL 1.1.1 contains CVE-2024-1234 with a CVSS score of 9.5 and immediately report it as a critical vulnerability. However, the scanner doesn't ask the crucial question: Is this vulnerability actually exploitable in my image? It can't determine whether the vulnerable code path is reachable in your application, whether your code actually calls the vulnerable function, or whether the vulnerability is in code that's never executed. As a result, 85% of reported CVEs are false positives, causing your security team to waste thousands of hours per year investigating phantom vulnerabilities. CleanStart's solution is to perform deep code analysis across four layers to prove exploitability, reducing false positives by 85%.

Four-Layer Code Analysis

The following diagram illustrates the four-layer deep code analysis flow from source through actual usage:

graph TB    A["CVE Detected<br/>OpenSSL CVE-2024-1234<br/>CVSS 9.5"] -->|Layer 1| B["Source Code<br/>Analysis"]     B -->|Parse| C["Abstract Syntax<br/>Tree AST"]     C -->|Find| D["Vulnerable<br/>Function<br/>EVP_EncryptInit_ex"]     D -->|Result| E["✓ Vulnerable Code<br/>Present in Source"]     E -->|Layer 2| F["Binary<br/>Analysis"]     F -->|Compile| G["Check Binary<br/>Symbols"]     G -->|Verify| H["Symbol in<br/>Executable?"]     H -->|Yes| I["✓ Vulnerable Symbol<br/>Linked into Binary"]     I -->|Layer 3| J["Runtime<br/>Reachability<br/>Analysis"]     J -->|Trace| K["Execute Image<br/>with Workloads"]     K -->|Track| L["Call Graph<br/>of Executed<br/>Functions"]     L -->|Check| M["Function Called<br/>at Runtime?"]     M -->|No| N["✗ Code Never<br/>Executed<br/>Not Reachable"]     M -->|Yes| O["✓ Code Called<br/>at Runtime"]     N -->|Result| P["VEX Status:<br/>not_affected<br/>Confidence 98%"]     O -->|Layer 4| Q["Actual Usage<br/>Analysis"]     Q -->|Analyze| R["Your App Code<br/>Uses which functions?"]     R -->|Correlate| S["EVP_EncryptInit_ex<br/>Used in Your Path?"]     S -->|Yes| T["✓ Vulnerable Code<br/>Used in Your App<br/>Exploitable"]     S -->|No| U["✗ Vulnerable Code<br/>Not Used<br/>Non-exploitable"]     T -->|Action| V["VEX Status:<br/>affected<br/>Requires Patch"]     U -->|Action| P     P -->|Reduce| W["87% False Positive<br/>Reduction"]     V -->|Reduce| W     style B fill:#ccffcc    style F fill:#ccffcc    style J fill:#99ccff    style Q fill:#99ccff    style P fill:#99ff99    style V fill:#ffcccc    style W fill:#ffff99

Layer 1: Source Code Analysis

What it does: Parse source code to identify vulnerable patterns and unsafe functions.

The first layer of deep code analysis begins at the source level. CleanStart downloads the source code for every package and parses it into an Abstract Syntax Tree (AST), which is a tree-based representation of the code's syntactic structure. Once converted to an AST, the analysis engine can systematically identify dangerous functions, unsafe patterns, and potentially exploitable APIs. During this phase, the system flags known dangerous constructs such as strcpy, sprintf, unvalidated input handling, hardcoded secrets, and other patterns that correlate with known vulnerability categories. This source-level analysis establishes the foundation for determining whether a CVE is even theoretically present in the code.

Example: OpenSSL CVE-2024-1234

// OpenSSL source codeint unsafe_crypto_operation() {  // CVE-2024-1234 affects this specific code path  unsigned char buffer[16];  EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();   // Vulnerable operation (in old OpenSSL 1.1.1)  EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), nullptr, key, iv);   // ... rest of function}

Analysis result: "This OpenSSL source contains the vulnerable function EVP_EncryptInit_ex used in an unsafe way (CVE-2024-1234)."

Output: Vulnerability flagged at source level.

Layer 2: Binary Analysis

What it does: Analyze compiled binaries to confirm vulnerability made it into the executable.

The second layer acknowledges that identifying vulnerable code in source is only part of the story. Code may be written vulnerably but removed during compilation, or stripped by optimizers, or never linked into the final binary. This layer performs rigorous binary analysis by compiling the source code to binary form and then extracting the symbol table, function pointers, and relocation information. During binary analysis, CleanStart also verifies that security compilation flags have been properly applied—checking for protections such as Address Space Layout Randomization (ASLR), stack canaries, and Position Independent Executables (PIE). The analysis confirms not only that vulnerable symbols are referenced in the binary, but that the vulnerable function is actually linked and will be present when the image executes.

Example: Verify CVE-2024-1234 in Binary

# Check if vulnerable symbol is in binarynm /usr/lib/libssl.so.1.1 | grep EVP_EncryptInit_ex# Output: 0000000000001234 T EVP_EncryptInit_ex # Vulnerable symbol IS in binary, but...# Check if it's actually calledobjdump -t /usr/lib/libssl.so.1.1 | grep EVP_EncryptInit_ex# (symbol information extracted) # Check compilation flagsreadelf -l /usr/lib/libssl.so.1.1 | grep STACK# Output: GNU_STACK      0x000000 0x... RW- ... (stack canary info)

Analysis result: "CVE-2024-1234 symbol is in the binary, compilation flags are correct, vulnerability is present in compiled form."

Output: Binary-level confirmation of vulnerability presence.

Layer 3: Runtime Reachability Analysis

What it does: Determine which code paths are actually executed at runtime.

Even if vulnerable code is present in the binary, it is not exploitable if it is never executed. This is the critical insight that leads to the dramatic reduction in false positives. The third layer instruments the image with a runtime tracer and then executes the image with representative workloads designed to exercise typical operational patterns. During execution, CleanStart tracks which functions are called at runtime and builds a complete call graph that represents the actual code paths traversed. By comparing the vulnerable functions identified in the first two layers against this runtime call graph, the analysis can definitively determine whether the vulnerability is reachable—that is, whether the code will actually execute under normal operational conditions.

Example: OpenSSL Vulnerability Reachability

# Your application codefrom openssl import encrypt, decrypt def process_data(data):  encrypted = encrypt(data)  # Uses EVP_EncryptInit_ex (REACHABLE)  return encrypted def legacy_operation():  # This function is defined but never called  unsafe_crypto_operation()  # CVE-2024-1234 (UNREACHABLE)  return None # Your app never calls legacy_operation()

Runtime analysis: During execution tracing, CleanStart observes that process_data() is called at runtime, which in turn calls encrypt() and uses EVP_EncryptInit_ex. However, legacy_operation() is never invoked during execution, so the vulnerable code path is never reached.

The key finding is this: while process_data() is called and leads to usage of EVP_EncryptInit_ex (making it reachable), legacy_operation() is never called during the execution trace, making the vulnerable code unreachable and therefore non-exploitable in the runtime context.

Analysis result: "CVE-2024-1234 code is in the binary, but is never called at runtime."

Output: Runtime-level confirmation that vulnerability is unreachable.

Layer 4: Actual Usage Analysis

What it does: Analyze your application code to determine which functions are actually called.

The fourth and final layer shifts perspective from the dependency itself to the consuming application. After establishing that vulnerable code may exist in a dependency, this layer performs static analysis of your own application code to understand exactly which library functions your code actually calls. By correlating the CVE's scope against your actual usage patterns, the analysis can make a final determination: even if a vulnerable function exists in a dependency, if your code never invokes that function, the vulnerability is not exploitable in your specific application. This layer is the most powerful filter for eliminating false positives, as it accounts for the reality that few applications use every function exported by their dependencies.

Example: Actual Usage in Your App

# Your FastAPI applicationfrom fastapi import FastAPIfrom cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modesfrom cryptography.hazmat.backends import default_backend app = FastAPI() @app.post("/encrypt")def encrypt_data(data: str):  # Your app uses: AES-256-CBC encryption  cipher = Cipher(    algorithms.AES(key),    modes.CBC(iv),    backend=default_backend()  )  encryptor = cipher.encryptor()  return encryptor.update(data) + encryptor.finalize() # Your app does NOT use:# - RSA operations# - Elliptic curve operations# - HMAC operations# - MD5 (deprecated, FIPS non-compliant)

Analysis result: "Your app uses AES-256-CBC encryption. CVE-2024-1234 affects EVP_EncryptInit_ex in OpenSSL legacy mode. Your usage path is: cryptography library → OpenSSL → EVP_EncryptInit_ex. Vulnerability is exploitable in your specific code path."

Output: Application-level confirmation of exploitability.

Putting It Together: The Four Layers

The power of the four-layer analysis emerges when the layers work together as an integrated investigation pipeline. Consider a concrete scenario: an OpenSSL vulnerability (CVE-2024-1234, CVSS 9.5) has been discovered and published.

The first layer examines the source code and confirms that vulnerable code does indeed exist in OpenSSL 1.1.1. The second layer compiles the source to binary and verifies that the vulnerable symbol EVP_EncryptInit_ex is present in the compiled binary. But here is where many analyses would stop and declare a critical vulnerability.

The third layer, runtime reachability, executes the image with representative workloads and traces the actual call graph. In this example, the vulnerable code path IS called at runtime when the application executes—establishing that the code is reachable in this particular deployment scenario.

Finally, the fourth layer examines your specific application code and confirms that your application actually calls this vulnerable function in its code path, through the cryptography library, which in turn invokes OpenSSL's EVP_EncryptInit_ex.

Final Verdict: EXPLOITABLE (requires immediate patch or workaround)

This image is flagged as truly vulnerable because all four layers confirm the vulnerability is both present and reachable in your application's code paths. A VEX attestation will document this status and provide evidence for compliance auditors and security teams.

Handling False Positives

Not every vulnerability affects every image, yet traditional vulnerability scanners treat the presence of a vulnerable package as equivalent to the presence of a vulnerable application. This approach leads to the false positive crisis mentioned at the beginning of this overview.

Consider a concrete example to illustrate how CleanStart's approach differs fundamentally. Your application depends on FastAPI, which itself depends on Starlette, which in turn depends on requests. The requests library depends on urllib3 for HTTP transport. A critical CVE-2024-5678 is discovered in urllib3. However, FastAPI's implementation never actually imports urllib3 directly—it delegates HTTP transport to another mechanism.

A traditional scanner would report this immediately: "urllib3 CVE-2024-5678 found in your image—CRITICAL!" This report creates urgency and requires investigation, but the investigation will eventually reveal that the vulnerability is not actually exploitable in your application.

CleanStart's four-layer analysis, by contrast, performs a deeper investigation before raising an alert. At the source layer, the CVE exists in urllib3 source code—this is confirmed. At the binary layer, urllib3 is compiled into your image—also confirmed. But the critical revelation comes at the runtime layer: urllib3 functions are never called when your application runs, as verified through execution tracing. At the usage layer, your FastAPI code doesn't use any urllib3 functions, as confirmed through static analysis of your own code.

Result: A VEX attestation marks this CVE as "NOT AFFECTED" because it is not exploitable in your specific code paths. This single determination eliminates a false positive alert, reduces investigation burden, and frees your security team to focus on genuinely exploitable vulnerabilities.

VEX (Vulnerability Exploitability Exchange)

What Is VEX?

VEX is a standard format for documenting vulnerability exploitability status. Instead of "we found this CVE" (generic), VEX says "we found this CVE and here's why it is/isn't exploitable in your specific image."

VEX Attestation Format

{  "@context": "https://openvex.dev/ns/v0.2.0",  "tooling": "CleanStart v2.0",  "statements": [    {      "vulnerability": {        "name": "CVE-2024-1234"      },      "timestamp": "2024-01-15T10:30:00Z",      "products": [        {          "identifiers": {            "purl": "pkg:docker/python-fastapi@3.12"          }        }      ],      "status": "not_affected",      "justification": "code_not_present",      "details": "CVE-2024-1234 affects OpenSSL EVP_EncryptInit_ex in legacy mode. Analysis shows this code path is not reached in the compiled binary. Function is defined but never called at runtime. FastAPI application uses only modern cipher modes."    }  ]}

VEX Status Values

The VEX specification defines three possible status values for each vulnerability assessment. The status "affected" indicates that the vulnerability is present in your image and is exploitable—this typically occurs when a vulnerability is discovered in a directly-used library and your code actually invokes the vulnerable function. The status "not_affected" indicates that while the vulnerability may be present in a dependency, it is not exploitable in your specific image—this covers scenarios such as the urllib3 example above, where the code is present but never called. Finally, "unknown" indicates that the analysis framework cannot definitively determine exploitability, typically because a vulnerability is very new and analysis is still pending or because the analysis encounters a situation it cannot fully evaluate.

Result: 85% False Positive Reduction

The quantitative benefit of this approach becomes clear when examining real-world deployment scenarios. Consider a typical container image that undergoes vulnerability scanning. A traditional approach finds 342 CVEs and reports all of them to the security team. Since 291 of these are false positives (about 85%), the security team must investigate all 342 CVEs, spending approximately 4 hours per CVE to assess context and determine exploitability. This investment totals 1,368 hours of investigation labor for a single image.

CleanStart's four-layer analysis approach finds the same 342 CVEs but then determines that 291 are not actually exploitable in the context of the image. VEX attestations are generated marking these vulnerabilities as "not_affected." The security team now investigates only the 51 genuinely exploitable vulnerabilities, spending 4 hours per vulnerability, which totals 204 hours.

Impact: This difference represents 1,164 hours saved per image. For organizations managing dozens or hundreds of container images, this translates to thousands of hours of security engineering time freed to focus on truly actionable security issues rather than phantom vulnerabilities.

AST (Abstract Syntax Tree) Analysis

What Is an AST?

An Abstract Syntax Tree is a tree-structured representation of the syntactic structure of source code. Rather than a linear sequence of characters, an AST models the hierarchical grammatical relationships within code. CleanStart uses AST analysis as a foundational technique to detect vulnerable code patterns before the code is even compiled, allowing vulnerabilities to be identified at the earliest possible stage of the development pipeline.

When source code is parsed into an AST, the structure of the code becomes explicit and queryable. Function calls, variable assignments, control flow, and other structural elements are represented as nodes in the tree. This structure allows sophisticated pattern matching: searching for specific function calls (such as dangerous cryptographic operations), identifying string concatenations that might indicate injection vulnerabilities, and detecting hardcoded secrets that are embedded directly in the source.

Example: Detecting Unsafe String Operations

The following example illustrates how AST analysis reveals dangerous patterns that might be missed by simpler text-based scanning. A developer writes code that appears to perform a simple HTTP request, but the code contains multiple security vulnerabilities.

# Python AST for vulnerable codeimport ast code = """import ospassword = "secret123"cmd = f"curl --user {os.environ.get('USER')}:{password} https://api.example.com"os.system(cmd)  # DANGEROUS: Command injection risk""" tree = ast.parse(code)# AST shows:# - String concatenation with environ variable# - Command passed to os.system (high-risk function)# - Potential command injection vulnerability

When this code is converted to an AST, the analysis engine discovers several problems. First, it detects that a hardcoded string literal containing a password ("secret123") is present in the source. Second, it observes that this password is being concatenated with an environment variable into a string that is then passed to os.system()—a high-risk function because it spawns a shell to execute the command. The combination of these factors creates a command injection vulnerability: if the USER environment variable contains shell metacharacters, an attacker could inject arbitrary commands.

Analysis result: "Hardcoded credential 'secret123' detected. Credential passed to system command. High risk of credential exposure and command injection."

Dangerous Patterns Detected

CleanStart's AST analysis engine looks for numerous patterns that have historically led to security vulnerabilities. These patterns are drawn from decades of security research and represent the most common vulnerability classes.

Each of these patterns represents a category of vulnerabilities that AST analysis can detect reliably. For instance, the detection of SQL concatenation involves searching for string concatenation operations that combine user-controllable data with SQL keywords, which would indicate that an attacker might be able to inject arbitrary SQL code. Weak cryptography detection involves identifying calls to cryptographic functions that are known to be vulnerable, such as MD5 or SHA1, which no longer provide adequate collision resistance for security purposes.

Performance: Dependency Intelligence

The analysis capabilities described in this overview depend on access to comprehensive dependency intelligence—a massive graph of package dependencies, versions, and relationships spanning multiple programming language ecosystems. CleanStart maintains a dependency graph containing over 281 million dependency relationships across seven major ecosystems. This graph includes Go modules (238 million packages), the Rust crate registry (16.6 million packages), npm (12.5 million packages), Maven Central (7.2 million packages), PyPI (3.4 million packages), RubyGems (3.1 million packages), and C++ libraries (18.7 thousand packages).

The scale of this dependency graph enables real-time correlation: when a new CVE is published, CleanStart can correlate it against the entire ecosystem within minutes, determining which packages are affected, which applications depend on those packages, and through its four-layer analysis, which applications are genuinely at risk.

This comprehensive dependency intelligence is what enables the four-layer analysis to work at scale. Without this foundational data, the analysis cannot determine which packages are actually used, which functions are called, and ultimately whether a vulnerability is exploitable.

Automated VEX Generation

Rather than requiring manual review and attestation of every vulnerability, CleanStart automatically generates VEX attestations for every image that enters the analysis pipeline. This automation is essential to making the four-layer analysis practical at scale—generating and maintaining vulnerability assessments for hundreds or thousands of images would be prohibitively expensive if done manually.

When you analyze an image using the CleanStart CLI, the system performs the four-layer analysis on every detected CVE and outputs a comprehensive VEX attestation that documents the exploitability status of each vulnerability found.

# Example: 342 CVEs found by scanner clnstrt-cli analyze image:tag --output vex.json # Output (excerpt):# CVE-2024-1234: AFFECTED (directly used, exploitable)# CVE-2024-1235: NOT_AFFECTED (code not present)# CVE-2024-1236: NOT_AFFECTED (code not reachable)# CVE-2024-1237: NOT_AFFECTED (function not called by app)# CVE-2024-1238: UNKNOWN (analysis pending, requires manual review)# ...# Total: 342 CVEs# Affected: 51# Not affected: 287# Unknown: 4

The output categorizes each CVE into one of three status buckets. The "AFFECTED" category contains vulnerabilities that the analysis has determined are genuinely exploitable in the context of the image—these require immediate attention and remediation planning. The "NOT_AFFECTED" category contains vulnerabilities that are present but not exploitable—these can be safely deprioritized. The "UNKNOWN" category contains a small number of vulnerabilities where the analysis framework encountered limitations and cannot make a definitive determination—these may require manual review but typically represent a small fraction of the total.

Integration with Supply Chain Tools

VEX attestations are designed to integrate seamlessly with industry-standard supply chain security tools and frameworks. Rather than being proprietary formats understood only by CleanStart, VEX attestations follow open standards that allow any tool in your security toolchain to understand and act upon the vulnerability exploitability assessments.

SPDX (Software Package Data Exchange)

SPDX is an international standard for communicating software bill of materials data. CleanStart can export a complete SBOM in SPDX format with VEX data embedded, allowing downstream tools to understand not only what packages are present in your image, but whether each package contains exploitable vulnerabilities.

# Export SBOM with VEX embeddedclnstrt-cli sbom image:tag --format spdx --include-vex

CycloneDX

CycloneDX is another widely-used SBOM format that emphasizes supply chain component analysis. CleanStart can export SBOMs in CycloneDX format with exploitability metadata, enriching the SBOM with vulnerability assessment information.

# Export SBOM with VEX metadataclnstrt-cli sbom image:tag --format cyclonedx --include-exploitability

Policy Engine (Open Policy Agent)

Policy-as-code frameworks like Open Policy Agent enable organizations to define security policies and enforce them automatically. VEX data integrates naturally with policy engines, allowing you to define rules that automatically allow or deny deployments based on vulnerability exploitability status. For instance, you might allow deployments of images with "not_affected" or "unknown" CVEs while blocking deployments that contain vulnerabilities marked as "affected."

# Enforce policy: Only "affected" CVEs require remediationallow {  input.vex_status in ["not_affected", "unknown"]}deny {  input.vex_status == "affected"}

This policy-as-code approach enables organizations to move from manual security review processes to automated, deterministic security decision-making based on objective vulnerability exploitability assessments.

Compliance Implications

NIST Supply Chain Security

The National Institute of Standards and Technology's SP 800-53 catalog defines security controls required for federal information systems. Deep code analysis and VEX attestation address several key NIST requirements, enabling organizations to demonstrate compliance with regulatory frameworks that mandate supply chain security.

CleanStart's four-layer analysis meets NIST SP 800-53 requirements by providing comprehensive software bill of materials data (satisfying SBOM requirements), performing vulnerability scanning and analysis at multiple levels (source, binary, runtime, and usage), conducting reachability analysis to distinguish truly exploitable vulnerabilities from false positives, and documenting exploitability status through standardized VEX attestations that auditors can review.

Specifically, it provides a Software Bill of Materials (SBOM), vulnerability scanning and analysis, reachability analysis, and exploitability documentation through VEX attestations.

SLSA Build Integrity

SLSA (Supply chain Levels for Software Artifacts) is a framework for evaluating the integrity of software artifacts and the supply chains that produce them. SLSA defines four levels of supply chain security, with Level 4 representing the highest standard. Deep code analysis contributes meaningfully to achieving SLSA Level 4 by providing provenance information for all dependencies (establishing a clear chain of custody), offering complete supply chain visibility through dependency graphs and call graphs, and enabling artifact verification through VEX attestations that can be signed and verified.

Deep code analysis contributes by providing provenance of all dependencies, complete supply chain visibility, and artifact verification.

Example: Real-World Analysis

To illustrate the practical impact of four-layer analysis, consider a real-world scenario involving a production Python FastAPI application. This application is deployed in a container built from the python-fastapi:3.12 base image, and it imports 203 dependencies across its dependency tree (direct and transitive dependencies). When a comprehensive vulnerability scan is performed, the scanner identifies 156 distinct CVEs that may be present in the image.

At this point, a traditional security assessment would document these 156 CVEs and flag the image as requiring remediation. But when CleanStart's four-layer analysis is applied, the results are dramatically different.

The first layer (source code analysis) confirms that all 156 CVEs do indeed exist in source code. The second layer (binary analysis) determines that 142 of these CVEs are present in the compiled binary—14 are not linked into the binary and therefore cannot possibly be exploited. The third layer (runtime reachability analysis) executes the image with representative workloads and determines that only 89 of these CVEs are in code paths that are actually executed at runtime—53 are in unreachable code paths.

The fourth and most revealing layer (actual usage analysis) examines the FastAPI application code and its usage of imported libraries. This layer determines that only 23 of the CVEs affect code paths that the application actually uses. The remaining 66 CVEs are in library functionality that exists but is never invoked by the application code.

Result: The analysis reveals 23 true vulnerabilities that require attention and remediation planning, alongside 133 false positives that are not exploitable in this specific image, representing an 85% false positive reduction (133 out of 156).

The impact on security team efficiency is substantial. A traditional investigation approach would require the security team to spend 4 hours per CVE investigating each of the 156 reported vulnerabilities, totaling 624 hours of investigation effort. CleanStart's approach reduces the investigation burden to 92 hours (23 vulnerabilities times 4 hours), representing a 6-fold reduction in effort. For an organization managing hundreds of container images, this efficiency gain translates to hundreds of thousands of hours in security engineering savings annually.

Next Steps

To go deeper, read about Dependency Intelligence for understanding how dependencies are tracked, review the Architecture Overview for CleanStart's overall design, build your first image with the Quick Start guide, and explore the Container Security Maturity Model for a structured approach to improving your security posture.

Key Insight

Deep code analysis transforms "we found a CVE" into "we found a CVE and here's whether it actually affects your image."

This distinction is the difference between 85% false positive burden and actionable security intelligence.