✓ Human-authored analysis; AI used for formatting and proofreading.
I maintain a configuration verifier, so I have every incentive to argue that signals are never enough. This article tries to resist that incentive.
The other articles in this series argue for formal specification, compound analysis, and deterministic verification. This one argues against them.
As the strongest version of the counterargument I can construct. Because the counterargument is mostly right, for most organizations, most of the time. Understanding where it's right is necessary for understanding where it breaks.
The counterargument: signals — alerts, heuristics, compliance scores, severity ratings, runtime monitoring are sufficient for cloud security. Formal verification of configuration invariants is intellectually interesting and operationally not necessary. Here is the best case for that position.
Argument 1: Most organizations don't have the compound problem
The Capital One breach required three configuration weaknesses to be simultaneously true on the same instance: IMDSv1, public IP, overpermissioned role. That's a compound finding. Detecting it requires reasoning about interactions between configurations, not just configurations individually.
But most organizations that get breached don't get breached through three-way compounds. They get breached through one misconfiguration that was obvious, well-known, and unfixed. A public S3 bucket with customer data. An IAM access key committed to a GitHub repository. A database with default credentials exposed to the internet. Intruder's 2026 Attack Surface Management Index analyzed 3,000 organizations and found that 26% expose MySQL directly to the internet, 16% expose Postgres, and 11% expose RDP. These aren't compound findings. They're single-resource misconfigurations that any scanner catches — including free ones.
For an organization where 26% of databases are internet-facing, investing in compound attack path analysis is solving a problem they don't have yet. They have a simpler problem: close the open database. A per-resource scanner such as Prowler, Checkov, AWS Config, ScoutSuite is the right tool. It's faster to deploy, easier to understand, and catches the misconfigurations that are causing breaches in their environment.
The compound problem is real, but it lives at the end of a maturity curve. You get there after you've closed the open databases, rotated the stale credentials, enabled MFA, and encrypted the volumes. Solving the compound problem before solving the single-resource problem is optimizing the last 20% while the first 80% is on fire.
Argument 2: Signals work when remediation is fast
A finding doesn't need to be precise if you fix it quickly. A false positive costs 30 minutes of investigation. A false negative is caught by the next scan. When your mean-time-to-remediate is measured in hours rather than weeks, the precision of the finding matters less than the speed of the pipeline.
This is the operational reality at organizations with mature DevOps practices. A CI/CD pipeline that runs Checkov on every pull request, blocks deployment on critical findings, and auto-opens a ticket for warnings doesn't need compound analysis. It needs fast, simple checks that produce a clear pass/fail signal. The check "does this Terraform plan create a public S3 bucket?" is binary, evaluable at build time, and blocks the deployment before the misconfiguration reaches production. No snapshot needed. No compound chain needed. No formal verification needed.
In a sufficiently fast remediation loop, the distinction between a signal and a verification becomes operationally invisible. Both produce findings and get fixed. The formal verification is more precise, but precision that doesn't change the remediation action is precision without value.
Shift-left cloud security — where checks run at build time rather than post-deployment is the clearest case for signals over verification. At build time, you're evaluating a plan, not a live environment. The plan is small, self-contained, and deterministic. A CEL predicate evaluating whether a Terraform resource block has publicly_accessible = true is functionally equivalent to a Python function doing the same thing. The formal method adds nothing because the input is already formal (infrastructure-as-code), the evaluation is already deterministic (same plan, same result), and the scope is already bounded (one resource block, not a full environment).
Argument 3: Runtime beats static
GuardDuty doesn't need to know your configuration invariants. It watches API calls, network traffic, and DNS queries, and flags anomalies. When an attacker assumes a role from an unexpected IP, GuardDuty generates a finding. When an EC2 instance communicates with a known malicious domain, GuardDuty generates a finding. When an IAM principal performs reconnaissance (listing buckets, describing instances, enumerating keys), GuardDuty generates a finding.
These are signals, not verifications. They're heuristic, probabilistic, and occasionally wrong. But they have one structural advantage over static configuration analysis: they see the attack, not just the precondition. A configuration verifier tells you the attack is possible. Runtime monitoring tells you the attack is happening.
For incident response, the runtime signal is strictly more useful. "This role was assumed from an IP in a country where you have no employees" is actionable in a way that "this role's trust policy allows cross-account assumption" is not. The first triggers an investigation. The second triggers a review that might happen next sprint.
CloudTrail, GuardDuty, VPC Flow Logs, Security Hub, and SIEM platforms comprise a mature runtime signal ecosystem for AWS. This ecosystem doesn't need formal specifications. It needs good detection rules, reasonable baselines, and competent analysts. Many organizations that have invested in runtime monitoring have a better operational security posture than organizations that have invested in static analysis. Because runtime monitoring catches the thing that's happening right now, while static analysis catches the thing that might happen eventually.
Argument 4: The compliance framework is the specification
CIS Benchmarks, SOC 2 controls, PCI-DSS requirements, HIPAA safeguards, NIST 800-53 controls — these are specifications. They were written by committees of security experts. They've been refined over years of audits and incident retrospectives. They represent professional consensus on what matters.
A Prowler check that maps to CIS AWS Foundations Benchmark v3.0 control 2.1.1 isn't an ad hoc signal. It's a check against a specification that was debated, revised, published, and adopted by thousands of organizations. The specification isn't expressed in CEL or Datalog. It's expressed in English, translated into Python, and mapped to a control number that an auditor recognizes. But it's a specification nonetheless.
The argument that "the industry has no specifications" conflates "no formal machine-evaluated specifications" with "no specifications." The specifications exist. They're in the compliance frameworks. They're not compound or formally verified. They don't detect interaction effects. They define what "correct" means for the 572 checks they cover, and that definition has institutional authority that no independent tool can replicate.
A passing CIS audit is not as precise as a compound invariant evaluation. But it's a lot better than nothing. And "better than nothing" is the relevant comparison for most organizations, because most organizations don't have any specification at all — formal or otherwise.
Argument 5: Perfect is the enemy of deployed
A tool that requires understanding compound chains, CEL predicates, and Datalog reachability has a higher adoption barrier than a tool that runs with pip install prowler && prowler. The tool that gets deployed and runs every week is infinitely more valuable than the tool that sits in a backlog because nobody had time to set up the collector.
Tool adoption at scale is hard. Uber's engineering leadership talked openly about AI adoption being slower than expected. That's at a company with 3,000 engineers and a dedicated developer platform team. Deploying a new tool with new concepts and new workflows is an organizational challenge, not a technical one. The organizational challenge doesn't care about the precision of the tool.
Security engineering is a resource-constrained field. The median security team at a midmarket company has fewer people than the engineering team has services. Asking that team to deploy a collector, manage snapshots, understand compound chains, interpret distance-one classifications, and maintain a control catalog on top of their existing workload is asking them to adopt a more precise tool at the cost of doing less with the tools they already have.
Sometimes the right answer is: run the scanner you have, fix what it finds, and worry about compound analysis after the simple problems are solved.
Argument 6: Security teams aren't formal methods practitioners
CEL, Datalog, Z3, SMT solvers, satisfiability, semantic equivalence — these are terms from formal methods and programming language theory. They are powerful. But unfamiliar to most security practitioners.
A Prowler check written in Python is readable by any security engineer who knows Python. The check says what it does, the code is auditable, and a contributor can write a new check by copying an existing one and modifying the conditions. The barrier to contribution is "know Python and understand the AWS API."
A Stave control written in CEL predicates evaluated by a compound chain engine backed by Datalog reachability is harder to read, harder to write, and harder to debug. When a finding is wrong, diagnosing whether the error is in the CEL predicate, the observation data, the chain definition, the Datalog rule, or the implicit dependency resolver requires understanding multiple interacting systems. The barrier to contribution is higher.
This matters because security tooling is only as good as the community that maintains it. A tool that a hundred people can contribute to will cover more ground than a tool that ten people can contribute to, even if the second tool is more precise per-check. Breadth of contribution trades against depth of verification, and for an open-source project, breadth often wins.
Where the arguments break
These six arguments are the strongest case I can make for signals over verification. I believe all of them are correct for the organizations and scenarios they describe.
Here is where they stop being correct.
The compound problem is rare until it's catastrophic. The 80/20 argument says most breaches come from simple misconfigurations. This is true by count and false by impact. Capital One's simple misconfigurations — IMDSv1, public IP, overpermissioned role — were each individually low-severity. The compound was critical. The breach cost $300 million. The distinction between "most breaches by count" and "worst breaches by impact" is the distinction between the 80% problem and the 20% problem. If your risk model weighs count, signals win. If your risk model weighs impact, verification wins.
Fast remediation assumes fast detection. The argument that precision doesn't matter if you fix quickly requires knowing there's something to fix. A compound finding that no scanner reports can't enter the remediation pipeline. You can't fix what you can't see, and you can't see what your tool can't compose. The remediation-speed argument works for findings that exist in your tooling. It fails for findings that exist in reality but not in your tooling.
Runtime monitoring detects exploitation, not exposure. GuardDuty fires when the role is assumed from an unusual IP. It doesn't fire when the configuration that allows the role to be assumed from any IP is created. Runtime monitoring is reactive. It tells you the attack is happening. Configuration verification is predictive. It tells you the attack is possible before it happens. Both are needed. The argument that runtime beats static conflates "more useful during an incident" with "more useful overall." Before the incident, static analysis is the only signal.
Compliance frameworks are specifications of what committees agreed on. They are not specifications of what attackers exploit. The CIS benchmark for AWS does not include a compound check for the Capital One pattern. It checks IMDSv2 in one control and S3 bucket policies in another and IAM role permissions in a third. A fully CIS-compliant environment can have the Capital One chain active, because the framework doesn't check the compound. The compliance specification is a specification of consensus, not a specification of security.
Deployment ease trades against capability. This is true. A tool that's deployed beats a tool that isn't. If the choice is between deploy the simple tool or deploy nothing — the simple tool wins. The question is whether the choice is binary, or whether it's a sequence. For most organizations, it's a sequence: deploy the simple tool, fix the simple problems, then deploy the precise tool for the compound problems. The argument against formal verification is strongest when it argues "not now." It's weakest when it argues "not ever."
When signals really are enough
Signals are enough when: your environment is small enough that a human can hold the full topology in their head. Your remediation loop is fast enough that false negatives are caught by the next cycle. Your risk profile doesn't include scenarios where individually acceptable configurations combine into critical paths. Your primary compliance obligation is met by per-resource framework checks. Your team's bandwidth is fully consumed by single-resource findings and won't free up for compound analysis until those are resolved.
For many organizations, most of the time, these conditions hold. Signals are enough. The per-resource scanner works. The compliance framework provides the specification. The runtime monitoring catches the incidents. And the compound attack path that exists in the configuration but has never been exploited is a risk that can wait.
The conditions stop holding when: the environment grows complex enough that no human holds the full topology. When the interaction between configurations becomes the primary attack surface. When the stakes of a single compound breach exceed the cumulative cost of all the single-resource findings combined. When a customer, an acquirer, or an insurer asks "can you prove your security posture?" and "we run Prowler weekly" isn't a sufficient answer.
That boundary exists. Knowing which side of it you're on is the decision that matters. Everything else — tools, methods, formal versus informal, signals versus verification — follows from that.
Top comments (0)