SBOM Graphs for Attack Chain Prediction and Workload Identity for Continuous Compliance

Introduction

Signing proves provenance but not safety, and the dependency graph is the structural amplifier of risk as shown in the companion article on attack vectors and keyless signing. This article moves from who produced the software to what is in it, and to how compliance can be enforced after deployment. The two problems sound different but share one root cause: static, point-in-time checks are misaligned with how software behaves.

Most current supply chain analysis treats each CVE as an independent record to be scored and triaged [1]. Yet real-world incidents show that cascaded attack chains, where multiple vulnerabilities interact across components, are a recurring and more dangerous failure mode [1]. In parallel, continuous compliance processes typically run vulnerability assessment only inside the CI/CD pipeline, so they stop protecting the workload the moment it is deployed and a new vulnerability is disclosed [2].

This article examines two peer-reviewed answers to those two problems: an SBOM-graph learning pipeline for attack chain prediction, and a zero-trust architecture that provisions automated workload identities and isolates workloads that fail a minimum vulnerability posture.

This article is educational and not legal advice.

The Shortcoming of Single-CVE Thinking

The starting premise of the SBOM graph work is that per-CVE analysis is useful for triage but fundamentally misaligned with how attacks actually happen [1]. Static scanners such as Snyk and Trivy are effective at enumerating vulnerable components, but they report per-component CVE lists and do not surface cross-component chains [1]. A vulnerability that looks low severity in isolation can become critical when composed through the dependency structure.

The motivating example is ProxyLogon, where four Microsoft Exchange vulnerabilities were chained into a pre-authentication path that led to persistent remote control of enterprise email servers [1]. Each of the four CVEs was individually known; what mattered was their interaction. The paper draws the consequence explicitly: shift from a score-each-CVE philosophy to one that learns interaction patterns constrained by the dependency graph [1].

The empirical context supports this concern. SBOM generation and maintenance remain difficult in realistic environments, and the choice of generation and analysis tool can materially change downstream vulnerability findings, increasing both false positives and false negatives depending on ecosystem and configuration [1]. So the pipeline feeding any higher-order reasoning is noisy and variable before reasoning even begins.

SBOMs as Heterogeneous Graphs

The proposed alternative represents a vulnerability-enriched CycloneDX SBOM as a heterogeneous graph [1]. Three node types carry the structure. Component nodes are the software packages or SBOM dependencies. CVE nodes are known vulnerabilities documented in the OSV database entries. CWE nodes are weakness types from the Common Weakness Enumeration database. Typed edges connect them: DEPENDS_ON between components from SBOM dependency relations, HAS_VULNERABILITY from components to CVEs from the scanner, and HAS_CWE from CVEs to CWEs, which in the current prototype is supported by the schema but not yet implemented [1].

The pipeline builds the SBOM in CycloneDX format using Syft and enriches components with vulnerability information using Grype, backed by the Open Source Vulnerabilities (OSV) database [1]. Node features stay lightweight and interpretable: component nodes carry CVSS aggregates, direct-versus-transitive dependency metadata, degree statistics, and license indicators; CVE nodes encode severity score and temporal metadata [1].

The point of the graph is not decoration. The work is explicitly framed as a new research direction: supply chain security analysis should treat scanner outputs as a dependency-constrained evidence graph rather than a flat list of vulnerabilities [1].

Learning Over the Graph: Feasibility and Evidence That Structure Matters

The graph representation is tested through two modular learning stages [1].

The first stage is a feasibility check. A two-layer Heterogeneous Graph Attention Network (HGAT), with two attention heads, hidden dimension 64, and dropout 0.2, learns to classify whether a component is associated with at least one known CVE, the has-any-CVE label [1]. This is deliberately not a vulnerability-discovery task. It is a mechanism to test whether the dependency structure carries a learnable signal beyond local node metadata, through a targeted ablation [1].

The results, on 200 real-world CycloneDX SBOMs for Python projects from the public Wild SBOMs dataset with a 70-15-15 train, validation, and test split, are [1]:

The ablation zeroes the dependency edges at inference time without retraining. Recall collapses to zero, meaning the model stops finding any vulnerable component when the dependency structure is removed [1]. The paper notes that the still-high accuracy under ablation is consistent with class imbalance, where predicting the majority class scores well on accuracy but badly on recall and F1, so recall and F1 are the informative indicators [1]. The signal is relational: the graph structure is what carries the vulnerability information.

Predicting Attack Chains as Link Prediction

Cascaded chains are scarcer than isolated CVEs, so training a model to predict full multi-step chains directly is data-limited. The work reframes cascade discovery as link prediction over CVE pairs [1]. Given two CVEs, the task is to estimate whether they are plausibly co-exploited in a chained scenario. High-scoring links are then composed into multi-step candidate chains for analyst triage.

The training set is a seed corpus of 35 documented chains, 27 from vulnerability disclosures and 8 from incident reports, with chain lengths from 2 to 4 CVEs (median 2, mean 2.51) [1]. Within-chain CVE pairs are positive examples; negatives are sampled at a 2:1 ratio from pairs not observed in the same chain, a deliberate compromise between class balance and aggressive oversampling [1].

The predictor is a lightweight five-layer MLP consuming a 22-dimensional feature vector per CVE pair: 9 per-CVE features from National Vulnerability Database (NVD) metadata, plus 4 interaction features such as CVSS difference, CVSS product, year gap, and a both-exploited indicator [1]. The architecture is 22-64-32-16-1 neurons with dropout 0.3, Adam at learning rate 10^{-3}, binary cross-entropy loss, up to 50 epochs, and early stopping on validation ROC-AUC [1].

The cascade predictor achieves a ROC-AUC of 0.93 on the seed set [1]. The authors apply their own caveat: ROC-AUC can be misleading under class imbalance, and the result demonstrates the model can distinguish metadata patterns of co-exploited pairs from random pairs, not that it can predict novel undocumented chains. Pair-level splitting, where the same CVE appears in train and test through different pairings, can inflate apparent generalization, which is why chain-level and temporal splits are planned next [1].

The honest boundary matters. This is a feasibility study and a proposed research direction, with the two models operating on disjoint CVE populations and not yet connected end to end [1]. What it establishes is that the dependency structure is learnable, and that scarcer chain documentation is enough to train a usable co-exploitation prior.

The Compliance Gap After Deployment

The second problem is enforcement timing. Continuous compliance processes often perform vulnerability assessment to prevent compliance breaches during the CI/CD pipeline, but they do not extend beyond the pipeline and so ignore incident response when dynamic aspects change, such as a newly disclosed vulnerability [2].

The two Gama papers address this with the same architectural core, refined across two years. The 2024 paper builds on SPIRE, a selective identity provider, and integrates response to compliance violations monitored by OWASP Dependency Track, showing the approach adds no significant latency and does not hinder operational or development efforts [2]. The 2026 paper extends the same design with risk indicators and a grace period mechanism, and evaluates performance at a scale that maps to a production recommendation [3].

The motivation is grounded in the same incident record as Part 1: a 742 percent increase in supply chain attacks between 2019 and 2021, and over 245,000 malicious open source packages discovered in 2022 alone, more than doubling the total of all previous years combined [3].

Zero Trust as Post-Deployment Enforcement

The core design principle is zero trust: never trust, always verify [3]. The idea directly opposes the assumption that a product is trustworthy because it left some trusted boundary [3].

The architecture gives every workload an identity through SPIRE workload attestation, and continuously checks that the workload conforms to a minimum vulnerability posture [3]. A custom plugin reacts to compliance violations driven by dynamic aspects exposed by OWASP Dependency Track, which monitors software components and their dependencies for vulnerabilities and provides a REST API to automate its use [3]. When a workload falls below the minimum posture, the workload is isolated. This isolation presents the fundamental trade-off this line of work is explicit about: exploitation prevention versus application availability, which matters most for critical use cases [2].

The post-deployment focus is the differentiator. Intervention is not a one-time pipeline gate; it is enacted when a new vulnerability appears after the software is running, which is exactly when per-pipeline compliance becomes silent [3].

Risk Indicators and Grace Periods

The 2026 refinement makes the security-availability trade-off configurable rather than binary. The approach introduces risk indicators derived from vulnerability scores and workload criticality, and a grace period mechanism that defers enforcement of newly identified vulnerabilities based on workload criticality [3].

The gradient works as follows. A newly discovered CVE triggers Dependency Track analysis through the REST API [3]. Instead of isolating every affected workload immediately, the plugin grants a grace period before enforcement, with rules driven by CVSS and EPSS-style scoring and by how critical the workload is [3]. Non-critical workloads can keep running through the grace period, which supports availability without compromising long-term security, because enforcement still arrives once the period expires [3].

The design is explicit that this is a judgement with a cost. Applying the same grace period rules to all workloads is not optimal, so criticality is a first-class input rather than an afterthought [3]. This mirrors the general principle of the series: enforce not uniformly, but proportionally to what is being protected.

Performance and Operational Feasibility

The enforcement machinery is only usable if it does not break the systems it protects. The 2026 evaluation measured both resource use and latency [3].

Dependency Track, in a production compliance environment, has a recommended allocation of 16 GiB of memory and 4 CPU cores [3]. The evaluation confirmed that added resource usage reliably remains within that envelope, so the integration does not force organisations to double their monitoring footprint [3].

Latency is reported against the attestation cadence. The plugin adds less than 6 seconds of latency to the attestation process, which is insignificant given the default attestation frequency of approximately once every 30 minutes, or twice per hour [3]. Checking for new vulnerabilities frequently is a recommended practice, and at this cadence the added six seconds is a rounding error relative to the interval [3].

The 2024 paper reached the same conclusion with the earlier design: the only overhead imposed by integrating Dependency Track is the latency of REST API communications during the attestation process, which the evaluation found not to be significant [2].

Implementing Graph-Aware Analysis and Continuous Enforcement in Practice

Neither framework requires a green-field rebuild if it is introduced as an evidence layer rather than a gate replacement. The research prototypes are bounded in ways that actually help to scope a production pilot [1][3].

For the graph pipeline, start where the evidence is strongest. Generate CycloneDX SBOMs in CI with Syft and enrich them with Grype against OSV, then normalise the output to the heterogeneous schema of component, CVE, and CWE nodes with typed edges for DEPENDS_ON and HAS_VULNERABILITY, leaving HAS_CWE as a schema extension until your data supports it [1]. Persist the graph in an existing graph or search store alongside the flat SBOM so current scanners such as Snyk and Trivy continue to run while the graph is used for secondary reasoning [1]. Pilot on Python services first because the 200-SBOM evaluation was Python-only from the Wild SBOMs dataset, and explicitly track where tool choice changes downstream findings by comparing two generators and two scanners on the same build before you trust any downstream classifier [1]. The has-any-CVE HGAT with two layers, two heads, hidden dimension 64 and dropout 0.2 is a diagnostic probe, not a detector [1]. The source paper uses edge-masking only as a one-off feasibility ablation on its own trained model and a 200-SBOM Python-only dataset, with edges zeroed at inference without retraining, not as a general operational technique [1]. As an author-suggested analogy, not a validated procedure endorsed by the source, a team could run a similar sanity check on its own graph-triage pipeline, for example comparing rankings with and without dependency edges, to sense-check whether the graph is adding signal. That heuristic is untested beyond the research context and should not be mistaken for an established method. For chain prediction, treat the 22-feature MLP with ROC-AUC 0.93 as a co-exploitation prior over CVE pairs with 2:1 negative sampling, and require chain-level and temporal splits before any production ranking, since pair-level splitting can inflate generalisation as the authors themselves flag [1].

For continuous posture enforcement, reuse the SPIRE and Dependency Track architecture rather than inventing new attestation. Provision every workload an identity through SPIRE workload attestation and drive the posture check from Dependency Track monitoring of software components and their dependencies via its REST API [2][3]. Isolate workloads that fall below the minimum posture and treat the fundamental trade-off as availability versus prevention, which is most sensitive for critical workloads [2]. Configure grace periods and risk indicators as policy, not as code constants, with rules driven by CVSS, EPSS-style probability, and workload criticality so that critical workloads receive a shorter or zero grace period and non-critical workloads can keep running boundedly through the window [3]. The 2026 evaluation used a 16 GiB and 4 vCPU envelope for Dependency Track and added less than six seconds to an attestation that runs twice per hour, which is a practical baseline for capacity planning rather than a guarantee for other stacks [3]. Previous work found the only overhead from the integration is REST API latency during attestation, which supports placing this in existing re-attestation intervals rather than adding a new control loop [2].

A pragmatic rollout sequence is to enforce graph-aware triage in advisory review first, then enforce continuous posture in non-production with log-backed audit of isolation decisions, and only then move the same policy to production admission with the grace period and criticality matrix as the tuning interface.

So What: Two Frameworks and What They Enable Next

This article establishes two complementary layers of what SBOMs can do once they stop being static PDFs.

The graph layer changes how SBOMs are read. Instead of a flat list of independent CVEs, the SBOM becomes a heterogeneous graph in which dependency structure is the carrier of risk, and cascaded chains become learnable rather than accidental [1]. The ablation result, where removing dependency edges collapses recall to zero, is the cleanest statement of that thesis [1].

The enforcement layer changes when compliance happens. Identity-provisioned workloads are continuously re-verified after deployment, with isolation as the backstop and grace periods and risk indicators as the tuning knobs [3]. The measurable cost, less than six seconds at a twice-per-hour cadence, makes the enforcement posture operationally defensible [3].

Together with the signing foundations covered previously, the picture is now three capabilities: cryptographic provenance for artifacts, graph-aware reasoning over what the artifacts contain, and continuous identity-based verification of where they run. The companion article on LLM and agentic systems examines what happens to all three when the artifact is a model rather than a package.

Conclusion

Static checks fail in two specific ways, and this part documented a published answer to each. Single-CVE scoring misses cascaded attack chains that the dependency graph makes possible, so the evidence graph approach makes those chains predictable [1]. Pipeline-time compliance stops at deployment, so the zero-trust architecture moves verification onto running workloads, isolates failures of posture, and prices the trade-off between availability and security with grace periods and risk scoring [3].

Both answers are early-stage: the graph pipeline is explicit about being a feasibility study, and the enforcement design is scoped to the trade-offs its authors name. But both move the field in the same direction, away from inventories and gates and toward continuous, structured, and relational reasoning about the supply chain.

Frequently Asked Questions

Why does single-CVE thinking fail to capture real supply chain risk?

The evidence graph view treats dependency relationships as the carrier of risk, so a single vulnerability is understood through the attack chains it can contribute to. The ProxyLogon chain in the Baird and Moin study shows how four Microsoft Exchange vulnerabilities were chained into a pre-authentication path that cascaded across components [1]. The ablation result makes the point measurable: removing the dependency edges collapses recall on has-any-CVE prediction to zero, which means the structure of the graph is doing the predictive work, not the individual component inventories [1].

What is the difference between an SBOM and an SBOM graph?

An SBOM is a flat nested inventory of components with identity and version data. An SBOM graph converts that inventory into a heterogeneous graph in which components, dependencies, and vulnerabilities are typed nodes that can carry multiple relationship kinds. The graph formulation is what allows attack chains to be predicted as link prediction over the heterogeneous graph, which is the concrete contribution of the Baird and Moin approach [1].

How does continuous compliance differ from pipeline-time compliance?

Pipeline-time compliance checks an artifact once at build and then stops, which leaves the deployed workload inside the gap the moment the runtime state drifts. Continuous compliance places the identity-based verification onto the running workload itself, using SPIRE to issue and refresh workload identity so that posture can be rechecked after deployment [2]. The Gama 2026 extension adds grace periods and risk indicators so that a non-conforming workload is given a bounded time window or a criticality-based tolerance instead of an immediate binary decision [3].

Can continuous compliance be operated without unacceptable latency?

The measured enforcement architecture re-verified identity and rechecked posture on a twice-per-hour cadence within a dependency check pipeline running on a 16 GiB and 4 vCPU envelope, with per-attestation latency under six seconds [3]. The figures describe the authors experimental context, so the claim here is bounded: the demonstrated envelope is operationally plausible, not a guarantee for other identity providers or monitoring tools.

What role do risk indicators play in a zero-trust compliance policy?

Risk indicators stop the policy from being a single blunt switch. A never-trust-always-verify architecture is still a decision procedure, and grace periods plus criticality scoring turn that procedure into a graded response rather than an all-or-nothing block [3]. This is what keeps continuous compliance deployable in production, because it prices the trade-off between availability and security instead of pretending it does not exist.

Technical Appendix