💻 computer science

SBOM-Based Container Deployment Risk Assessment under Incomplete Runtime Observations

This paper proposes an adaptive SBOM-based method for assessing container deployment risks under incomplete runtime observations by integrating multiple evidence sources to classify vulnerability applicability and prioritize inspection costs, achieving improved decision completion rates and reduced hold times compared to baseline approaches.

Original authors: Byeongchan Park, Sun-Jip Kim

Published 2026-10-19

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Byeongchan Park, Sun-Jip Kim

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

In the modern digital world, software is rarely built from scratch. Instead, developers assemble applications like a master chef assembling a complex dish from pre-made ingredients: libraries, frameworks, and tools created by others. To keep track of these ingredients, a new standard called a Software Bill of Materials, or SBOM, acts as a detailed inventory list. This list is crucial for security because if a known flaw is discovered in one of the ingredients, the SBOM helps identify which applications contain it. However, knowing an ingredient is present is only half the battle. A flaw in a library only becomes a danger if the software actually uses that specific part of the code while it is running. If the code sits dormant, never called upon by the program, the flaw is harmless. The challenge for security teams is that they cannot always watch the software run perfectly; sometimes the monitoring tools miss events, or the test scenarios do not cover every possible way the software might be used. This leaves a gap where a team might not know if a flaw is dangerous or safe, forcing them to either block a necessary update or risk a breach.

Researchers Byeongchan Park and Sun-Jip Kim addressed this uncertainty by creating a new method for deciding whether to deploy a software container, which is a self-contained package of an application and its ingredients. Their approach treats the lack of perfect information not as a reason to guess, but as a reason to pause and gather more specific evidence. They built a system that combines the inventory list with static analysis, which examines the code structure, and runtime observations, which watch the software in action. Crucially, the system recognizes that just because a dangerous function was not seen during a test, it does not mean the function is safe to ignore. Instead of forcing a "yes" or "no" answer when the evidence is thin, the system classifies the risk as confirmed dangerous, confirmed safe within a specific scope, or unresolved. When a risk is unresolved, the system does not simply approve the deployment; it places the request on hold.

The core of their innovation is a strategy for spending a limited amount of time and computing power to resolve these uncertainties. Imagine a security team with a strict deadline to decide on a software update. They have a list of potential flaws, but checking every single one thoroughly takes too long. The researchers' method acts as a smart guide, deciding which checks to run first based on how much they are likely to help reach a final decision. It prioritizes actions that are most likely to turn an "unresolved" risk into a clear "safe" or "dangerous" verdict, rather than just running checks in a random order or by severity alone. The system continuously re-evaluates its choices as new data comes in, ensuring that every second of the inspection budget is spent on the check that matters most for the final decision.

To test this approach, the researchers constructed a realistic simulation using one hundred different software deployment scenarios derived from forty specific vulnerability cases in Java projects. They created a ground truth for ninety of these cases, meaning they knew exactly which deployments were safe and which were dangerous, independent of their new system. They then subjected the system to various forms of incomplete information, such as missing parts of the test workload, shortened observation windows, and lost data events. They compared their adaptive method against several other strategies, including a simple list-based check and a method that prioritizes inspections based on the cost to resolve them. The results showed that their method was more effective at reaching a correct final decision within the time limit. Under a budget of one hundred and twenty seconds, the new method achieved a balanced correct decision rate of seventy-eight point four percent, compared to seventy-six point three percent for the next best method.

Perhaps more importantly, the new method reduced the number of cases that remained stuck in an unresolved "hold" state. While other methods left twenty-two percent of decisions undecided, the proposed method reduced this to twenty percent. This means that more software updates could proceed safely without unnecessary delays, while still maintaining a very low rate of error. The system incorrectly approved dangerous deployments only one point two percent of the time and incorrectly blocked safe deployments only two percent of the time. These numbers suggest that by carefully ordering which checks to perform and by refusing to make a decision when evidence is insufficient, security teams can navigate the fog of incomplete data more effectively. The study confirms that a structured, evidence-based approach can distinguish between a flaw that is truly harmless and one that is simply unobserved, allowing organizations to move forward with confidence even when they cannot see every single detail of their software's behavior.

Technical Summary: SBOM-Based Container Deployment Risk Assessment under Incomplete Runtime Observations

1. Problem Definition

The paper addresses the challenge of assessing container deployment risks using Software Bills of Materials (SBOMs) when runtime observations are incomplete. While SBOMs provide structured component inventories, the mere presence of a vulnerable component does not confirm its exploitability in a specific deployment context. Conversely, the absence of observed vulnerable behavior in runtime traces does not definitively prove non-applicability, as relevant execution paths (e.g., administrative operations, exception handling) may be omitted, or events may be lost due to collector failures.

Current approaches often struggle to distinguish between:

Confirmed Applicability: Evidence proving a vulnerability is exploitable.
Confirmed Non-Applicability: Evidence proving a vulnerability is excluded within a specific scope (e.g., a patch is present, or a mandatory trigger condition is missing).
Unresolved Applicability: Insufficient evidence to determine either state.

The core problem is managing deployment decisions (ALLOW, BLOCK, HOLD) under resource constraints (inspection budgets) and incomplete data, ensuring that "unresolved" states are not incorrectly converted into "ALLOW" decisions due to missing evidence.

2. Methodology

The proposed method integrates SBOM data, static analysis, runtime observations, and deployment configurations into an iterative assessment framework.

2.1 Evidence Model and State Classification

The system maintains an evidence ledger bound to specific image digests, configurations, and collection conditions. For each candidate vulnerability, the assessment determines one of three states:

$A$ (Applicable): Valid evidence confirms the vulnerability can be triggered.
$X$ (Excluded): Valid evidence confirms non-applicability within the declared scope (e.g., verified patch, confirmed absence of trigger conditions).
$U$ (Unresolved): Evidence is insufficient, conflicting, or the observation conditions (workload, collector health) are invalid.

Crucially, the model enforces that missing execution events alone do not justify state $X$ . Non-applicability requires a verifiable basis, such as a confirmed fix or the exclusion of a mandatory triggering condition.

2.2 Decision Policy

Deployment decisions are mapped from the vulnerability states:

BLOCK: Issued if any policy-relevant vulnerability is in state $A$ .
ALLOW: Issued only if all policy-relevant vulnerabilities are in state $X$ and all assessment prerequisites (e.g., inventory consistency) are met.
HOLD: Issued if any finding is in state $U$ or if prerequisites are unmet. Budget exhaustion or missing observations do not automatically convert a HOLD to an ALLOW.

2.3 Budget-Constrained Adaptive Inspection

When a request is in a HOLD state, the system selects additional inspections (e.g., targeted execution, patch verification, static analysis refinement) to resolve uncertainty. The selection strategy is budget-aware and decision-oriented:

Cost Estimation: Uses historical median costs for similar actions.
Outcome Prediction: Estimates the probability of an action leading to a terminal decision (ALLOW or BLOCK) or resolving specific obligations.
Selection Heuristic: The method uses a lexicographic ordering to select the next action ( $a^*$ $a^{*}$ ):
- Primary: Maximize expected decision completion per unit cost.
- Secondary: Maximize expected resolution of unresolved obligations per unit cost.
- Tertiary: Minimize estimated cost.

This approach prioritizes inspections that are most likely to yield a definitive deployment decision within the remaining time budget.

3. Key Contributions

The paper outlines three primary contributions:

An Evidence Model for Incomplete Observations: A formal model distinguishing confirmed applicability, scope-bounded non-applicability, and unresolved states, with explicit conditions for evidence validity and reassessment.
A Budget-Aware Deployment Decision Procedure: A procedure that links inspection selection to ALLOW, BLOCK, and HOLD policies, directing limited resources toward evidence necessary to resolve deployment decisions rather than merely maximizing coverage.
An Evaluation Framework: A framework assessing both security outcomes (decision correctness) and operational costs (latency, overhead) under various forms of incomplete observation (workload omission, shortened windows, event loss).

4. Experimental Results

The method was evaluated using 100 deployment instances derived from 40 vulnerability cases across 20 Java projects (Vul4J dataset). Experiments compared the proposed method against baselines including SBOM-based gating, evidence-only assessment, fixed-order, random-order, severity-cost, and resolution-cost inspection strategies.

Key Findings (at a 120s budget):

Balanced Correct Decision Rate: The proposed method achieved 78.4%, outperforming the next best baseline (resolution-cost inspection at 76.3%) by 2.1 percentage points.
HOLD Rate: Reduced from 22.0% (baseline) to 20.0%, indicating fewer deployments were left unresolved.
Efficiency: Mean budget-penalized completion time decreased from 55.9s to 54.1s.
Error Rates: The false-allow rate was 1.2% and the false-block rate was 2.0%.
Robustness: Under increased workload omission (0% to 75%), the proposed method maintained a higher correct decision rate (66.0%) compared to the baseline (59.7%), though the HOLD rate increased for both.

5. Significance and Claims

The paper claims that adaptive inspection ordering can improve the rate of completed deployment decisions under incomplete observation conditions while preserving the integrity of unresolved states when evidence is insufficient.

The authors emphasize that their approach:

Prevents risky deployments by refusing to treat "absence of evidence" as "evidence of absence."
Avoids unnecessary service delays by distinguishing between confirmed risks and unresolved uncertainties that require further inspection.
Optimizes limited inspection budgets by prioritizing actions that contribute directly to reaching a terminal decision (ALLOW or BLOCK) rather than simply maximizing vulnerability discovery.

The study concludes that while the method improves decision completion and reduces latency under the evaluated conditions, its effectiveness relies on the accuracy of the underlying evidence and the validity of the cost/outcome estimates used for selection. The authors note that the scope is limited to known dependency vulnerabilities in Java applications within Linux containers, and future work is needed to generalize these findings to other ecosystems and long-running workloads.