Demand-Driven Vulnerability Detection for Cloud Security Posture Management: Removing Human Rule Authoring from the Disclosure-to-Protection Critical Path Prashant Kumar Pathak [email protected]
arXiv:2606.07957v1 [cs.CR] 6 Jun 2026
Preprint. Under review at IEEE Transactions on Cloud Computing.
I. INTRODUCTION
Abstract—Cloud Security Posture Management (CSPM) systems detect known vulnerabilities by maintaining a rule set, distributing it to customers, and evaluating it against periodicallycollected asset inventories. To our knowledge, in publicly documented CSPM architectures, the rule set is environment-agnostic and authored or curated centrally by the vendor; updates to it are batched into release cycles and shipped to customers on a cadence that, depending on the vendor and the complexity of the detection, can range from hours to days. The disclosureto-protection window—the time from a CVE being published in a public catalogue to the customer’s system being capable of detecting affected assets—is therefore bounded by the vendor’s release cadence for simple version-match detections, and by additional human authoring time for richer detections that incorporate configuration predicates beyond the affected-software string. This paper proposes an alternative architecture in which the rule set is not vendor-distributed at all but continuously derived, within the customer’s tenant, from the intersection of public catalogue feeds and the live asset graph. A rule comes into existence when a catalogue entry and an applicable asset are simultaneously present, and goes out of existence when either input ceases to support it. Derivation is bidirectional: new catalogue entries and new assets both trigger it. Derivation incorporates the full structured-field content of catalogue entries, not only the affected-software predicate, producing detections that current automated matching does not generally cover. The live rule set is bounded by environment diversity rather than by catalogue breadth. Prior systems incrementally evaluate a static rule set; we incrementally derive the rule set itself. We present the threat model, the architecture, formal semantics with an equivalence theorem, complexity analysis, a worked example, and an evaluation methodology with experimental design. The contribution is specifically the architectural shift and its latency and resource consequences; rule correctness, alert prioritization, and risks outside structured threat-intelligence catalogues are out of scope and identified as future work.
When a Common Vulnerabilities and Exposures (CVE) entry is published in the National Vulnerability Database, or when a vendor publishes a security advisory, the practical question for a cloud security team is: how long until our detection tooling can identify whether we are affected? In current Cloud Security Posture Management (CSPM) practice, the answer depends on what kind of detection is required, and in both cases the answer is slower than it needs to be. For simple version-match detections, where the rule is essentially “does this asset run the affected software at an affected version,” many commercial CSPMs do automatically consume CVE feeds and produce findings. The latency floor here is not the matching itself but the vendor’s content-update cadence: rules are batched into release cycles, tested, and distributed to customers on a schedule that, depending on the vendor and the severity of the detection, can range from hours for high-severity advisories to days for routine ones. The customer waits not because the matching is hard but because the vendor’s release pipeline is in the way. For richer detections, where the rule incorporates configuration predicates that appear in the CVE structured fields beyond the affected-software string—network exposure conditions, deployment-mode requirements, feature-flag prerequisites— publicly documented CSPM architectures do not, to our knowledge, derive these mechanically. A human detection engineer reads the entry, decides which structured fields matter, and writes a query that joins them against the asset graph. The aggregate elapsed time from CVE publication to deployable rule, in industry-typical workflows, is typically several business days for routine CVEs, and can be longer for less prominent ones. In both cases, the customer is exposed during the window. The vulnerability is publicly disclosed, the affected configurations are visible to attackers consulting the same feeds the defender consults, and the defender’s tooling has, in principle, all the information needed to detect the exposure—but does not yet do so. This paper attacks both cases through one architectural change: the rule set should not be authored or distributed by a vendor at all. It should be a continuously-derived view over two independent inputs the system already has: the public vulnerability catalogue, which the system ingests directly from upstream feeds,
Index Terms—Cloud security, CSPM, vulnerability detection, CVE, demand-driven rule derivation, alert latency, resource efficiency, asset graph.
1
and the live asset graph of the protected environment. A rule comes into existence when a catalogue entry and an applicable asset are simultaneously present in the system. It goes out of existence when either input ceases to support it. The central novelty can be stated in one sentence. Prior systems incrementally evaluate a static rule set; we incrementally derive the rule set itself. The substrate of incremental computation we build on—differential dataflow, incremental Datalog, materialized-view maintenance—is mature and well-understood, and we make no contribution to it. The contribution is the observation that vulnerability detection is naturally a problem of maintaining a rule set as a derived view, not of evaluating a static rule set faster, and the architectural and formal consequences that follow. This change has four specific consequences that distinguish the proposed architecture from current practice:
authored rule from the same source would over-fire. We do not address alert fatigue, prioritization, or analyst workflow. We do not address risks that have no representation in any catalogue (compliance violations, internal-policy rules, novel attack patterns not yet documented in threat intelligence). Each of these is a natural subject of follow-on work that extends the architecture this paper proposes. Section II frames the threat model around the disclosure-toprotection window. Section III describes the current CSPM architecture and identifies precisely where current systems do and do not automate. Section IV introduces the demand-driven architecture, with the central figures. Section V formalizes the architecture as a derived view, states an equivalence theorem between incremental and full re-derivation, and analyzes complexity. Section VI works through a representative example. Section VII states the design choices: when derivation runs, what a catalogue entry is, and how the rule lifecycle is managed. Section VIII presents the evaluation methodology and experimental design. Section IX covers related work. Section X discusses limitations and the future-work program that extends from this paper. Section XI concludes.
1. The vendor-managed rule distribution layer is removed from the disclosure-to-protection path. Rules are derived locally, in the customer’s own system, directly from the public catalogue. The vendor’s release cadence is no longer the latency floor; the upstream feed’s publication time is. 2. Rule derivation is bidirectional. A new catalogue entry triggers derivation against the existing asset graph; a new asset triggers derivation against the existing catalogue. The second direction matters in cloud environments where infrastructure is provisioned continuously: a newly-deployed asset is evaluated against every known vulnerability the moment it appears, not at the next scan cycle, and not only against rules a vendor has previously written for its resource class. 3. Derivation incorporates the full catalogue entry, not only the affected-software predicate. The configuration predicates, exposure conditions, and provenance metadata in the structured fields all participate in the derived rule’s body, producing detections that current automated matching does not cover. 4. The live rule set is bounded by the environment, not by the catalogue. Rules whose applicability predicates do not match any asset in the environment are not instantiated. The rule set scales with the diversity of the environment, not with the breadth of the catalogue.
II. THREAT MODEL The operative variable in cloud breach outcomes is not whether detection capability exists at all but how soon detection capability exists relative to the introduction of exploitation capability. A vulnerability becomes exploitable the moment a public catalogue entry, a proof-of-concept exploit, or an in-the-wild detection appears. From that moment, every additional hour the customer’s tooling lacks the corresponding detection rule is an hour of exposure during which the affected configuration is visible to attackers but not to defenders. The adversary in our model is external and competent: familiar with the publication cadence of major catalogues, capable of weaponizing newly-disclosed CVEs within hours, and aware that customers running standard CSPM tooling will lack corresponding detections for several days. The adversary times exploitation to this window. The customer’s defensive position during the window is approximately equivalent to the position they would occupy with no detection tooling at all for the specific vulnerability in question: the configuration is undetected and the system has no awareness that anything is amiss. The defender’s security goal is therefore to compress the disclosure-to-detection window. Compressing it does not eliminate the underlying vulnerability—the configuration is still vulnerable until patched—but it converts an undetected exposure into a detected one, which is the operative difference between a successful breach and a contained one. This paper’s architectural changes are evaluated against this goal directly: by how much do they reduce the disclosure-to-detection window, and at what resource cost.
The combination produces both faster detection and a smaller operational surface. The latency improvement is the headline: from the days-to-weeks window of human authoring and vendor distribution to a window measured in seconds, bounded by feed propagation and incremental evaluation. The efficiency improvement is the byproduct: rule sets that previously had to be authored conservatively (covering all resource classes a vendor’s customer base might contain) collapse to the rules actually needed by each environment. The contribution is deliberately bounded. We address detection latency and resource cost for vulnerabilities represented in structured threat-intelligence catalogues. We do not address rule correctness beyond what the catalogue’s structured fields admit; derived rules over-fire in exactly the cases where a human-
A. Latency Decomposition The end-to-end latency from a security-relevant cloud event to an alert decomposes into three stages, and it is important to be explicit about which of them the architectural change targets. 2
The first stage is cloud-to-asset-graph ingestion: the time from a real cloud event (a VM provisioned, a security group modified, a software package installed) to the corresponding asset graph delta becoming observable to the CSPM. This stage is bounded by the cloud provider’s event-stream propagation, the ingestion adapter’s polling cadence or event-subscription latency, and any reconciliation logic the adapter applies. It is typically seconds in event-driven adapter designs and longer in pull-based ones. This latency is a property of the cloud-provider integration; it is the same for both architectures we compare, because both consume the same asset graph from the same ingestion pipeline. The second stage is catalogue ingestion: the time from a CVE being published in a public feed to the corresponding catalogue entry becoming observable to the CSPM. This is also a property of feed propagation and is bounded similarly. The current vendordistributed model adds a content-update step here that does not exist in the proposed model. The third stage is rule derivation and evaluation: the time from a catalogue or asset graph delta becoming observable to a finding being emitted for an affected asset. This is the stage the architectural change targets directly. In a rescan-based system this stage costs the rescan-cycle window (configured in minutes to hours). In the proposed architecture this stage costs the perdelta derivation-and-evaluation latency (milliseconds). The total time-to-detection is the sum: δingestion + δderivation + δevaluation . The first term is a shared floor for both architectures. The second and third terms are what we measure and what we reduce. The improvement from days-or-hours-to-detection to ingestion-plus-milliseconds is the substance of the contribution; ingestion itself remains whatever the cloud-provider integration delivers.
feeds directly into each customer’s tenant. Instead, the vendor consumes the feeds centrally, packages the resulting matchers into release artifacts, runs internal QA against representative customer environments, and distributes the artifacts to customers on a release cadence. The cadence varies by vendor and by detection severity, ranging from hours for the most urgent advisories to days for routine ones. The customer’s engine then receives the distributed artifacts, indexes them, and applies them to its asset store. The disclosure-to-protection window for simple version-match detection is therefore bounded by the vendor’s release cadence, not by the technical difficulty of the matching. B. Behavioral and Configurational Rules A second category of rules incorporates structured fields beyond the affected-software predicate. CVE entries frequently include configuration-specific applicability conditions: network exposure requirements (“the affected service must be reachable on the public internet”), deployment-mode requirements (“the daemon must be running with privilege X”), and feature-flag prerequisites (“the affected behavior is enabled only when option Y is configured”). These conditions are present as structured fields in many entries and are present in advisory prose for nearly all entries. Publicly documented systems do not, to our knowledge, derive rules that incorporate these conditions automatically. A human detection engineer reads the entry, identifies which structured fields and which prose-described prerequisites matter, and writes a query in the engine’s query language that joins them against the asset graph. The resulting rule is then tested, packaged, distributed, and deployed through the same vendor-release pipeline as version-match rules. The wall-clock time from catalogue publication to customer engine, for this category, is the sum of human authoring time, internal review and test time, distribution time, and the customer’s local indexing time. It can aggregate to several days for routine CVEs and longer for less urgent ones.
III. CURRENT CSPM ARCHITECTURE A CSPM system in current practice consists of four layers. An ingestion layer pulls cloud-provider configuration data via API calls, supplementing it with event-stream subscriptions where available. An asset store records the resulting configuration as a graph or tabular dataset. A rule engine evaluates a rule set against the asset store. A presentation layer aggregates, ranks, and routes findings. The rule set is the focus of this paper. To engage honestly with the contribution, it is important to distinguish two categories of rules that current systems handle differently.
C. Rule Set Composition Independently of which category of rule is being shipped, the rule set received by each customer is environment-agnostic. The vendor cannot know which resource classes a given customer’s environment contains, so the rule set covers all resource classes the vendor’s customer base might collectively contain. A tenant whose entire workload runs on managed Kubernetes still carries rules for unmanaged virtual machines, on-premises directory services, and discontinued cloud-provider services. The engine indexes them, the scheduler considers them, the audit log records their continued existence, and the content-update pipeline distributes their updates. Figure 1 illustrates the latency consequence by tracing a single CVE through both the current pipeline and the proposed alternative. The top track shows a representative current pipeline: each transition between stages has a human or batch-process boundary, and the aggregate window of exposure can span hours to days depending on detection severity. The bottom track shows the proposed pipeline: each transition is an automatic eventdriven boundary that does not pass through a vendor release, and the aggregate window collapses to seconds.
A. Simple Version-Match Rules For rules of the form “asset X runs software S at a version within affected range [v1 , v2 ],” many current systems do consume CVE feeds automatically and produce findings. A periodic job fetches the latest entries from the National Vulnerability Database, normalizes them, and joins them against the asset inventory. This part of the pipeline is event-driven and operates at the latency of the upstream feed. Where the latency is consumed in this case is not in the matching but in the distribution layer that sits between the catalogue and the customer’s engine. To our knowledge, in publicly documented architectures, commercial CSPMs do not ingest CVE 3
F IG . 1. The disclosure-to-protection window in current and proposed pipelines. The current pipeline introduces human-authoring, content-update-distribution, and scan-cycle stages between catalogue publication and customer alert. The proposed pipeline removes the human and the scan cycle from the critical path; the remaining stages are bounded by feed propagation, automatic rule derivation, and incremental evaluation.
IV. DEMAND-DRIVEN ARCHITECTURE
An entry in the catalogue contains an identifier, a source, an affected-software predicate (typically a Common Platform Enumeration string with version ranges), zero or more configuration predicates that further narrow applicability, severity and provenance metadata, and a publication timestamp. We do not require the catalogue to contain the full prose of advisories or proof-ofconcept exploits; only the structured fields are consumed. This is a deliberate scope decision: structured fields are sufficient for the latency-and-efficiency contribution this paper makes, and the harder problem of synthesizing rules from unstructured advisory text is left to future work.
The architectural proposal of this paper is that the rule set should not be a static input to the system but a derived view over two dynamic inputs: a structured vulnerability catalogue maintained by the operator (and continuously populated from public feeds) and the live asset graph of the specific environment under protection. A rule comes into existence when both a catalogue entry that could affect the environment and an asset that the entry could affect are simultaneously present. The rule goes out of existence when either of those preconditions ceases to hold. Figure 2 shows the architecture. We describe each component in turn.
B. The Live Asset Graph The asset graph is a typed, labeled multigraph of the cloud resources, identities, and relationships currently observable in the protected environment. Nodes correspond to assets (workloads, identities, storage resources, network elements, installed software components, attached configurations). Edges correspond to relationships (assumes, runs, contains, exposes, reaches). Each node and edge carries timestamps that record when the entity exists in the cloud and when the system observed it; the resulting bitemporal structure permits accurate accounting of out-of-order observations and historical reconstruction within a retention window. For the purposes of this paper, the asset graph is the same
A. The Vulnerability Catalogue The catalogue is the system’s representation of the world’s published knowledge about exploitable conditions. It is populated from structured public feeds, of which the dominant examples are the National Vulnerability Database, the Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities list, and the structured security-advisory feeds published by major operating system, cloud-provider, and software-package maintainers. Each feed produces entries with varying field coverage; a feed adapter per source normalizes them into a uniform internal schema. 4
F IG . 2. Demand-driven CSPM architecture. The vulnerability catalogue and the live asset graph are independently maintained inputs. The derivation engine, triggered by deltas on either input, instantiates a rule for each (catalogue entry, applicable-asset class) pair where the applicability predicates are satisfied. The derived rule set is therefore a function of state: it contains exactly the rules that could produce a non-empty result against the environment as it currently exists. The evaluation engine maintains each derived rule’s findings under further asset graph deltas.
primitive used by any modern CSPM. What differs is how the rule set relates to it. In current practice, rules are independent of the graph and evaluated against it. In the proposed architecture, rules are derived from the graph, and only the rules that have join-partners in the graph are instantiated.
filled from the catalogue entry’s structured fields. The rule enters the live rule set. If no asset matches, no rule is instantiated; the catalogue entry continues to exist in the catalogue but produces no engine-resident artifact. When the catalogue acquires a new entry, the derivation engine evaluates the new entry against the asset graph and instantiates rules if applicability holds. When the asset graph acquires a new asset, the derivation engine evaluates the new asset against the catalogue and instantiates rules for any catalogue entries that the new asset would match. When an asset disappears, any rules whose applicability depended solely on that asset are retracted. When a catalogue entry is removed (a rescinded CVE), the rules derived from it are retracted. In every case, derivation is incremental: the engine considers only the affected pairs, not the full Cartesian product.
C. The Derivation Engine The derivation engine is the new component introduced by this paper. Its responsibility is, on every delta to either the catalogue or the asset graph, to recompute which rules should currently exist. For each catalogue entry, the derivation engine checks whether any asset in the current graph matches the entry’s affectedsoftware predicate. If at least one asset matches, the engine instantiates a rule of the form: vulnerable(asset, entry_id) :- runs_software(asset, S), version_in_range(asset, lo, hi), configuration predicates, where the body terms are 5
entry, asset class) pair, not per asset. The rule set at time t is
D. The Live Rule Set The output of the derivation engine is the live rule set: the set of all derived rules currently instantiated. The rule set has the property, by construction, that every rule in it has at least one matching asset partner. The size of the rule set scales with the diversity of the environment, not with the size of the catalogue: a small environment containing few asset types maintains a small live rule set even against a large catalogue. The rule set is itself a derived relation in the system, with the same retraction semantics as any other derived data. Audit queries against the historical rule set — which rules were active at time t, and why — are answered by reconstructing the catalogue state and asset graph state at t within the retention window and re-deriving.
Rt = { r(c, κ) | c ∈ Ct , κ = κ(c), κ ∈ Cls(At ) } where r(c, κ) is the rule derived from catalogue entry c for asset class κ. A rule exists exactly when the catalogue entry’s targeted class is present in the environment; its body is the applicability conjunction π(c), evaluated against members of class κ. This definition makes the central architectural commitment formal: Rt is a function of the two inputs Ct and At , not an independent artifact. The rule set is bounded by |Ct | and, more tightly, by the catalogue entries whose target class is present in the environment—so |Rt | ≤ |{c ∈ Ct : κ(c) ∈ Cls(At )}|. A rule per class, rather than per asset, is what keeps the rule set bounded by environment diversity rather than environment cardinality.
E. The Evaluation Engine Each rule in the live rule set is evaluated incrementally against the asset graph: as the graph evolves, the rule’s findings update under retraction-preserving semantics. The evaluation engine is essentially conventional, with one observation: because the live rule set contains only applicable rules, the evaluation engine never spends work on rules that cannot match. The total evaluation cost scales with the number of derived rules and the rate of asset graph change, neither of which depends on the size of the underlying catalogue.
Definition 3 (Findings). The findings set at time t is the per-asset evaluation of every rule against the assets of its class: Ft = { (a, c) | c ∈ Ct , a ∈ At , r(c, cls(a)) ∈ Rt , App(c, a) }. The two-level structure is deliberate: rules are per class (so the rule set scales with diversity), while findings are per asset (so detection is per-resource). A single rule r(c, κ) produces a finding for each asset of class κ whose attributes satisfy π(c). B. Incremental Derivation The architecture maintains Rt and Ft incrementally under deltas to its inputs. A delta ∆C is a pair of sets (C + , C − ) of inserted and retracted catalogue entries; similarly ∆A = (A+ , A− ) for the asset graph.
V. FORMAL SEMANTICS AND COMPLEXITY We now state the demand-driven derivation formally and analyze its complexity. The formalization serves two purposes. First, it gives a precise definition of what “the rule set is a derived view” means, against which an implementation can be checked. Second, it allows us to state and prove an equivalence between incremental derivation and full re-derivation, which is the property that lets us replace periodic recomputation with continuous incremental maintenance without weakening correctness.
Definition 4 (Incremental Derivation Step). On a catalogue delta ∆C = (C + , C − ), a rule r(c, κ(c)) is added for each c ∈ C + whose class is present (κ(c) ∈ Cls(At )), and removed for each c ∈ C − . On an asset delta ∆A = (A+ , A− ), the addition of an asset a whose class was previously absent instantiates rules r(c, cls(a)) for every c ∈ Ct with κ(c) = cls(a); the removal of the last asset of a class retracts all rules for that class. Findings are updated per affected asset: an asset delta touches only the findings for that asset, and a catalogue delta touches only the findings for assets of the entry’s class.
A. Definitions Let Ct denote the catalogue state at logical time t: the set of catalogue entries currently known to the system. Each entry c ∈ Ct is a tuple c = (id , src, κ, π, µ), where id is a unique identifier, src is the originating feed, κ is the asset class the entry targets (e.g. the affected software identifier), π is a conjunction of applicability predicates over asset attributes (version range, configuration conditions, exposure requirements), and µ is provenance metadata. Let At denote the asset graph state at logical time t: the typed, labeled multigraph of assets currently present in the protected environment. Each asset a ∈ At belongs to an asset class cls(a) (its software identifier) and carries an attribute record and edges to other assets. Let Cls(At ) = { cls(a) | a ∈ At } denote the set of asset classes present in the environment.
This is the precise sense in which derivation is bidirectional and incremental: a catalogue delta touches only the matching class’s assets, and an asset delta touches only the matching class’s catalogue entries—never the full Cartesian product. C. Equivalence Theorem The central correctness property is that incremental derivation produces the same rule set as full re-derivation from scratch.
Definition 1 (Applicability). An entry c is applicable to an asset a, written App(c, a), if and only if κ(c) = cls(a) and every predicate in c’s applicability conjunction π is satisfied by a’s attributes and edges in At .
Theorem 1 (Incremental–Full Equivalence). For every sequence of deltas ∆1 , ∆2 , . . . , ∆n applied to initial inputs (C0 , A0 ), yielding final inputs (Cn , An ), the rule set Rn produced by applying the incremental derivation step to each ∆i in order is equal to the rule set obtained by full re-derivation over (Cn , An ):
Definition 2 (The Rule Set). A rule is derived per (catalogue
Rn = { r(c, κ) | c ∈ Cn , κ = κ(c), κ ∈ Cls(An ) }. 6
Proof sketch. By induction on the number of deltas. The base case (n = 0) holds by definition: R0 is the set of rules r(c, κ(c)) for entries c ∈ C0 whose target class is present in Cls(A0 ), which is exactly the full-derivation result. For the inductive step, assume the equivalence holds at step n − 1. Consider ∆n . There are two cases. If ∆n is a catalogue delta (C + , C − ), then Cn = (Cn−1 \ C − ) ∪ C + and An = An−1 , so Cls(An ) = Cls(An−1 ). The full-derivation rule set at step n is
in the worst case where every catalogue entry’s affected-software predicate has many asset partners. Without indexed joins, the cost is Θ(|C| · |A|) regardless. In practice, this is what current static-rule-set architectures pay on every scan cycle, with |C| replaced by the vendor’s full rule set. Incremental derivation on a catalogue delta. When a new entry c ∈ C + arrives, the engine queries the asset graph index for assets matching c’s applicability predicates. The cost decomposes into a constant-time (or O(log |A|)) index lookup plus a term proportional to the size of the matched join partition. Letting k denote the average selectivity of an applicability predicate (the fraction of assets matching a given catalogue entry):
{ r(c, κ(c)) | c ∈ Cn , κ(c) ∈ Cls(An ) }. This decomposes as {r(c, κ(c)) | c ∈ Cn−1 \ C − , κ(c) ∈ Cls(An )}
Θ(|∆C| · (log |A| + k · |A|)).
∪ {r(c, κ(c)) | c ∈ C + , κ(c) ∈ Cls(An )}. The first set equals Rn−1 \ R− by the inductive hypothesis and the definition of R− . The second set equals R+ by definition. Their union is Rn as produced by the incremental step. The case for an asset delta is symmetric: an asset insertion that introduces a new class adds the rules for that class, and the removal of the last asset of a class retracts them, so Cls(An ) and hence Rn track the incremental updates exactly.
Which term dominates depends on selectivity. For workloads dominated by rare-software entries (where k is very small), the logarithmic term dominates. For workloads with non-trivial k, the linear term dominates and per-delta cost grows with the size of the matched partition, not with the size of the full graph. Incremental derivation on an asset delta. Symmetric, with k ′ denoting the fraction of catalogue entries that target the asset’s software stack:
Proposition 1 (Findings Equivalence). Under Theorem 1, the findings set Fn produced by incrementally maintained derivation is equal to the findings set produced by full re-derivation at step n, provided rule evaluation is itself maintained incrementally under standard retraction-preserving semantics.
Θ(|∆A| · (log |C| + k ′ · |C|)). Comparison. The baseline pays Θ(|C| · |A|) on every periodic recomputation, regardless of how small the incoming change is. The incremental approach pays only for the change, with the cost bounded by the size of the matched join partition rather than by the product of the two full inputs. The practical speedup depends on selectivity: for low-selectivity workloads (most assets are unaffected by most CVEs, the typical operating regime), the gap between k · |A| and |C| · |A| is several orders of magnitude. The crossover at which incremental loses to batch is |∆C| + |∆A| ≈ min(|C|, |A|), a scenario that does not occur in steady-state operation.
The equivalence theorem establishes that the demand-driven architecture is observationally equivalent to a static-rule-set architecture that periodically re-derives its rule set from Cn and An . The contribution of the architecture is not in producing a different rule set; it is in producing the same rule set faster and at lower cost. The theorem is what licenses replacing the periodic re-derivation with continuous incremental maintenance. D. Complexity Analysis We analyze the cost of maintaining Rt in two regimes: full re-derivation (the baseline) and incremental derivation (the proposed approach).
Live rule set size. Because a rule is derived per (entry, asset class) pair rather than per (entry, asset) pair, the size of Rt is bounded by the number of catalogue entries whose target class is present in the environment: |Rt | ≤ |{c ∈ Ct : κ(c) ∈ Cls(At )}| ≤ |C|. In the worst case, where every catalogue entry’s class is present, this is O(|C|) regardless of how many assets populate each class; it never reaches O(|C| · |A|). More tightly, if catalogue entries are distributed across classes and the environment contains d = |Cls(At )| distinct classes, the live rule set is bounded by the entries falling in those d classes. For environments where d is small relative to the catalogue’s class coverage—which describes the typical cloud tenant, since assets fall into a small number of resource classes—the live rule set is substantially smaller than |C|. This is the formal statement of the efficiency claim: rule-set size scales with environment diversity, not with environment cardinality, and is bounded by
Notation. Let |C| and |A| denote the sizes of the catalogue and asset graph respectively. Let |∆C| and |∆A| denote the sizes of incoming deltas. Let k denote the average selectivity of an applicability predicate: the expected fraction of assets matching a given catalogue entry’s applicability condition (typically k ≪ 1 in real environments, since most CVEs affect a small subset of resource types). Let b denote the branching factor on the indexed join: the number of assets sharing the most common key value (e.g., the number of assets running a given software package). Full re-derivation. A from-scratch derivation of Rt requires evaluating App(c, a) for each (c, a) pair. With indexed joins on the affected-software predicate, the cost is Θ(|C| · b) = O(|C| · |A|) 7
The total elapsed time from t0 to first alert is approximately δfeed + δderive + δevaluate . The first term is bounded by feed mechanics and is typically seconds. The second term is bounded by the size of the affected join partition, which is typically a small constant. The third term is similarly bounded. The aggregate is on the order of seconds. The corresponding aggregate in the current architecture, by contrast, is the sum of human-authoring time, content-update distribution time, and scan-cycle latency, which together are days. A second illustration of the architecture’s behavior comes from considering what happens when the environment does not contain assets running W . The catalogue entry arrives, the derivation engine evaluates applicability, the matching join partition is empty, and no rule is instantiated. The environment incurs no detection cost for this CVE because no detection rule exists. If a developer later deploys an asset running W at an affected version, the resulting delta on the asset graph triggers the derivation engine to evaluate the new asset against the catalogue; the existing CVE entry is matched, a rule is instantiated, and the asset is flagged immediately upon appearance.
catalogue breadth only when the environment’s class diversity matches the catalogue’s.
VI. DESIGN CHOICES F IG . 3. A new catalogue entry flows through the system. Each stage is eventtriggered; there is no scan cycle and no human in the loop between catalogue publication and alert emission.
Three design decisions warrant explicit statement. A. Eager Derivation The derivation engine is triggered eagerly: every delta on the catalogue or the asset graph invokes the derivation step immediately. The alternative, lazy derivation, would defer rule instantiation until an explicit evaluation request arrived. Lazy derivation is more conservative of compute in the limit but loses the latency property that motivates this work: if rules are not derived until some later trigger, the window between catalogue ingestion and rule availability is bounded by that trigger, which in practice would have to be approximated by a periodic poll. Eager derivation, in contrast, ensures that the only delay between catalogue publication and rule existence is the time to actually perform the derivation, which is short. The eagerness applies to both directions of the join. A new catalogue entry triggers derivation against the existing asset graph. A new asset triggers derivation against the existing catalogue. Both are handled by the same engine and the same join indexes.
Suppose a CVE entry is published at time t0 in a public feed. It describes a vulnerability in web server software W affecting versions v1 through v2 inclusive. The feed adapter ingests the entry at time t0 + δfeed , where δfeed is bounded by the feed’s polling interval (typically seconds for high-frequency feeds, minutes for slower ones). The entry is normalized into the system’s internal catalogue schema and inserted. The insertion is a delta on the catalogue. The derivation engine, triggered by the delta, evaluates the new entry’s applicability predicates against the asset graph. The applicability predicate decomposes into a join: which assets in the graph have runs_software relationships to software identifier W at a version within [v1 , v2 ]. The join is indexed; the engine identifies the matching asset partition in time proportional to the partition’s size, not the graph’s size. If the partition is non-empty, the engine instantiates a rule for the matching asset class. The rule’s body is constructed from the catalogue entry’s structured fields. The rule enters the live rule set as a derived data item with the same provenance and retention semantics as any other derived data. If the partition is empty, no rule is instantiated; the catalogue entry remains in the catalogue, available to be activated later when an applicable asset eventually appears, but consumes no further engine state in the meantime. If a rule was instantiated, it is now part of the live rule set. The evaluation engine, triggered by the rule’s instantiation delta, evaluates the rule against the asset graph. Because the join arrangements are already maintained, the evaluation reduces to consulting the relevant indexed partition. The rule produces a finding for each matching asset; the findings emit to the alert layer.
B. Catalogue Entry Schema A catalogue entry, as consumed by the derivation engine, is a tuple with the following fields: identifier (the CVE number or equivalent), source (the feed that produced the entry), affectedsoftware predicates (CPE strings or similar, with version ranges), optional configuration predicates (network exposure requirements, feature flags, deployment-mode predicates), severity and provenance metadata, and timestamps. Different feeds populate these fields with different completeness; per-feed adapters normalize. The structured-fields-only choice is deliberate. The hard problem of parsing advisory prose and extracting structured exploitation prerequisites is not in scope for this paper. The contribution of this paper holds even if the structured fields are imperfect: derived rules have the same correctness profile as a rule a human 8
would have written from the same structured fields. Where the structured fields are insufficient to express full exploitation conditions, the derived rule over-fires, exactly as a human-authored rule from the same input would. This is the same precisionrecall tradeoff that current detection-engineering practice makes; our contribution is making it at automation speed rather than at human-review speed.
for the scaling experiments below. B. Workload The primary workload consists of three streams replayed against the prototype. The catalogue is generated synthetically with a Zipf-distributed software population modeling the heavy-tailed distribution of CVE-affected products in real catalogues. The asset graph is generated synthetically with parameterized diversity (fraction of the software universe present). The delta stream models continuous cloud-infrastructure evolution: assets added and removed, CVEs ingested and rescinded. For the measurements reported here, we use |C| = |A| = 104 and a delta stream of 105 events, with diversity 0.30 (a moderate-diversity environment). The scaling experiment in Table 3 sweeps these parameters independently to characterize how per-delta cost grows with input size.
C. Rule Lifecycle Rules in the live rule set come into existence when their applicability conditions begin to hold and go out of existence when those conditions cease to hold. In the bitemporal model, every rule’s existence interval has both a valid time (when the applicability conditions hold in the cloud) and a transaction time (when the system observes the conditions). Audit queries within the retention window reconstruct the historical rule set by querying these timestamps. Rule existence is itself a derived relation. The derivation engine does not treat rules as a special class of object; rules are derived data, like any other data, and participate in the same retraction-preserving incremental computation as the rest of the system. This uniformity is what allows the architecture to be implemented as a single dataflow pipeline rather than as a rule engine paired with a separate rule-maintenance system.
C. Baselines Two baselines are run on the same workload. The first is a staticrescan baseline: the rule set is loaded once from the catalogue at startup, and on each catalogue change the full rule set is re-evaluated against the full asset graph. This emulates the behavior of a content-update-driven CSPM after a release ships. The second is a filter-at-evaluation baseline: the full catalogue is loaded as rules, but each rule is filtered for applicability at evaluation time rather than at derivation time. This isolates the contribution of demand-driven derivation from the contribution of incremental evaluation alone.
VII. EVALUATION Note on scale: The numbers reported below come from a reference single-node Python prototype run at |C| = |A| = 104 with 105 deltas, aggregated across three independent runs with different random seeds. Latency values are reported as mean ± stddev across runs. The architectural property and the complexity behavior are demonstrated at this scale; absolute numbers are gated by Python’s per-operation overhead and would improve in a production implementation. The relative ordering of the architectures, and the scaling trends in Table 3, hold across the seeds we tested.
D. Detection Latency The headline metric is the wall-clock latency from a catalogue or asset graph delta arriving at the engine to a finding being emitted for the affected asset. We instrument both ends of the pipeline and report the distribution of latencies across all findings produced during the workload. We measure post-ingestion latency only: the time the engine itself takes from observing a delta to emitting findings. The cloud-provider-to-asset-graph ingestion stage (Section II) is excluded, because it is a property of the cloud-provider integration and is the same floor for both architectures we compare. The end-to-end time-to-detection that an operator experiences is the sum of ingestion latency and the post-ingestion latency reported here. Table 1 reports the latency distribution for the demand-driven architecture and the two baselines. The demand-driven architecture achieves mean post-ingestion latency four to eight orders of magnitude below the static-rescan baselines. Against the most aggressive rescan we observe (1 minute), the latency reduction the rule engine adds on top of ingestion is approximately 230,000× at the median (0.13 ms vs 30 s). Against the typical 1-hour configuration, the reduction is approximately 14 million×. The total time-to-detection from cloud event to alert is the sum of this engine latency and ingestion latency, which is a shared floor for both architectures. Against the stronger filter-at-evaluation baseline, demand-driven is 6.7× faster at the median (0.13 vs 0.88 ms) and comparable at the tail (p95 0.94 vs 1.47 ms), because it evaluates only the matched join partition rather than scanning the full opposing input on each
The contribution is evaluated against two questions: how much does the demand-driven architecture reduce the disclosureto-protection latency, and how much does it reduce the resource cost of maintaining the rule set. Each question maps to a specific experiment configuration. A. Prototype The reference implementation is a single-node prototype consisting of a catalogue ingester (which polls the NVD JSON feed and the CISA KEV feed), a derivation engine (which implements the incremental derivation step of Section V), an evaluation engine (which runs derived rules against the asset graph), and an instrumented logger that records timestamps and resource counters at each stage. The prototype is implemented in approximately three thousand lines of code and runs on a single workstation. The asset graph for experimental purposes is generated synthetically by a parameterized workload generator: assets are drawn from a configurable distribution of resource classes and software versions, with the distribution and the population size set per experiment. The synthetic generation allows us to vary environment size and diversity independently, which is essential 9
Table 1: End-to-end post-ingestion detection latency on the prototype workload (|C| = |A| = 104 , 105 deltas), aggregated across 3 seeds, reported as mean±stddev. Static-rescan latencies are deterministic functions of the configured rescan interval. The 1-minute rescan is the most aggressive configuration we observe in current practice; the 1-hour and 24-hour rescans are more typical.
than the baseline’s tight inner loop, so a compiled implementation would close more of the gap. Memory is comparable across the continuous approaches; demand-driven’s inverted indexes cost slightly more than the rule-set pruning saves at this scale. F. Scaling To characterize per-delta cost as a function of input size, we sweep two parameters independently. First, holding catalogue size constant, we vary the asset graph size from 102 to 104 assets and measure per-delta cost on catalogue deltas. Second, holding environment size constant, we vary the catalogue size from 102 to 104 entries and measure per-delta cost on asset deltas. Table 3 reports the per-delta cost across the sweep.
Configuration p50 p95 p99 Static-rescan (24h interval) 43,200 s 82,080 s 85,536 s Static-rescan (1h interval) 1,800 s 3,420 s 3,564 s Static-rescan (1m interval) 30 s 57 s 59 s Filter-at-eval 0.88±0.08 ms 1.47±0.14 ms 1.89±0.31 ms Demand-driven (this work) 0.13±0.01 ms 0.94±0.07 ms 1.93±0.89 ms
Table 3: Per-delta cost as a function of input sizes, aggregated across 3 seeds, reported as mean ± stddev. Observed growth remained substantially sub-linear relative to the baseline’s |C| · |A| scaling and was dominated by downstream evaluation over matched assets rather than by the index lookup itself. The per-delta cost grows roughly with the size of the matched join partition, which under Zipf-distributed software in this workload grows close to linearly with input size. A workload with lower-selectivity predicates (rarer software, sparser environments) would compress this growth further toward the logarithmic index-lookup floor.
delta. The bidirectional-triggering experiment below shows the architecture’s clearest advantage. We additionally report the latency decomposition for the demand-driven configuration: feed ingestion, applicability check, rule instantiation, and evaluation, separately. This attribution lets the reduction be assessed against the architectural change rather than against any single engineering optimization. E. Resource Efficiency The second metric is the resource cost of maintaining the rule set: live rule count, memory consumed by indexed arrangements, and CPU consumed per unit of incoming delta. We report each as a function of environment size and asset diversity. Table 2 reports the steady-state resource cost at the target workload size, comparing the demand-driven architecture against the two baselines.
|A| or |C| 102 Catalogue delta cost (ms) 0.002 stddev (ms) 0.0001 Asset delta cost (ms) 0.002 stddev (ms) 0.0003
Table 2: Steady-state resource consumption at |A| = |C| = 104 , after processing 103 deltas, aggregated across 3 seeds, reported as mean ± stddev. “Checks/delta” is the number of applicability evaluations performed per delta—a language-independent measure of the work the architecture must do. The filter-at-evaluation baseline cannot complete 105 deltas in tractable time, so we compare at the smaller delta count. Live rules Static-rescan 13,987±41 Filter-at-eval 10,032±4 Demand-driven 7,753±74 Configuration
103 0.008 0.0003 0.014 0.001
104 0.138 0.053 0.236 0.060
100× growth ∼92× ∼103×
G. Bidirectional Triggering A separate experiment measures the latency from a new asset arriving in the asset graph to the first finding being emitted for that asset, when the relevant catalogue entry was already present. This isolates the bidirectional triggering claim from Section I: new assets are evaluated against the full catalogue immediately on arrival, not at the next periodic scan. As with Table 1, the measurement is post-ingestion: the cloud-event-to-asset-graph latency is the same floor for both architectures and is excluded here. What is reported is the additional latency the rule engine adds on top of ingestion. Table 4 reports this latency, comparing the demand-driven architecture against the static-rescan baseline configured at typical industry intervals.
Mem CPU/103 Checks (MB) deltas (s) /delta 41.2 0.001 — 88.8 0.075 6,920±10 90.9 0.029 541±6
The “Checks/delta” column is the cleanest statement of the architectural property: demand-driven performs 541 applicability evaluations per delta against filter-at-evaluation’s 6,920—a 12.8× reduction in fundamental work, independent of implementation language, and a direct consequence of evaluating only the matched join partition rather than the full opposing input. This work reduction also translates to wall-clock CPU: demanddriven consumes 0.029 s per 103 deltas against filter’s 0.075 s, a 2.6× improvement. The CPU ratio (2.6×) is smaller than the work ratio (12.8×) because demand-driven’s per-operation mix—dictionary lookups and set insertions over the matched partition—carries more Python interpreter overhead per item
H. Scale to 105 We extended the workload to 105 in one dimension while holding the other at 104 . Symmetric 105 ×105 at our diversity setting is not memory-tractable in single-process Python because the steady-state findings set grows to tens of millions. The asymmetric configurations are arguably more interesting: the architecture’s claim is that the live rule set is bounded by environment rather than catalogue, and the large-catalogue-against-moderateenvironment regime is where that claim is sharpest. Table 5 reports both directions. 10
Table 6: Diversity sweep at |C| = |A| = 104 , 103 deltas, uniform catalogue, aggregated across 3 seeds, reported as mean ± stddev.
Table 4: Latency from new-asset arrival in the asset graph to first finding emission for that asset, against a pre-populated catalogue of 104 entries, aggregated across 3 seeds, reported as mean ± stddev. Cloud-provider-to-asset-graph ingestion is excluded (a shared floor for both architectures). The static-rescan baselines are bounded by their configured rescan interval; the demand-driven architecture evaluates the new asset against the full catalogue immediately on arrival. The latency reduction the rule engine adds on top of ingestion is between five and eight orders of magnitude. Configuration Static-rescan baseline (24h interval) Static-rescan baseline (1h interval) Static-rescan baseline (1m interval) Demand-driven (this work)
Diversity 0.05 0.10 0.30 0.50 Filter live rules 10,032±4 10,032±4 10,032±4 10,032±4 Filter CPU (s) 0.54±0.02 0.53±0.01 0.53±0.01 0.53±0.00 Demand live rules 493±19 978±22 2,979±30 5,015±28 Demand CPU (s) 0.35±0.04 0.35±0.01 0.36±0.01 0.37±0.01 Pruning 95.1% 90.3% 70.3% 50.0% CPU ratio 0.65× 0.66× 0.68× 0.70×
Median latency 43,200 s 1,800 s 30 s 0.11±0.01 ms
diversity adds roughly one percentage point of catalogue coverage. CPU drops correspondingly to ∼0.65× of the filter baseline, and the drop is stable across the diversity range tested because demand-driven’s bookkeeping overhead is proportional to liverule count rather than catalogue size. The architectural advantage on CPU manifests when the catalogue distribution is decoupled from the environment distribution—which is the realistic case. The earlier comparison at diversity 0.30 with jointly-Zipf catalogue and assets (Table 2) showed demand-driven losing on CPU because in that workload the active asset classes happened to capture almost all of the catalogue’s weight, hiding the pruning benefit.
Table 5: Demand-driven performance at 105 scale, aggregated across 3 seeds, reported as mean ± stddev. Configuration A is |C| = 105 , |A| = 104 (large catalogue against moderate environment). Configuration B is |C| = 104 , |A| = 105 (moderate catalogue against large environment). Metric A Bulk-load (s) 18.98±0.36 p50 latency (ms) 3.28±0.52 p95 latency (ms) 72.2±1.6 p99 latency (ms) 82.7±2.9 Peak memory (MB) 837±6 Live rules 97,014±230 Findings 4.0M±39k
B 29.45±0.57 0.43±0.10 7.6±0.2 10.6±1.0 829±10 9,692±85 3.9M±45k
J. Threats to Validity The prototype is written in Python and runs single-threaded on a single node; absolute numbers are gated by Python’s peroperation overhead. The architectural property we demonstrate— per-delta cost scales with the work the delta touches rather than with total input size, and inapplicable rules consume no engine state—is independent of implementation language. A production implementation in a compiled language would shift the absolute latencies downward by roughly the Python-vs-compiled overhead ratio (typically one to two orders of magnitude) without changing the relative ordering. We report most numbers at |C| = |A| = 104 because filter-at-evaluation does not complete 105 deltas in tractable time in Python. The 105 asymmetric runs in Table 5 demonstrate that demand-driven retains its architectural properties at that scale; symmetric 105 × 105 at this diversity is memory-bound at tens of millions of findings. The evaluation uses synthetic catalogues and asset graphs. This is a deliberate methodological choice rather than a fallback: production CSPM workloads, even when accessible, do not permit the independent control over diversity and scale that the scaling experiment in Table 3 requires. The synthetic generator uses a Zipf-distributed software population intended to match the heavy-tailed distribution of real CVE-affected products. A natural follow-on is to replay against snapshots of the National Vulnerability Database paired with anonymized production asset graphs, but ablation and scaling experiments require parameterized synthetic workloads in any case. The latency comparison against commercial practice is necessarily architecture-level rather than head-to-head. Controlled benchmarking against commercial CSPMs is infeasible: their implementations are proprietary, their internal pipeline latencies are not externally observable, and their content-update cadences are
Two observations. Per-delta latency at 105 scale is still well below the rescan baselines (3.3 ms vs the 30 s 1-minute rescan = 9,000× reduction; vs 1-hour rescan = 550,000×). And the live-rule fraction is high (97%) for both configurations because the Zipf-distributed workload concentrates catalogue weight on the popular software classes that the diversity-0.30 environment happens to contain. The diversity sweep below addresses this directly. I. Diversity Sweep The architectural claim is that demand-driven prunes catalogue entries targeting software classes with no assets in the environment, so the rule set size and CPU cost should decrease as environment diversity drops. Tables 2 and 5 did not reveal this clearly because the catalogue and asset distributions were jointly Zipf-weighted: the active asset classes were always the top-CVE classes, so even a low-diversity environment captured most of the catalogue’s weight. To isolate the pruning effect, we re-run the workload with the catalogue uniformly distributed across the software universe (modelling realistic CVE coverage that is decoupled from any one tenant’s software mix) and sweep environment diversity from 0.05 to 0.50. The pruning effect is now visible. At diversity 0.05 (a tenant using ∼5% of the software universe), demand-driven maintains only 493 live rules against filter’s 10,032—a 95% reduction. The reduction scales linearly: each percentage point of environment 11
reported through marketing rather than measurement. We therefore compare against an emulated static-rescan baseline that implements the architectural pattern attributed to current systems in the public literature—periodic full re-evaluation against a vendor-distributed rule set—running the same workload as the proposed architecture. The emulated baseline is conservative: it implements rescan dynamics but not the human-authoring or content-distribution steps that would extend real-world latency further. The latency reduction we measure against it is therefore a lower bound on the reduction a real CSPM tenant would observe. The prototype is single-tenant. We believe the architectural property generalizes to multi-tenant deployments where each tenant has its own asset graph and shares a global catalogue, but we do not measure that generalization here.
vulnerability data and network configuration. Our architecture treats the rule set as a continuously-maintained derived view that updates under deltas to either input. Recent cloud-specific extensions [3] inherit the batch orientation and do not address the latency between vulnerability disclosure and rule availability. C. Vulnerability Management and Software Composition Analysis A separate line of tooling, generally called vulnerability management or software composition analysis, scans software inventories for known CVEs by matching CPE strings or packageversion metadata. These tools consume the same feeds the system we propose consumes, and they are event-driven in the sense that they evaluate continuously rather than only on schedule. The difference from our contribution is the rule body and the substrate against which the rule evaluates. Software composition analysis matches against package inventories, which are flat lists of installed software with versions. Our derived rules match against the full cloud asset graph, including not only installed software but configuration state, network exposure, identity relationships, and the transitive structure of the environment. The rule body that emerges from a catalogue entry’s configuration predicates would not type-check against a flat package inventory; it requires the graph-structured asset model that a CSPM maintains.
VIII. RELATED WORK The space of related work falls into four categories, and the position of this paper’s contribution differs in each. A. Current CSPM and CNAPP Practice Commercial and open-source CSPM systems automate CVE-toasset matching for the case where the rule reduces to “software identifier and version range,” as discussed in Section III. To our knowledge, publicly documented architectures in this category do not derive the richer rule body from the other structured fields present in catalogue entries, nor do they eliminate the vendor-managed distribution layer between the catalogue and the customer’s engine. The rule sets they distribute are environmentagnostic and the disclosure-to-protection window is bounded by vendor release cadence. Our contribution differs from current practice in four specific ways, corresponding to the four consequences enumerated in Section I. First, derivation runs in the customer’s tenant directly against public catalogue feeds, with no vendor in the path. Second, derivation is bidirectional: new assets and new catalogue entries both trigger it. Third, derivation incorporates the full structured-field content of catalogue entries, not only the affected-software predicate. Fourth, the live rule set is bounded by the environment rather than by the catalogue. Each of these differences is, individually, an architectural choice rather than a technique invention; the contribution is the combination, applied to vulnerability detection.
D. Incremental Computation Differential dataflow [4] and its descendants in incremental view maintenance [7] provide the underlying technique we use to make derivation and evaluation incremental under deltas. Incremental Datalog engines [5, 6] provide the substrate for stratified rule evaluation. Our contribution is not in this layer; we build on existing incremental-computation techniques and apply them to the problem of demand-driven rule derivation from public vulnerability catalogues against a live asset graph. The recognition that this problem has the structure of an incrementally-maintained view, rather than the structure of a periodic batch scan, is the conceptual move we contribute. The implementation substrate is borrowed. IX. DISCUSSION AND FUTURE WORK The contribution of this paper is bounded to latency and resource efficiency for vulnerability detections derived from structured threat-intelligence catalogues. Several natural extensions follow from this scoping. The most immediate extension is improving the correctness of derived rules. Structured catalogue fields capture the affectedsoftware predicates well but capture exploitation prerequisites unevenly: an advisory may describe a condition in prose that the structured fields do not represent, so derived rules over-fire when that prerequisite does not hold. The same over-firing occurs in human-authored rules from the same source unless the human invests the additional effort of parsing the prose. Closing the gap automatically (language models extracting prerequisites from prose, or grounding ontologies mapping prose terminology to asset attributes) improves precision at additional complexity; the latency benefit of the demand-driven architecture does not
B. Attack-Graph Generation The academic literature on attack-graph generation begins with Phillips and Swiler [1] and continues through MulVAL [2] and its descendants, which build attack graphs from vulnerability databases and network configurations using Datalog-style reasoning. These systems treat the graph and its rules as the output of a batch process. The Datalog formulation in this lineage is similar in spirit to the rule body our derivation engine produces, and we acknowledge the resemblance: a derived rule for a CVE with configuration prerequisites is conceptually a small attack-graph fragment scoped to a single vulnerability. The difference is that the attack-graph literature treats the rule set as the artifact to be computed once from a snapshot of 12
depend on solving this first. A second extension is alert prioritization and analyst feedback. The demand-driven architecture produces alerts as soon as derived rules match, which is the goal, but the alerts arrive without prioritization beyond the catalogue’s published severity. Ranking alerts by environmental context (asset criticality, blast radius, exploitation likelihood) and by analyst-feedback signal is a natural follow-on that addresses alert fatigue without conflicting with the latency contribution of this paper. A third extension is CVE-less risks: compliance posture, internal-policy violations, IAM misconfigurations, and other categories without catalogue representation. These continue to be handled by human-authored rules in any practical deployment of the proposed architecture, which does not preclude them but does not contribute to them either. Whether the demand-driven derivation pattern extends to authored rule sources (compliance frameworks, organizational policies) is a separate research question. A fourth extension is cross-tenant signal: patterns of exploitation observed in one tenant could inform rule prioritization in another, subject to privacy and data-isolation constraints. The architecture is compatible with such an extension but does not require it for the contributions claimed here. We note three limitations of the present work. First, derived rules inherit the correctness profile of the structured catalogue fields they are derived from; the system is no more correct than its inputs. Second, the latency contribution requires that catalogue feeds be reliable; outages or delays in upstream feeds propagate to corresponding delays in derived rules. Third, the architecture assumes a coherent asset graph; environments with substantial blind spots in their asset inventory will detect vulnerabilities only on the visible portion.
ables but does not itself perform. What this paper claims is the architectural shift itself: vulnerability detection is naturally a demand-driven problem, and the current static-distribution model persists for reasons of commercial structure rather than technical necessity. Recognizing the shift opens a program in which faster detection, smaller operational surface, and bidirectional triggering are not improvements layered onto the existing architecture but consequences of choosing a different one. REFERENCES [1] C. Phillips and L. P. Swiler, “A graph-based system for network-vulnerability analysis,” in Proc. New Security Paradigms Workshop, 1998. [2] X. Ou, S. Govindavajhala, and A. W. Appel, “MulVAL: A logic-based network security analyzer,” in Proc. USENIX Security Symposium, 2005. [3] M. Khouzani et al., “Cloud attack graphs: A survey,” Computers & Security, vol. 121, 2022. [4] F. McSherry, D. G. Murray, R. Isaacs, and M. Isard, “Differential dataflow,” in Proc. CIDR, 2013. [5] B. Scholz, H. Jordan, P. Subotić, and T. Westmann, “On fast large-scale program analysis in Datalog,” in Proc. CC, 2016. [6] L. Ryzhyk and M. Budiu, “Differential Datalog,” in Proc. Datalog 2.0 Workshop, 2019. [7] M. Budiu et al., “DBSP: Automatic incremental view maintenance for rich query languages,” Proc. VLDB Endow., vol. 16, no. 7, 2023.
X. CONCLUSION Current Cloud Security Posture Management practice maintains a vendor-distributed rule set, environment-agnostic by construction, evaluated against a periodically-collected asset inventory. For simple version-match detections the matching is automatic but the vendor’s release cadence sets the latency floor at days. For richer detections, human authoring sets the same floor. The resulting rule set consumes resources on rules that cannot apply to the environment under protection. This paper has argued that both inefficiencies are consequences of one architectural choice: distributing rules from a vendor to a customer rather than deriving them in the customer’s tenant from the public catalogue and the live asset graph. The alternative is demand-driven: rules are a continuously-maintained view over two inputs, derived bidirectionally on every delta to either, incorporating the full structured-field content of catalogue entries, and bounded by the environment rather than by the catalogue. The disclosure-to-protection window collapses to milliseconds on top of ingestion because no vendor and no human stand between the upstream feed and the derived rule. The contribution is bounded: it does not address rule correctness beyond what structured inputs admit, alert prioritization, analyst workflow, or risks outside structured threat-intelligence catalogues. Each is natural follow-on work the architecture en13