✓ Human-authored analysis; AI used for formatting and proofreading.

You run a security scanner on your AWS environment. It finds 47 issues. The leaders hear: "our infrastructure has 47 things wrong with it." This is the problem with bug-finding tools. Every finding is bad news.

What Amazon learned from a bank

A finance company could not understand their own IAM policies. The policies were too complex to reason about manually.

Amazon team said: "We're formalizing the semantics of the policy language. We can prove what your policies allow and don't allow. Mathematically."

The bank increased their workload and their spending. Because AWS proved properties.

The asymmetry

There are two different things a security tool can tell you:

Bug finding: "We found 47 issues in your environment."

The scanners CSPM, CNAPP, Prowler, Scout Suite do it. They check your configuration against a list of known-bad patterns. Each finding is a problem. The report is a list of problems. More findings = more problems. The tool is useful but the output is always bad news.

Property proving: "We verified that no unauthorized principal can reach any sensitive resource in your environment."

The formal verification does it. The output is a statement about what is TRUE across your entire environment for all possible inputs. The report is evidence of safety. The output is good news.

Executives want assurance. They want to tell their board, auditors and regulators: "this property holds. Here's the proof."

AWS team launched tools, interviewed the users. The executives loved soundness. The people writing the checks wanted proofs.

Why this matters for your security tooling

Every scanner on the market is a bug finder. You run it. You get findings. You triage and fix. You run it again. You get more findings. The cycle never ends because the tool is designed to find problems, not to prove their absence.

The question your CISO wants answer is:

  • Can any external principal reach our customer data? (yes or no, with proof)
  • Do any privilege escalation paths exist in our IAM graph? (yes or no, with proof)
  • Are there any ghost references — resources pointing to things that were deleted? (yes or no, with proof)
  • If an auditor asks whether we have unauthorized access paths, what do I tell them? (here's the mathematical evidence)

These are property questions. The answer is a proof.

Proof in practice

A proof in cloud security is a deterministic evaluation of a specific property against your actual configuration state:

Property: No principal outside organization o-abc123 can perform s3:GetObject on any resource tagged Sensitivity: High. Evaluation: 847 resources checked. 23 S3 buckets with Sensitivity: High. All 23 evaluated against identity policies, resource policies, SCPs, and permission boundaries. Result: VERIFIED. No external principal can reach any high-sensitivity bucket through any policy composition path. Evidence: Per-resource evaluation trace available. Deterministic. Reproducible. Same input → same output, always.

That's relevant to the CISO. We verified this property holds across 847 resources. Here's the evidence. Run it again. You'll get the same answer.

The CISO brings that to the board. The board brings it to the auditor. The auditor accepts mathematical evidence. The conversation shifts from "how many problems do you have?" to "which properties have you verified?"

The two conversations 

Conversation A (bug finding): Engineer: "We found 47 issues." CISO: "How many did we have last quarter?" Engineer: "38." CISO: "So we're getting WORSE?" Engineer: "No, we expanded coverage..." CISO: "Fix them. All of them. By Friday." Conversation B (property proving): Engineer: "We verified three properties across the entire environment." CISO: "Which properties?" Engineer: "No unauthorized external access paths. No privilege escalation chains. No ghost references to deleted resources." CISO: "And they hold?" Engineer: "Verified. Deterministic. Here's the evidence." CISO: "What properties should we verify next?"

Conversation A is defensive. The engineer is delivering bad news and defending why there's more of it. The meeting ends with a mandate to fix things.

Conversation B is constructive. The engineer is delivering evidence of safety. The CISO is asking strategic questions about what to verify next. The meeting ends with a roadmap.

Same engineer and environment. Different tool and conversation.

Why Amazon invested in proofs

The business case for formal verification is economic.

Customers moved workloads to AWS because of proofs. Because AWS could prove properties. Financial institutions, government agencies, healthcare organizations are the ones with the strictest requirements moved more data to AWS because the proofs gave them assurance no bug-finding tool could provide.

Proofs enable fearless infrastructure rewrites. Amazon rewrites its infrastructure to lower costs (low-margin business, every penny matters). Formal verification enables that prove the new code is equivalent to the old, ship it confidently. The rewrite pays for the proof. The proof enables the rewrite. Virtuous cycle.

Proofs compound across services. A proof of KMS correctness helps every service that uses KMS (which is every service). A proof of the policy interpreter helps every API call to AWS (2 billion per second). Bug findings are local. You find a bug in one service, you fix it in one service. Proofs are global. You prove a property once, every consumer benefits.

Proofs are the answer to "why should I trust you?" When a regulated customer asks "how do I know my data is safe?", "we ran a scanner and found no issues" is weak. "We proved this property holds under these assumptions, and here's the evidence" is strong. The difference is "we looked and didn't see anything" and "we proved nothing is there."

The adoption pattern

How formal verification spread inside Amazon:

Step 1: Pitch formal methods to a team. Step 2: They say "not interested." Step 3: Don't push. Leave. Wait. Step 4: They have a bad day. Security incident. Close call. Step 5: Their priorities change. They call you. Step 6: "Can you come to the Friday security meeting and explain that formal methods stuff you mentioned?" Step 7: Adoption happens.

This happened "over and over and over." This works because the value was demonstrated before the need became urgent. The team saw the proof capability. They filed it away as "interesting but not my priority." Then the priority changed. The capability was already there, waiting.

What this means for you

You need a tool that evaluates your configuration state against declared safety properties deterministically and produces evidence you can hand to an auditor.

The progression:

Today: Scanner finds 47 issues. You triage. You fix. You run again. 47 becomes 52. The cycle never ends. Leadership loses confidence. Step 1: Run a tool that proves structural properties with no attack paths, no privilege escalation, no ghost references from your existing configuration. No setup. No tags. Results in minutes. Step 2: Bring the evidence to your CISO. Not "we found 47 issues." Instead: "we verified 3 properties across 847 resources." Step 3: The CISO asks: "what properties should we verify next?" You now have a roadmap driven by properties, not by bug counts. Step 4: Each quarter, the list of verified properties grows. The evidence is cumulative. The story gets stronger. The board sees progress measured in proofs, not in bugs.

The scanner doesn't go away. Bug finding is still necessary. You need to fix specific issues. But the conversation shifts from "how many problems do we have?" to "which properties have we verified?" The first question has no good answer (more findings = more problems). The second has a clear trajectory (more verified properties = stronger assurance).

The question that changes the conversation

When preparing a security report for leadership, ask yourself:

Am I delivering a list of problems? Or am I delivering evidence of properties?

If it's a list of problems, the best case is "fewer problems than last quarter." That's still bad news. The trend you're hoping for is "we're getting closer to zero" which you'll never reach.

If it's evidence of properties, the best case is "we verified three new properties this quarter, bringing our total to twelve." That's good news. The trend is "the verified surface is growing." The trajectory is progress.

Amazon learned this from a bank that almost left and stayed because of a proof. Your organization can learn it from a tool that proves properties instead of finding bugs.

The math and evidence is the same. The conversation it enables and changes everything.

Bug Finding vs. Property Proving 

┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ BUG FINDING (what scanners do) │ │ │ │ Output: "We found 47 issues" │ │ Trend: More coverage → more findings → looks worse │ │ Evidence: List of known-bad patterns matched │ │ Scope: Checks inputs you tested │ │ To board: "We're reducing our issue count" (defensive) │ │ Feeling: Bad news. Every report is a list of problems. │ │ │ │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ │ │ │ PROPERTY PROVING (what verification does) │ │ │ │ Output: "We verified 3 properties across 847 resources" │ │ Trend: More properties verified → stronger assurance │ │ Evidence: Mathematical proof over ALL possible inputs │ │ Scope: Proves property holds for every case, not just tested ones │ │ To board: "We proved these properties hold" (constructive) │ │ Feeling: Good news. Every report is evidence of safety. │ │ │ │ Amazon grew formal verification to 300+ scientists because │ │ a major bank added "an extra zero to their check" — │ │ not because of bug counts, but because of mathematical proofs. │ │ │ └─────────────────────────────────────────────────────────────────────────┘

The properties your auditor will ask about 

┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ PROPERTY VERIFIED? EVIDENCE │ │ ────────────────────────────────── ───────── ────────── │ │ No external principal can reach ☐ YES Deterministic │ │ any sensitive resource ☐ NO evaluation trace │ │ │ │ No privilege escalation path ☐ YES Transitive closure │ │ exists in the IAM graph ☐ NO over permissions │ │ │ │ No ghost references to ☐ YES Cross-reference │ │ deleted resources exist ☐ NO all identifiers │ │ │ │ No policy is mathematically ☐ YES SMT satisfiability │ │ equivalent to Principal: * ☐ NO check │ │ │ │ No Deny statement is unreachable ☐ YES Condition │ │ (shadowed / dead code) ☐ NO reachability │ │ │ │ Evaluation: deterministic, reproducible, same input → same output │ │ Scope: ALL resources observable in configuration snapshot │ │ Tool: open source, air-gapped, no cloud credentials required │ │ │ └─────────────────────────────────────────────────────────────────────────┘

The quarterly security report, transformed 

┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ BEFORE (scanner-based) AFTER (property-based) │ │ ───────────────────── ──────────────────────── │ │ Q1: 47 findings Q1: 3 properties verified │ │ Q2: 52 findings (worse?) Q2: 5 properties verified (progress) │ │ Q3: 38 findings (better?) Q3: 8 properties verified (progress) │ │ Q4: 61 findings (???) Q4: 12 properties verified (progress) │ │ │ │ Trend: unclear Trend: monotonically improving │ │ Story: "we keep finding bugs" Story: "verified surface is growing" │ │ Board reaction: concern Board reaction: confidence │ │ │ │ The scanner doesn't go away. Bug fixing is still necessary. │ │ But the STRATEGIC conversation shifts from │ │ "how many problems?" to "which properties are verified?" │ │ │ └─────────────────────────────────────────────────────────────────────────┘

Structural property verification such as attack paths, privilege escalation, ghost references, policy shadowing is implemented in Stave, an open-source cloud security reasoning engine. 3,000+ safety invariants. Deterministic evaluation. Evidence traces for every finding.