✓ Human-authored analysis; AI used for formatting and proofreading.
I maintain Stave, so this is a product capability article, not independent analysis. The CSA rankings are theirs. The capability claims are mine.
Every year, the Cloud Security Alliance surveys hundreds of industry experts to rank the most significant threats to cloud computing. The 2024 report identifies eleven. We applied Axiomatic Design. A systems engineering methodology from MIT to derive what a cloud security tool should do from those eleven problems, without referencing any existing tool. Then we compared the result to what we built.
Nine of eleven threats map to Stave capabilities. Two don't and we'll name those, because a tool that claims to solve problems it can't loses credibility.
Threat 1: Misconfiguration and inadequate change control
The #1 ranked threat. The CSA identifies two problems in one: resources are misconfigured, AND configuration changes aren't controlled.
How Stave addresses misconfiguration: 3,109 controls evaluate every resource's configuration against named security invariants. Each control specifies a property that should always be true ("no S3 bucket permits public write access," "IMDSv2 is enforced on all EC2 instances," "no IAM role uses AdministratorAccess"). When a control fails, Stave reports exactly which resource, which property, and which named attack pattern the failure enables.
But the CSA doesn't just say "misconfiguration." It says "inadequate change control." That's a different problem — it's not "is the configuration wrong?" but "did the configuration CHANGE, and did the change introduce risk?"
How Stave addresses change control: The stave diff command compares two snapshots and reports what changed between them. Not just field-level diffs — compound-level impact. A single property change (disable IMDSv2 on one instance) can activate an entire attack chain. The diff engine connects per-resource changes to compound-level risk: "this change activated the Capital One breach pattern on 3 instances." It also detects when the snapshot scope changed (collector permissions reduced, regions added or removed) so collection artifacts don't masquerade as security changes.
Threat 2: Identity and Access Management
The CSA identifies excessive permissions, invisible access paths, and the difficulty of understanding who can access what across complex IAM configurations.
How Stave addresses IAM: Two engines work together. The CEL predicate engine evaluates per-resource IAM properties: does this role have AdministratorAccess? Does this trust policy allow cross-account assumption without conditions? Is this OIDC federation scoped to specific repositories?
The Datalog reachability engine goes further. It computes transitive access paths through role assumption chains, resource policies, and federation trust. It answers questions like "can a GitLab pipeline in project X transitively reach S3 bucket Y through OIDC → role A → role B → bucket policy?" This is a graph traversal that per-resource checks can't perform, because the answer crosses resource boundaries.
Federation trust (OIDC, SAML, cross-account) is modeled as graph edges in the reachability engine. An OIDC provider creates an edge from the external identity to an IAM role. The transitive closure computation then reveals paths that no individual check surfaces.
Threat 3: Insecure interfaces and APIs
The CSA identifies public exposure of APIs and interfaces without adequate controls.
How Stave addresses API exposure: The public exposure control family covers every AWS resource type that can be made public. Over 40 resource types across three exposure mechanisms (resource policies, sharing APIs, network access). Each type has a dedicated control that detects when the resource is accessible from outside the organizational boundary.
Stave evaluates exposure at two distinct layers. The state layer checks whether a resource IS currently public — is Block Public Access enabled on this S3 bucket, is this API Gateway endpoint authenticated, is this Lambda Function URL using AuthType: AWS_IAM. The governance layer checks whether an SCP EXISTS that prevents the public exposure setting from being disabled. A BPA setting without an SCP protecting it is one API call away from disappearing — any principal with s3:PutPublicAccessBlock or ec2:DisableSnapshotBlockPublicAccess permissions can remove it. The governance controls verify that the SCP denying these actions is in place, turning a fragile state-level protection into an organizationally enforced invariant. The state layer tells you "BPA is on." The governance layer tells you "BPA cannot be turned off."
Threat 4: Inadequate cloud security strategy
The CSA identifies ad hoc, unverifiable, and unrepeatable security posture assessments.
How Stave addresses this: Stave evaluates a configuration snapshot — a static, immutable artifact. The same snapshot evaluated against the same control catalog produces the same findings on anyone's machine, every time. The findings are independently reproducible: share the snapshot with an auditor, they run Stave, they get the same results. No proprietary algorithm, vendor-specific scoring or trust our dashboard.
The control catalog is version-controlled, human-readable YAML. Each control specifies its invariant in plain language, its predicate in CEL, and its framework mappings (CIS, SOC 2, PCI-DSS, HIPAA, NIST, DORA). Adding a compliance framework requires zero engine changes. It's a YAML mapping file. The strategy is encoded in the catalog.
Threat 5: Insecure third-party resources
The CSA identifies unaudited access by third parties — vendors, partners, SaaS integrations to cloud environments.
How Stave addresses third-party access: The federation audit controls enumerate every OIDC provider, SAML provider, and cross-account trust relationship. Each is checked against an approved-source list. Unknown providers are findings. Providers without subject restrictions (allowing any identity from the provider to assume roles) are critical findings.
The Datalog reachability engine extends this to transitive federation queries: not just "is this OIDC provider known?" but "what can identities from this provider transitively reach?" A GitLab pipeline federating into your account with an unscoped trust policy may have transitive access to production data through role chains that no single-resource control sees.
Threat 6: Insecure software development — OUT OF SCOPE
The CSA identifies vulnerabilities introduced during software development — code-level flaws, insecure dependencies, container image vulnerabilities.
Why Stave doesn't address this: Stave verifies cloud configuration. It does not analyze source code, scan container images, or evaluate dependency manifests. The SSRF vulnerability that initiated the Capital One breach is invisible to Stave. It lives in the application, not in the AWS configuration.
What to use instead: SAST, DAST, SCA, and container scanning tools. Stave tells you the blast radius if an application-layer entry point exists. Application security testing tells you whether one does. Both answers are needed; neither is sufficient alone.
Threat 7: Accidental cloud data disclosure
The CSA identifies data accidentally exposed through misconfigured storage, databases, or sharing settings.
How Stave addresses data disclosure: The public exposure controls detect every mechanism by which data can be accidentally exposed: public S3 bucket policies, public ACLs, publicly shared RDS snapshots, publicly accessible databases, unauthenticated resource sharing, permissive VPC endpoint policies.
The compound finding engine adds the dimension that per-resource scanners miss: a public bucket is one finding. A public bucket containing data classified as sensitive, with no CloudTrail logging, matching the Vitagene breach pattern, is a named incident shape at critical severity. The compound finding connects the exposure to its consequence — and the choke point analysis quantifies the remediation leverage. If the public-access control that participates in the Vitagene pattern also appears in seven other compound chains, its choke point score reflects that: fixing this one control breaks eight attack paths simultaneously. The priority score surfaces this to the CISO as a single number (computed from compound severity × blast radius × environment tier × choke point multiplier × incident precedent), turning "we have a public bucket" into "fixing this public bucket eliminates eight named breach patterns across production, priority 847."
Threat 8: System vulnerabilities — OUT OF SCOPE
The CSA identifies unpatched systems with known vulnerabilities.
Why Stave doesn't address this: Stave evaluates configuration state, not patch state. Whether an EC2 instance has a specific CVE requires runtime vulnerability scanning — checking installed packages, OS versions, and application dependencies. Stave can detect that an instance is long-running (staleness control), that it's not managed by SSM (patch management gap), or that its AMI is outdated (lineage control). But it cannot determine whether a specific CVE is present.
What to use instead: Vulnerability scanners (Inspector, Qualys, Nessus) for CVE detection. Stave and vulnerability scanning are complementary: the scanner finds the CVE, Stave determines whether the configuration around the vulnerable instance enables exploitation.
Threat 9: Limited cloud visibility/observability
The CSA identifies the inability to see what's in the cloud environment — shadow resources, untracked services, blind spots.
How Stave addresses visibility: The stave readiness command reports which asset types are in the snapshot and which controls are blocked by missing observations. A readiness report showing zero observations for a service you use is a finding, not silence.
The SILENT_RISK classification catches an even subtler visibility problem: when a control's predicate references a field that doesn't exist in the observation, the control passes vacuously. It looks safe. It's not. The data to determine safety was never collected. SILENT_RISK classifies these vacuous passes separately from genuine passes, making incomplete observations visible rather than invisible.
The collector contract (data/collector-contract.yaml) formalizes what the observation layer must capture for each field. 47 semantic postconditions that define what "correctly collected" means. The stave validate --check collector-contract command validates observations against this contract, reporting missing fields, wrong types, and coverage percentage. An adopter building a collector can iterate against the contract until their observations are complete.
Threat 10: Unauthenticated resource sharing
The CSA identifies resources shared without authentication requirements — publicly accessible storage, APIs callable without credentials, unauthenticated function URLs.
How Stave addresses unauthenticated sharing: Specific controls check for each unauthenticated sharing mechanism: Lambda functions with Principal: * in resource policies, Lambda Function URLs with AuthType: NONE, S3 buckets with public ACLs, API Gateway endpoints without authentication, SES identity policies permitting external senders.
The organizational policy controls verify that SCPs prevent these configurations at the organizational level — not just detecting them after creation, but verifying that the SCP preventing their creation exists. A resource that can't be made public because the SCP denies it is categorically different from a resource that isn't public today but could be made public by any developer with the right IAM permissions.
Threat 11: Advanced persistent threats
The CSA identifies sophisticated attackers who chain multiple techniques across multiple services to achieve their objectives.
How Stave addresses APTs: This is where compound findings and named incident shapes provide what no per-resource scanner can.
An APT doesn't exploit one misconfiguration. It exploits a chain: gain initial access (exposed credentials, SSRF), move laterally (overpermissioned role, cross-account trust), escalate privileges (unscoped OIDC trust, role chaining), access data (broad S3 permissions, unencrypted snapshots), and persist (rogue OIDC provider, Lambda layer backdoor). Each step in the chain is a configuration state. Each state is individually low-to-medium severity. The compound is critical.
Stave's chain engine evaluates 488 named attack patterns derived from 16 documented breaches, 65 offensive techniques, and 200+ threat intelligence entries. Each chain is a conjunction of controls: when all member controls fail, the chain fires as a compound finding at elevated severity. The distance-one classification tells you when you're one control change away from a named incident shape — when all but one gate is failing, and the remaining gate is the only thing preventing the pattern from activating.
The named incident shapes cite precedent with documented consequences: Capital One ($300M), Uber ($148M fine), CodeSpaces (company ceased operations). The CISO can tell the board "we are zero named incident shapes away from a breach". A statement grounded in machine-verified compound analysis, not in a compliance percentage.
What the compound approach eliminates
The CSA problems aren't independent. Alert noise (problem P1 from our operational analysis), triage time waste (P2), false alarms (P3), overlapping tools (P5), and tool sprawl (P7) are all consequences of the same architectural error: evaluating resources independently and treating each finding as a separate alert.
Stave's compound-only default output changes this. 3,109 controls evaluate silently as detection infrastructure. Only the compound chains that cross the exploitability threshold produce user-facing findings. In practice, this means approximately 50 ranked compound findings instead of 300+ undifferentiated atomic alerts. Each finding has a numeric priority score computed from five dimensions — compound severity, blast radius, environment tier, choke point score, and incident precedent. So no triage meeting is needed to determine what to fix first.
The priority score replaces human judgment with machine-computed ranking. Two findings at CRITICAL severity may have very different urgency: one is exploitable with automated tools against a production database (priority 847), the other requires manual exploitation against a dev sandbox (priority 210). The score captures this distinction. The severity label doesn't.
What stays when the expert leaves
The CSA's Threat 4 (inadequate strategy) and our operational analysis's Problem 6 (tribal knowledge) share a root cause: security posture depends on people, not on systems. When the senior engineer who understood the environment leaves, the knowledge goes with them.
Stave encodes security knowledge as version-controlled specifications. The control catalog is the expert's mental model written as YAML: which configurations are acceptable, which are violations, which combinations are attack paths, which resources are exempt and why. The exemption mechanism captures rationale, approver, approval date, and review cadence. So when the expert leaves, the exemption explains itself. The stave validate command surfaces overdue exemption reviews by default, preventing the knowledge decay that follows personnel transitions.
The specification persists independently of the person who wrote it. A new team member can read the control definition, understand the invariant, and evaluate whether it still applies. The expert's contribution is a PR in the git history, not a conversation that was never documented.
When to use Stave
Nine of eleven CSA threats, addressed by seven design parameters, validated by Axiomatic Design from three independent starting points (CSA threats, operational pain, Stave architecture review). The same triangular, decoupled design matrix emerged each time confirming that the architecture isn't arbitrary but follows from the problem structure.
Two threats are out of scope: software development vulnerabilities (T6) and system patching (T8). These require code analysis and vulnerability scanning — different tools, different data, different expertise. Claiming to address them would violate the Independence Axiom, coupling configuration verification with code analysis in a way that makes both worse.
A tool that covers nine of eleven problems and names the two it can't is more trustworthy than a tool that claims to cover all eleven. The two gaps are real. Use SAST/DAST/SCA for T6 and vulnerability scanners for T8. Use Stave for everything else.
Top comments (0)