API-Risk & Scenario Engine

• API-Risk and Scenario Engine is a programmatic platform that integrates automated graph-based risk modeling, semantic verification, and policy-driven governance for managing API and dependency risks.
• It employs Execution Path Dominance (EPD) with LLM-based semantic slicing to quantify operational blast radius and reduce false positives in complex software supply chains.
• The engine features programmable ‘As Code’ policy enforcement with REST/gRPC APIs, enabling dynamic, scenario-driven risk control and seamless integration with development pipelines.

API-Risk and Scenario Engine

An API-Risk and Scenario Engine is a programmatic platform that combines automated graph-based software supply chain risk modeling, semantic verification, and policy-driven governance for API and dependency risk management. Such engines operationalize alert suppression, granular scenario-driven access control, and real-time scenario notification or interdiction, responding to the evolving needs of complex organizational software and services environments. Advanced systems implement these concepts via property graphs, code property graph slicing, LLM semantic checks, and programmable “As Code” policy layers, as exemplified by the Deptex platform (Ruckman-Utting et al., 30 Apr 2026).

1. Execution Path Dominance: Core Risk Quantification Framework

The backbone of an API-Risk and Scenario Engine is the Execution Path Dominance (EPD) methodology, as implemented in Deptex. The API/system is modeled as a typed property graph,

$G = (V, E, \tau_V, \tau_E, \mathcal{A}),$

where vertices $V$ correspond to assets (e.g., APIs), components, and organizational constructs, and edges $E$ encode logical relations such as depends_on and affects. Nodes and edges are type-annotated; attributes such as CVSS, exposure, and criticality are embedded in $\mathcal{A}$.

Upon receipt of a vulnerability signal $s$ (e.g., CVE-20XX-1234), the engine locates affected components and computes not just raw reachability, but the asset-specific “operational blast radius”—the set of exploit paths that are semantically relevant for attack surface in production. To this end, the procedure is:

• Structural slicing: For each entry point $e\in E_0$ (e.g., public HTTP handler), generate the set of code/control/data-flow paths $\mathcal{P}(s,e)$ to the vulnerable sink. This reveals but typically over-approximates all attack vectors.
• LLM semantic slicing: Each path is further inspected by an LLM, returning a numeric entry-weight $W_{\text{entry}}(e)\in[0,1]$ and a boolean is_sanitized(p), denoting effective exploitability. Sanitized paths are pruned.
• Geometric decay score: The full EPD for path $p$ from $e$ is

$V$0

where $V$1 is path length and $V$2 is the attenuation factor (default 0.85).

The asset blast radius is maximized over all entry-point/path pairs:

$V$3

To obtain organizational risk, EPD is composed with a contribution function $V$4 and aggregated across units/assets.

This fusion of CPG path enumeration and LLM-based semantic triage enables both precision (filtering out false-positives via sanitation analysis) and operational context (entry weights), addressing alert fatigue endemic to traditional SCA (Ruckman-Utting et al., 30 Apr 2026).

2. Programmable Governance and Policy-As-Code

Deptex’s governance and scenario enforcement engine is built around a JavaScript-based “As Code” policy sandbox. This programmable layer exposes the property graph, EPD scores, asset metadata, and current organizational context to user-defined policy scripts, which are invoked during key events:

• Pull-Request-as-Code (PR): Triggered on SCM PR events (e.g., dependency update proposals).
• Policy-as-Code: Invoked on SBOM ingestion or new vulnerability signals.
• Status/Notifications-as-Code: Background or event-driven triggers for notifications or integration (e.g., Jira, PagerDuty).

The policy engine loads .policy.js/.yaml files from a Git-backed store, compiles to byte-code, and executes under a managed context. Policy scripts can block, warn, allow, or escalate PRs depending on asset tier, EPD score, and other runtime factors. For example, tier-1 “PaymentGateway” assets may require legal approval for new dependencies, while PRs with EPD exceeding 0.7 for any vulnerability are automatically denied with tailored rationales (Ruckman-Utting et al., 30 Apr 2026).

Deptex exposes a REST and gRPC API including endpoints for policy evaluation, SBOM ingestion, EPD scoring, and third-party integration.

3. End-to-End Scenario Flow: Ingestion, Risk, and Enforcement

A typical scenario-based workflow is as follows:

1. SBOM Ingestion: The client submits a software bill of materials via $V$5 containing components and entry points for a given asset.
2. Vulnerability Signal Handling: On new CVE/event, $V$6 attaches vulnerability-to-component edges in the property graph.
3. EPD Computation:

$V$7 yields quantified, context-specific blast radius via slicing and LLM check.

1. Policy Enforcement on PR: A PR triggers $V$8 which inspects proposed dependency changes, known vulnerabilities, and EPD scores in the context of organizational policy, responding with allow, warn, or deny decisions and optional escalations.
2. Scenario-Based Notifications: Custom Notifier policies dispatch alerts or open tickets, for example, paging on high-EPD vulnerabilities in payment assets, or filing low-priority Jira tickets for low-impact findings.

This flow replaces traditional untargeted CVE scanning with proactive and efficiency-oriented governance, ensuring only semantically significant attack paths trigger high-severity alerts or process blockages (Ruckman-Utting et al., 30 Apr 2026).

4. API Design and Integration Interfaces

The API-Risk and Scenario Engine exposes a comprehensive set of programmatic endpoints supporting full automation and enterprise integration. Core endpoints include:

Endpoint	Function	Typical Payload/Response
POST /api/v1/graph/ingestSBOM	Ingest SBOM and map to graph	Asset info, components, entry points
POST /api/v1/signals	Register vulnerability signals	Signal ID, affected component
GET /api/v1/epd/score	Query EPD score per asset/signature	Query: signalId, assetId
POST /api/v1/policy/evaluatePullRequest	PR risk evaluation/enforcement	PR metadata, dependency changes
POST /api/v1/integrations/{system}	Notify or integrate with 3rd party systems	System-specific payload

Policy-as-code, REST/gRPC, and the event/batch/notification model accommodate integration with development pipelines, security orchestration, asset management, and SIEMs.

5. Programmable Scenario-Based Governance: Example Policies and Use Cases

The programmable policy environment supports complex, scenario-driven risk controls. Canonical cases include:

• Tiered asset governance: Critical assets may be subject to stricter dependency or PR gating rules. PRs on non-critical assets may allow higher EPD, triggering only warnings.
• Dynamic vulnerability thresholds: Blocking, warning, or allowing actions based on EPD (e.g., deny if EPD>0.7, warn if EPD>0.3). These thresholds are configurable per asset or scenario.
• Scenario-based notification routing: High-urgency triggers (e.g., EPD>0.5 on payment assets) can directly notify real-time escalation channels (PagerDuty), while non-critical findings divert to issue/backlog flow.
• Custom asset tiers and tag-based controls: Policies may incorporate arbitrary asset classifications, regulatory scope, and cross-system integrations for legal/security compliance.

Policy authoring is facilitated via JavaScript modules that leverage the context interface, e.g.,

$V$9

and scenario-driven escalation code such as:

$E$0 (Ruckman-Utting et al., 30 Apr 2026).

6. Implications and Organizational Impact

By modeling software supply chain risk as an emergent, context-dependent property—rather than as an intrinsic risk of each component—the API-Risk and Scenario Engine allows organizations to minimize alert fatigue, prioritize true operational threats, and align enforcement with business expectations and legal mandates. Integration with SBOMs and direct linkages between graph-based vulnerability propagation, LLM-checked semantic validity, and programmable policy achieves a high degree of automation while conforming to custom governance regimes.

The ability to escalate or suppress findings based on scenario relevance, asset criticality, and runtime context supports efficient risk appetite calibration and operational alignment, as evidenced by the shift from reactive CVE scanning to governed, scenario-based API risk management (Ruckman-Utting et al., 30 Apr 2026).

7. Limitations and Future Directions

The EPD-centered approach presumes sufficient code coverage for CPG slicing and reliable LLM semantic parsing. False negatives may arise if critical code paths are missed or LLMs misclassify sanitization. Policy authoring requires careful calibration to prevent under- or over-blocking in dynamic software environments. Ongoing extension areas include deeper integration with asset management workflows, automated policy tuning using risk telemetry, and expansion to emerging software supply chain standards (e.g., extended SBOM schemas, vulnerability exchange APIs).

The Deptex implementation constitutes a reference for organization-centric, programmable, and scenario-aware API-risk governance. Future work may focus on extending the scenario engine to cloud-native and heterogeneous runtime environments and on enhancing explainability or auto-remediation pathways (Ruckman-Utting et al., 30 Apr 2026).