✓ Human-authored analysis; AI used for formatting and proofreading.
"Our CSPM secures the cloud." "Our SIEM detects threats." "Our CNAPP protects cloud-native applications." "Our AI flags risks."
Each claim is wrong by a specific, testable standard. There's a discipline from TRIZ that forces you to state what a tool DOES to its DIRECT OBJECT. No indirect effects. No consumer perceptions. No metaphors. Just: what does the tool DO to what it TOUCHES?
Applied to six cloud security tool categories, the discipline reveals a structural pattern: every tool produces signals. None produces decisions. Operators must currently infer decisions from accumulated signals. Breaches live in that inference gap.
The discipline: state the direct action
A function is the intended direct physical action of the tool on the object. State it as Tool—Verb—Object. Reject anything that describes an indirect effect, a consumer perception, or a non-physical concept.
The classic example: a ship propeller. "Propeller drives ship" is wrong. The propeller doesn't touch the ship. "Propeller pushes water" is correct. The propeller directly acts on the water; the water moves the ship. If you optimize for "driving the ship" you optimize the wrong thing. If you optimize for "pushing water" you optimize the right thing.
Cloud security descriptions fail the same test:
| Common description (wrong) | Why wrong | Correct formulation |
|---|---|---|
| "CSPM secures the cloud posture" | "Secures" is consumer-perceived | CSPM rule engine matches API responses against rule database |
| "SIEM detects security incidents" | "Detects" + "incident" are indirect | SIEM correlation engine matches log events against detection signatures |
| "CNAPP protects cloud-native apps" | "Protects" is consumer-perceived | CNAPP aggregation engine collects and deduplicates findings from multiple scanners |
| "SOAR automates incident response" | "Automates" is meta | SOAR playbook executor runs scripted action sequences against detected events |
| "Checkov scans IaC for misconfigurations" | "Scans" + "misconfiguration" are technical-system labels | IaC scanner tests parsed HCL/JSON against rule patterns |
| "ML detects anomalies" | "Anomaly" is non-physical | ML model scores events against a learned baseline distribution |
Six categories. Six correct formulations. Now the structural pattern becomes visible.
Six tools, six verbs
| Tool | Primary function (correct) | Verb |
|---|---|---|
| CSPM | Rule engine matches API responses against rule database | Matches |
| CNAPP | Aggregation engine collects and deduplicates findings from scanners | Aggregates |
| SIEM | Correlation engine matches log events against signatures | Matches |
| SOAR | Playbook executor runs scripted sequences against detections | Runs |
| IaC scanner | Parser + matcher tests parsed IaC against rule patterns | Tests |
| ML detection | Trained model scores events against learned baseline | Scores |
Six verbs: matches, aggregates, matches, runs, tests, scores.
Every verb is signal-producing. Each tool takes input and produces a signal — a finding, an alert, a score, a playbook result. None of the verbs is decision-producing. None produces a verdict that a machine can act on without human interpretation.
The cloud security industry has built six categories of signal-producing tools and zero categories of decision-producing tools.
The absent-function inventory
For each tool, what's missing — functions that should exist but don't:
CSPM: matches, but only after deployment
✓ Adequate: Matches API responses against rules (within rule coverage)
✗ Absent: Pre-deployment matching (CSPM runs AFTER state exists in the cloud)
✗ Absent: Machine-verifiable deterministic verdict (findings require human interpretation)
✗ Absent: Auditable rule basis (rule libraries are often vendor-proprietary)
✗ Harmful: Alert fatigue (match volume exceeds operator capacity)
✗ Harmful: Severity-score inflation (vendors exaggerate to justify visibility)
CNAPP: aggregates, but amplifies the noise
✓ Adequate: Collects findings from multiple scanners
✗ Absent: Pre-deployment prevention (inherits CSPM's post-hoc limitation)
✗ Absent: Deterministic verdict (aggregated findings are MORE noisy, not less)
✗ Harmful: Amplifies alert volume (aggregation increases noise without increasing signal)
✗ Harmful: Hides scanner-specific quality (which scanner produced which finding?)
SIEM: matches events, but only after they happen
✓ Adequate: Matches log events against signatures (within signature coverage)
✗ Absent: Prevention (SIEM matches AFTER events occur; cannot prevent)
✗ Absent: Machine-verifiable verdict per asset (produces alerts, not asset-level verdicts)
✗ Harmful: Alert fatigue at production scale
✗ Harmful: Cost growth (log-volume billing incentivizes reducing collection)
SOAR: runs playbooks, but amplifies upstream errors
✓ Adequate: Runs playbooks (executor logic is mature)
✗ Absent: Input quality control (cannot determine if the detection is correct)
✗ Absent: Prevention (runs AFTER a detection; unsafe state already exists)
✗ Harmful: Amplifies false positives (false detection → automated false response)
✗ Harmful: False sense of automation (operators stop reviewing; detection failures become silent)
IaC scanner: tests source, but not deployed state
✓ Adequate: Tests parsed IaC against rules (within rule coverage)
✗ Absent: Post-deployment evaluation (tests source; not deployed state)
✗ Absent: Identity and environment context (source file lacks the live account state
it deploys into — a Terraform module is safe in isolation but unsafe when
composed with an existing FullAccess role it attaches to)
✗ Absent: Detection of console/CLI changes (manual changes bypass IaC entirely)
✗ Absent: Drift detection (source vs live state divergence is invisible)
✗ Harmful: False security from "clean IaC" (clean source ≠ clean deployed state)
ML detection: scores events, but can't explain or enumerate
✓ Adequate: Scores events against baseline (inference is mechanical and fast)
✗ Absent: Auditable verdict basis (high score doesn't explain WHY)
✗ Absent: Determinism (same event scores differently after retraining)
✗ Absent: Catalog-style enumeration (model cannot be inspected for "what counts as unsafe")
✗ Harmful: Probabilistic verdicts for binary decisions (score thresholds are arbitrary)
✗ Harmful: Model drift produces silent failure (stops catching things without anyone noticing)
The cross-tool pattern
Line up the absent functions across all six tools:
| Absent function | CSPM | CNAPP | SIEM | SOAR | IaC | ML |
|---|---|---|---|---|---|---|
| Pre-deployment evaluation | ✗ | ✗ | ✗ | ✗ | ✓* | ✗ |
| Deterministic verdict | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Auditable rule basis | ✗ | ✗ | ~ | ~ | ✓ | ✗ |
| Catalog-style enumeration | ~ | ~ | ✗ | ✗ | ✓ | ✗ |
| Deployed-state evaluation | ✓ | ✓ | ✓ | ~ | ✗ | ✓ |
| Snapshot-based reasoning | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
*IaC scanners are pre-deployment but source-only. They test the declared intent, not the actual state that will exist after apply. A source-only check cannot account for identity and environment context. The Terraform plan says "attach this policy to this role." Whether the resultant state is safe depends on what permissions that role already has, what other policies are attached, and what SCPs constrain the account — none of which exist in the source file. The snapshot (planned state composed with live state) is the only valid object for a pre-deployment security decision.
The pattern: no tool provides all six functions. Most tools provide one or two. The combination of all six tools still leaves gaps. Because the gaps are structural, not coverage-based. Adding a seventh tool that also produces signals doesn't fill the decision gap.
The most striking column: deterministic verdict is absent in all six categories. No tool in the cloud security market produces a deterministic, machine-verifiable, per-asset verdict that a pipeline can act on without human interpretation.
The second most striking row: snapshot-based reasoning is absent in all six. Every tool operates on streams, events, findings, or source code — not on coherent point-in-time snapshots of actual cloud state.
The harmful-function pattern
Line up the harmful functions across all six tools:
| Harmful function | Tools producing it |
|---|---|
| Alert/finding volume exceeds operator capacity | CSPM, CNAPP, SIEM |
| Severity-score inflation | CSPM, CNAPP, ML |
| Vendor lock-in by rule/signature format | CSPM, CNAPP, SIEM |
| Amplification of upstream errors | SOAR, CNAPP |
| False security from clean source | IaC scanners |
| Model drift / silent failure | ML |
| Cost growth with scale | SIEM |
The harmful pattern compounds: CSPM produces inflated-severity findings → CNAPP aggregates them (amplifying volume) → SIEM correlates them (adding more alerts) → SOAR runs playbooks against the accumulated noise (amplifying false positives). Each tool's harmful function feeds the next tool's harmful function. The aggregate is worse than any individual tool's harmful contribution.
The complete picture: existing tools vs the missing function
Combine the absent-useful inventory and the harmful inventory into one view. The rows are the properties the problem requires. The columns are every tool category — including the missing one:
| Required property | CSPM | CNAPP | SIEM | SOAR | IaC Scanner | ML Detection | Configuration Verifier |
|---|---|---|---|---|---|---|---|
| Pre-deployment evaluation | ✗ Post-deploy | ✗ Post-deploy | ✗ Post-event | ✗ Post-detection | ⚠️ Source only | ✗ Post-event | ✅ Planned + deployed snapshots |
| Deterministic verdict | ✗ Findings | ✗ Aggregated findings | ✗ Alerts | ✗ Playbook results | ✗ Findings | ✗ Scores | ✅ COMPLIANT / NON_COMPLIANT per asset |
| Auditable rule basis | ✗ Proprietary | ✗ Proprietary | ⚠️ Signatures visible | ⚠️ Playbooks visible | ✅ Open rules | ✗ Model opaque | ✅ Open YAML catalog, every control readable |
| Catalog-style enumeration | ⚠️ Rules exist but vendor-locked | ⚠️ Inherited | ✗ Signatures ≠ invariants | ✗ No catalog | ✅ Rules enumerate | ✗ Model can't enumerate | ✅ 2,949 controls, each traceable to documented failure |
| Deployed-state evaluation | ✅ Queries live APIs | ✅ Inherits CSPM | ✅ Reads live events | ⚠️ Acts on detections | ✗ Source only | ✅ Reads live events | ✅ Snapshots of actual cloud state |
| Snapshot-based reasoning | ✗ Stream/API polling | ✗ Stream/API polling | ✗ Event stream | ✗ Event-driven | ✗ Source files | ✗ Event stream | ✅ Coherent point-in-time snapshots |
| Compound cross-asset reasoning | ✗ Per-resource rules | ⚠️ Heuristic correlation | ⚠️ Event correlation | ✗ Per-playbook | ✗ Per-resource rules | ⚠️ Behavioral patterns | ✅ Compound chains across configuration graph |
| Machine-consumable output | ⚠️ API but interpretation needed | ⚠️ API but noisy | ⚠️ Alerts need triage | ⚠️ Actions need approval | ✅ Exit codes | ✗ Scores need thresholding | ✅ Exit code 0/3, pipeline acts directly |
| Primary function verb | Matches | Aggregates | Matches | Runs | Tests | Scores | Evaluates |
| Output type | Signal | Signal | Signal | Signal | Signal | Signal | Verdict |
Read the table column by column. Every existing category has gaps (✗) in the rows that matter most. Read the last column: the Configuration Verifier fills every gap. Because the function analysis of existing tools diagnosed what was missing, and the missing function was designed to fill the diagnosis.
Read the bottom two rows. Six tools with six different verbs — matches, aggregates, matches, runs, tests, scores — all producing signals. One tool with a different verb — evaluates — producing verdicts. The verb difference is the category difference.
The most revealing row: deterministic verdict. Six ✗ marks. Every existing tool produces something that requires human interpretation before a machine can act on it. The Configuration Verifier produces a verdict a pipeline reads as an exit code. No interpretation, triage or threshold. Binary.
The diagnosis: signals vs decisions
The structural diagnosis from the function analysis:
What existing tools produce: SIGNALS
- findings for human interpretation
- alerts for human triage
- scores for human thresholding
- playbook results for human verification
What the problem requires: DECISIONS
- deterministic per-asset verdicts
- machine-readable pass/fail
- auditable reasoning per verdict
- pre-deployment evaluation against enumerated forbidden states
The gap between signals and decisions is the gap between the existing toolchain and the problem it claims to solve. No amount of better signals closes the gap. Because signals and decisions are different categories. A faster alert is still an alert. A smarter score is still a score. A better finding is still a finding. None is a verdict.
The gap requires a tool with a different primary function:
Existing PF verbs: matches, aggregates, matches, runs, tests, scores
(all signal-producing)
Missing PF verb: EVALUATES — produces a deterministic categorical verdict per asset
by applying an enumerated catalog of forbidden states
to a snapshot of actual cloud state
(decision-producing)
The missing verb is qualitatively different from the existing verbs. It's not a better version of matching or scoring. It's a different action that produces a different output (verdict vs signal) from a different input (snapshot vs stream) using a different substrate (enumerated catalog vs learned baseline).
The design brief
The function analysis produces the brief. The brief:
A tool whose primary function fills the absent-useful inventory must:
1. Take snapshots as its object — Coherent point-in-time captures of actual cloud state.
2. Apply a catalog of forbidden states — An enumerated, human-authored, auditable specification of what unsafe means.
3. Produce a verdict — A deterministic, categorical, per-asset decision: compliant or not.
4. Operate pre-deployment — Evaluate proposed state before it reaches the cloud.
5. Be deterministic — Same inputs, same verdict, every time.
6. Be auditable — the catalog is external, readable, and independently verifiable. An auditor can read the full enforcement scope without accessing vendor internals.
Six properties. Each is the complement of a specific absent-useful function in the cross-tool inventory. Together they describe a tool with the primary function: the verdict engine evaluates a snapshot of cloud state against a catalog of forbidden states, producing a deterministic per-asset verdict.
That primary function doesn't exist in any of the six existing categories. It's a different verb (evaluates), operating on a different object (snapshot), using a different substrate (catalog), producing a different output (verdict). The function analysis tells us the gap is structural. The tool that fills it is a new category, not a better version of an existing one.
The diagnostic for your own toolstack
Apply the same discipline to your tools:
1. For each tool, state the primary function in Tool—Verb—Object form. Reject non-physical vocabulary. What does the tool do to what it touches?
2. Classify each function. Adequate useful (works), inadequate useful (undershoots), absent useful (should exist, doesn't), harmful (works against you).
3. Look at the absent-useful column across all tools. The pattern of what's missing across the toolstack is the structural gap.
4. Look at the harmful column across all tools. Do the harmful functions compound? Does one tool's harmful output feed the next tool's harmful input?
5. State the missing primary function. What verb, operating on what object, producing what output, would fill the absent-useful inventory?
The answer to step 5 is the design brief for what your toolstack needs next. Not "a better version of tool X". A tool with a different primary function that fills the gaps the existing tools collectively leave.
Every cloud security tool works. Each tool's primary function is adequate within its coverage. The diagnosis is that they all produce signals where the problem demands decisions. The gap is structural. Filling it requires a different verb.
The missing primary function — the verdict engine evaluates a snapshot against a catalog of forbidden states, producing a deterministic per-asset verdict — is implemented in Stave, an open-source cloud configuration verifier. The verb the industry doesn't have: evaluates. The output the industry doesn't produce: verdicts. The input the industry doesn't use: snapshots. Try the missing function: bash examples/demo-ai-security/run.sh
Top comments (0)