DEV Community: Bala Paranj

Every scanner checks what exists. Nobody checks what's missing

Bala Paranj — Tue, 28 Apr 2026 12:10:08 +0000

When cloud resources are deleted, the references to them persist — in IAM policies, event triggers, compute configs, and trust relationships. These orphaned references create exploitable gaps that no per-resource scanner can detect. The finding doesn't live on any single resource. It lives in the space between what's referenced and what exists.

The assumption every scanner makes

Cloud security scanners work by iterating over resources. For each S3 bucket, check its configuration. For each IAM role, check its policies. For each security group, check its rules. The resource exists. The scanner examines it. The finding describes what's wrong with it.

This is a reasonable architecture. It covers the vast majority of cloud security risks. Misconfigured resources — public buckets, overprivileged roles, open security groups — are the bread and butter of cloud security posture management.

But every scanner built on this architecture shares a blind spot: when a resource is deleted, it disappears from the scan. The scanner has nothing to examine. The resource is gone.

The references to it are not.

What deletion leaves behind

Cloud infrastructure is a graph of interconnected references. An IAM policy doesn't exist in isolation — it references S3 buckets, KMS keys, Lambda functions, and SQS queues by ARN. An EventBridge rule references a Lambda function as its target. A CloudWatch alarm references an SNS topic as its notification action. An ECS task definition references an ECR image by tag and a Secrets Manager secret by ARN.

When any of these referenced resources is deleted, the reference persists. The IAM policy still says "Allow PutObject to arn:aws:s3:::prod-audit-logs." The EventBridge rule still targets the Lambda function. The CloudWatch alarm still notifies the SNS topic. The ECS task definition still pulls the image.

The resource is gone. The references are not. And depending on the resource type, those references may be actively exploitable.

Three classes of orphaned references

Not every orphaned reference is equally dangerous. The risk depends on what the reference does and whether the deleted resource's identity is reclaimable.

Class 1: Reclaimable names with active permissions

S3 bucket names are globally unique across all AWS accounts. When a bucket is deleted, its name becomes available for registration by anyone, anywhere. An IAM policy that grants PutObject to that bucket name is now granting write access to whoever claims it next.

This is the most dangerous class. The organization's systems are actively trying to send data — audit logs, backups, application output — to a resource name that an attacker can claim. The attacker registers the bucket, configures it to accept writes, and data starts flowing. The Lambda function writing audit logs doesn't error. The S3 client library doesn't warn. The write succeeds. It goes to the wrong place.

A healthcare organization's HIPAA audit logs — the very records required to prove compliance — could be delivered to an attacker's bucket. The organization continues generating compliance evidence and delivering it to an adversary.

KMS key policies with orphaned principal references follow a related pattern. AWS protects IAM trust policies by replacing deleted role ARNs with internal unique IDs. But resource-based policies — on S3 buckets, KMS keys, SQS queues, SNS topics — evaluate the ARN string directly. A new role created with the same name as a deleted one matches the policy and inherits every permission it grants. For a KMS key policy, that means decrypt access to everything the key protects.

Class 2: Silent monitoring failures

A CloudWatch alarm fires when a metric breaches a threshold. The alarm's action sends a notification to an SNS topic. If the SNS topic has been deleted, the alarm fires into the void. The metric breaches the threshold. The alarm enters ALARM state. The notification goes nowhere. The dashboard shows the alarm is configured. The console shows the alarm is active. Nobody receives the alert.

This class is insidious because the system appears to work. The alarm exists. The EventBridge rule exists. The S3 event notification exists. The configuration looks correct. The targets are gone. Events are generated, matched, and silently dropped. Security automation that the organization built and maintains and monitors through dashboards has stopped functioning — and nothing indicates the failure.

An attacker who discovers this can exploit it deliberately. Delete the SNS topic that a critical alarm notifies. The alarm still fires. The team never knows. The attacker operates under the alarm's detection threshold, and even when they don't, the alarm's notification pipeline is broken. The alarm fires. Nobody comes.

Class 3: Compute dependencies

An ECS task definition references a container image by tag in a registry. The image is deleted. The next deployment pulls — what? If the registry is private, the pull fails. If the registry is public, whatever image currently holds that tag. An attacker who pushes a malicious image with the matching name and tag controls what code runs in the container. The malicious code executes with the task role's IAM permissions.

A Lambda function references a layer that's been deleted. The function deploys without the layer's contents. If the layer provided a security-relevant dependency — a TLS certificate bundle, an encryption library, authentication middleware — the function runs without it. The function serves traffic. The security dependency is silently absent.

A launch template references a deregistered AMI. The auto-scaling group can't launch new instances. During a DDoS attack, when the organization needs to scale response capacity, the scaling group discovers it can't scale. The launch template looks correct. The AMI it depends on is gone.

Why per-resource scanners can't detect this

The architectural limitation is fundamental. A per-resource scanner iterates over resources that exist and evaluates their properties. An orphaned reference finding doesn't live on any existing resource.

The IAM policy exists and looks normal — valid JSON, well-formed ARNs, reasonable permissions. The S3 bucket it references doesn't exist, but the scanner evaluating the IAM policy doesn't know that because it's evaluating the policy, not cross-referencing it against the full resource inventory.

The CloudWatch alarm exists and looks correct — metric configured, threshold set, action defined. The SNS topic it targets doesn't exist, but the scanner evaluating the alarm doesn't cross-reference action ARNs against the SNS inventory.

Cross-inventory reasoning requires holding two datasets simultaneously: the set of all ARNs referenced in configurations and the set of all resources that actually exist. The finding is the difference between these two sets. No single resource carries it. The scanner must reason about the gap — about what's referenced but absent.

Per-resource scanners aren't poorly built. They're architecturally incapable of this detection class. Adding ghost reference detection to a per-resource scanner requires changing its fundamental evaluation model from "for each resource, check properties" to "for each reference, check whether the target exists." That's a different architecture.

What about AWS-native tools?

AWS Config records configuration changes over time, including resource deletions. When a bucket is deleted, Config records the deletion event. But Config doesn't cross-reference the deletion against IAM policies that still reference the bucket. It records "bucket was deleted" — it doesn't conclude "and three policies still grant access to its name."

AWS CloudTrail records API calls, including DeleteBucket. But CloudTrail records the event, not the consequence. It tells you the bucket was deleted. It doesn't tell you which policies, triggers, and configurations are now orphaned.

AWS Security Hub aggregates findings from other services. None of the services it aggregates detects orphaned references.

The information exists in AWS — the deletion event is recorded, and the persisting references are visible through API queries. But no AWS-native service connects these two data points into a finding. The deletion is observed. The consequence is not.

The temporal dimension

Single-snapshot absence detection has an inherent uncertainty: if a resource doesn't appear in the inventory, maybe it was deleted. Or maybe the scanner didn't collect it. An incomplete scan produces false ghost references — resources that exist but weren't captured look like deletions.

Temporal detection resolves this. If a resource appeared in snapshot N-1 and is absent in snapshot N, the resource was genuinely deleted. The scanner collected it before. It's gone now. Two independent observations confirm the deletion. The ghost reference is verified — not just "we can't find it" but "we watched it disappear."

Temporal ghost detection is the highest-confidence version: compare the resource inventory across two consecutive snapshots, identify deletions, then cross-reference persisting references against the confirmed deletions. The finding says: "This resource existed on March 15. It's gone as of March 22. These seven policies still reference it."

The lifecycle gap

Cloud security tools generally treat infrastructure as a static snapshot. What's deployed right now? Is it configured correctly? This covers creation and configuration. It doesn't cover decommissioning.

The lifecycle of a cloud resource has three security-relevant phases:

Creation. The resource is provisioned. Policies are written to grant access. Triggers are configured to reference it. Compute definitions are updated to depend on it. Trust relationships are established. Every scanner covers this phase — the resource exists and can be evaluated.

Operation. The resource runs. Its configuration may drift. Permissions may expand. New references may be added. Scanners cover this phase too — they detect drift, overprivilege, and misconfiguration on the running resource.

Deletion. The resource is removed. The policies aren't updated. The triggers aren't cleaned up. The compute definitions still reference it. The trust relationships persist. No scanner covers this phase — the resource is gone, and the orphaned references are invisible to per-resource evaluation.

The deletion phase is where ghost references are created. And deletion is a normal operation — teams decommission services, migrate architectures, consolidate accounts, sunset products. Every deletion that doesn't include a full reference cleanup creates potential ghost references. In large organizations with hundreds of services and thousands of cross-references, the ghost reference count grows continuously.

What this means in practice

Consider a typical enterprise migration: a team moves from a legacy logging pipeline to a new one. The old pipeline used an S3 bucket for audit log storage, a Lambda function for processing, an SNS topic for alerting, and a KMS key for encryption. The new pipeline uses different resources with different names.

The migration is successful. The new pipeline works. The old resources are deleted. The cleanup checklist says:

[x] Delete old S3 bucket
[x] Delete old Lambda function
[x] Delete old SNS topic
[ ] Update IAM policy that granted write access to old bucket
[ ] Update EventBridge rule that targeted old Lambda
[ ] Update CloudWatch alarm that notified old SNS topic
[ ] Update KMS key policy that trusted old Lambda's role
[ ] Update ECS task definition that injected old Secrets Manager secret

The first three items are the resources. The last five are the references. The resources are deleted because they're the visible artifacts of the old pipeline. The references persist because they're scattered across IAM policies, event configurations, alarm actions, key policies, and task definitions — managed by different teams, in different consoles, with different change management processes.

No single team owns all the references. The application team deletes the Lambda function. The IAM team doesn't know the Lambda was deleted. The monitoring team doesn't know the SNS topic is gone. The platform team doesn't update the KMS key policy. The container team doesn't update the ECS task definition.

The migration succeeded. Five ghost references were created. Each is a potential security gap. One of them (the IAM policy granting write access to the deleted S3 bucket name) is an active exfiltration path — the bucket name is globally reclaimable.

Deleted and forgotten

The reason ghost references persist for months and years is simple: everything still works.

When you delete a resource and something breaks — a deployment fails, an API returns 500, a dashboard goes red — you notice immediately. You trace the error, find the missing dependency, and fix it. Broken things get fixed because broken things are visible.

Ghost references don't break anything. The IAM policy with a dangling ARN still loads. The CloudWatch alarm with a dead SNS target still evaluates its metric. The ECS task definition with a deleted secret still sits in the registry. The EventBridge rule with a missing Lambda target still matches events. Nothing errors. Nothing warns. Nothing crashes. The system runs exactly as it did before — minus one resource that nobody is looking for because it was intentionally deleted.

In complex cloud setups with hundreds of services, thousands of policies, and dozens of teams, the gap between "resource deleted" and "every reference cleaned up" isn't a failure of discipline. It's a structural impossibility. No team has visibility into every configuration surface that references their resources. The application team knows the Lambda function exists. They don't know which EventBridge rules target it, which KMS key policies trust its role, or which monitoring alarms depend on the SNS topic it publishes to. They delete the Lambda. Everything else keeps running. There's nothing to fix because nothing is broken.

That's the trap. The absence of failure is the failure. The system's continued operation is what makes ghost references invisible. If a dangling reference caused an error, every organization would have already solved this problem. It doesn't. So nobody has.

Detection without execution

Ghost reference detection doesn't require running code against live infrastructure, deploying agents, or performing active scanning. It requires two things: a complete inventory of what exists, and a complete inventory of what's referenced. The finding is the set difference.

This makes it suitable for air-gapped environments, compliance-sensitive workloads, and organizations that prohibit active scanning. The evaluation runs over configuration snapshots — captured state, evaluated offline, no credentials needed beyond the initial snapshot collection.

The detection is deterministic. Given the same two inventories, the same ghost references are found every time. No false positives from timing issues, network conditions, or scanner state. The reference either resolves or it doesn't. The resource either exists or it doesn't. The finding is binary.

Ghost References are Risky and Dangerous

Every organization that has ever deleted a cloud resource and didn't update every reference to it has ghost references in their infrastructure. The question is not whether they exist — the question is how many and how dangerous.

The organizations most at risk are the ones that have been operating longest. Years of migrations, decommissions, team changes, and architectural evolution create layers of orphaned references. Each one is individually small — a single ARN in a single policy. Collectively, they represent an unmapped attack surface that grows with every deletion and shrinks only through deliberate cleanup that nobody is doing because nobody can see the gaps.

The tools they rely on for security posture management evaluate what exists. The gaps exist in what does not exist.

Cross-inventory ghost reference detection is implemented in Stave, an open-source security CLI. 23 controls detect orphaned references across IAM policies, resource-based policies, event triggers, compute configurations, network infrastructure, cross-account trust, and temporal confirmation. The finding lives in the space between what's referenced and what exists.

Debugging theory solved our security triage problem

Bala Paranj — Mon, 27 Apr 2026 12:43:14 +0000

Our security CLI produced findings engineers couldn't triage without hours of research. We applied Andreas Zeller's defect/infection/failure chain from debugging theory — and triage time collapsed.

50 findings. 4 hours of triage.

Our Go CLI scans cloud configurations and reports security misconfigurations. A typical scan produces 50+ findings. Each finding says what control fired, which asset, and what severity.

Finding: CTL.IAM.ESCALATION.001
  Asset:     arn:aws:iam::123456:role/DeployerRole
  Severity:  high
  Remediation: Restrict iam:PassRole permissions

An engineer reads this and asks three questions:

What is wrong? "Escalation" — but what specifically about this role is the problem?
Why does it matter? Is this a theoretical risk or an active exposure?
What happens if I ignore it? Account compromise? Data leak? Compliance finding?

The finding answers none of these. The engineer opens the AWS console, reads the role's policy, traces the permissions, checks what resources the role can access, and reconstructs the risk chain manually. Per finding. Fifty times.

4.8 hours per week on triage. Not because the findings were wrong — because they were incomplete.

The insight from debugging theory

Andreas Zeller's Why Programs Fail describes how bugs propagate through programs. Every failure has three stages:

Defect — a specific flaw in the code
Infection — the defect causes incorrect state at runtime
Failure — the incorrect state produces an observable wrong behavior

A developer debugging a crash doesn't start at the crash. They trace backward: what state was wrong (infection), what code produced that state (defect). The chain from defect to failure is how they understand the bug.

Cloud misconfigurations follow the exact same chain:

Defect — a specific misconfiguration (the role grants iam:PassRole without resource constraints)
Infection — the misconfiguration propagates through dependent infrastructure (an attacker with this role can pass any role to any Lambda function)
Failure — the observable security consequence (full account compromise via privilege escalation through Lambda execution roles)

We were reporting the failure (high severity escalation finding) without the chain that explains it. Engineers reconstructed the chain manually every time.

1. What the output looks like now

Each finding carries the full chain:

Finding: CTL.IAM.ESCALATION.001
  Asset:     arn:aws:iam::123456:role/DeployerRole
  Severity:  high

  DEFECT:
    The role grants iam:PassRole and
    lambda:InvokeFunction without resource
    constraints, allowing any role to be passed
    to any Lambda function.

  INFECTION:
    An attacker with temporary access to this
    role's credentials can create or invoke a
    Lambda function that executes with a higher-
    privileged role. The iam:PassRole permission
    has no Condition or Resource restriction,
    meaning any role in the account is a valid
    target — including administrator roles.

  FAILURE:
    Full account compromise. The attacker
    escalates from the DeployerRole's permissions
    to any role in the account, potentially
    reaching administrator access within a single
    API call chain.

  OBSERVED:
    identity.role.permissions = [
      "iam:PassRole",
      "lambda:InvokeFunction",
      "lambda:CreateFunction"
    ]
    identity.role.condition = null

  REMEDIATION:
    Add a Condition to iam:PassRole limiting
    which roles can be passed, and restrict the
    Resource field to specific function ARNs.

Three authored sections (defect, infection, failure) plus one mechanical section (observed). The engineer reads the finding and knows what's wrong, why it matters, and what happens if they ignore it. No console. No manual tracing. No reconstructing the chain.

2. Authored vs. mechanical

Two kinds of content in the expanded output, with different sources:

Authored content: defect, infection, failure. Written by humans who understand the vulnerability. Stored as metadata alongside the control definition. Reviewed for accuracy and clarity. Changes when explanation quality improves or when new attack techniques emerge.

Mechanical content: observed. Generated automatically by the engine during evaluation. Every property the predicate read during evaluation is captured as a trace — property path and observed value. No authoring needed. Scales to every control automatically.

The OBSERVED section is the engine's property-access trace — Zeller's dynamic slice applied to configuration evaluation. Instead of instrumenting a program's runtime to capture variable reads, we instrument the predicate evaluator to capture observation property reads. The trace shows exactly what data the engine consulted to produce this finding.

OBSERVED:
  storage.access.acl.grants[0].grantee =
    "http://acs.amazonaws.com/groups/global/AllUsers"
  storage.access.acl.grants[0].permission = "READ"

An engineer reading this knows: the engine looked at the ACL grants. It found AllUsers with READ permission. That's what fired the control. No guessing about which property triggered the finding.

3. Why three sections, not one

An earlier design combined everything into a single context field — one paragraph explaining the finding. It didn't work. The single paragraph mixed three concerns that serve different triage needs:

Section	Triage question	Who uses it
Defect	What do I look for in my config?	Engineer fixing the issue
Infection	Should I care about this right now?	Engineer prioritizing the backlog
Failure	What do I tell leadership?	Engineer reporting risk upward

An engineer triaging 50 findings scans the failure sections first to prioritize. "Account compromise" triages before "development log exposure." Then they read the infection for the top-priority findings to decide urgency. Finally, the defect tells them where to look.

Three sections, three reading patterns. A combined paragraph forces the engineer to parse prose for the piece they need. Separate sections let them scan.

4. The scaling problem

Three controls authored, 675 to go. Per-control authoring doesn't scale.

The observation that saved us: within a control family, infection and failure text is nearly identical. Every CTL.S3.PUBLIC.* control shares the same infection ("public internet access to bucket contents") and the same failure ("data exposure"). Only the defect differs (which specific ACL or policy property is misconfigured).

We separated the authored content into two levels:

Family-level templates — infection and failure text shared across a family:

# triage/families/s3_public.yaml
family: CTL.S3.PUBLIC
infection: "Anyone on the internet can access this
  bucket's contents without authentication. Automated
  scanners continuously enumerate public S3 buckets."
failure: "Data exposure. Bucket contents are readable
  or writable by the public."

Per-control overrides — defect text specific to each control:

# triage/overrides/s3_public_001.yaml
control: CTL.S3.PUBLIC.001
defect: "The bucket's ACL grants read access to the
  AllUsers principal."

47 family templates cover 675 controls. Per-control overrides exist only when the defect needs to be specific. The engine joins them at runtime: family template provides infection and failure; override provides defect; OBSERVED is always mechanical.

This reduced the authoring burden by 14×. And it separated the two concerns — security definitions in one directory, triage content in another. Different change rates, different authors, different review processes.

5. The authoring guide

Authors write three things per family. Each has a specific purpose and a specific quality bar:

Defect: Specific about what's misconfigured. "The bucket's ACL grants AllUsers read access" is a defect. "Public S3 exposure" is a category. Engineers need the former to match against their own config.

Infection: How the defect propagates to enable attack. Plain language, focused on mechanism. Engineers use this to decide whether the defect matters in their specific environment. A public bucket in a CDN-only architecture is different from a public bucket holding customer PII. The infection section provides the reasoning; the engineer applies context.

Failure: Worst-case outcome in terms that matter to the business. "Data exposure" for storage issues. "Account compromise" for privilege escalation. "Regulatory violation" for compliance controls. Not CVSS scores — language that leadership understands without translation.

The quality bar: an engineer reading the three sections should be able to triage the finding without opening another tool or consulting external documentation. If the content doesn't reach that bar, it's not ready.

6. What changed for engineers

Before: 50 findings. Each a control ID, severity, and generic remediation. 4.8 hours of manual triage per week.

After: 50 findings. Each with a defect-infection-failure chain explaining why it matters, mechanical observed data showing what the engine found, and specific remediation. Triage is reading, not research.

The findings aren't fewer. The work per finding is smaller. An engineer scanning failure sections to prioritize, reading infection sections to decide urgency, and checking defect sections for the specific fix — that's minutes, not hours.

When to apply this

The defect-infection-failure chain works whenever your tool reports problems that require context to act on:

Linters that report rule violations but don't explain why the rule exists or what happens if it's violated.
Policy engines that report policy failures but don't explain how the failure propagates through dependent infrastructure.
Compliance scanners that report control failures but don't explain the business consequence of non-compliance.
Infrastructure auditors that report drift but don't explain which drift matters and which is cosmetic.

If your tool's output requires engineers to research context before acting, the context belongs in the output. Zeller's chain gives you the structure to deliver it: what's wrong, how it spreads, what breaks.

Understanding vs Detection Accuracy

Tool authors optimize for detection accuracy. We tune predicates, reduce false positives, expand control catalogs. That's the hard technical work, and it matters.

But the engineer receiving 50 findings doesn't care about detection accuracy at triage time. They care about understanding: what's wrong, why it matters, what happens if I ignore it, and what should I do. If answering those questions takes hours of manual research, detection accuracy is irrelevant — the findings sit in a backlog until someone has time.

The output isn't done when the detection is correct. It's done when the engineer can act without leaving the terminal.

These lessons were learned from real problems during development of Stave, an offline configuration safety evaluator.

The Airgap Test: Refactoring a Cobra CLI into a Library API

Bala Paranj — Sun, 26 Apr 2026 12:06:42 +0000

How a single rule — only RunE touches *cobra.Command — turned a CLI codebase into a library that happens to ship with a CLI.

I run a static analysis pass on my Go CLI that I call a contamination scan. It looks for places where the CLI framework has leaked out of the adapter layer and into code that has no business knowing a CLI exists.

A recent run flagged 25 instances across 11 files. That's not a lot of code, but I was experimenting a lot with the existing codebase and my previous attempt at decoupling Cobra from existing business logic was still not complete. The reason I had to tackle the tech debt now was I now have lot of commands and running them in a terminal is not a productive way for me to create small programs that exercises a given behavior and find bugs to fix. Once I write a program using the Stave library, I just use different data to test different scenario, the code remains the same. It is faster to find and fix bugs.

You might ask, that's why we have integration tests and unit tests. The reality is if you are using any LLM to generate code, the bugs are in the tests written by them. Only way I can make sure it is working is to use Stave functionality as a library and reproduce the problems. It is also a way for me to experiment to answer questions that CISO or security engineer will have on their mind. This makes the human judgement decide the correctness and capture the human knowledge in executable form.

The contamination

Three categories showed up:

Cobra objects passed into processing functions (12 instances):

func runValidate(cmd *cobra.Command, args []string) error {
    global := cliflags.GetGlobalFlags(cmd)
    project, _ := cmd.Flags().GetString("project")
    logger := cmdctx.LoggerFromCmd(cmd)
    // ... 80 lines of validation logic
}

Direct flag access inside business logic (5 instances):

if cmd.Flags().Changed("format") {
    // branch on whether the user explicitly set --format
}

Terminal I/O mixed into the work (8 instances):

RunE: func(cmd *cobra.Command, args []string) error {
    // ... compute exemptions ...
    fmt.Fprintf(cmd.OutOrStdout(), "Acknowledged: %s\n", id)
    // ... more compute ...
    fmt.Fprintln(cmd.OutOrStdout(), "Upcoming expirations:")
    for _, e := range upcoming {
        fmt.Fprintf(cmd.OutOrStdout(), "  %s  %s\n", e.ID, e.Expires)
    }
    return json.NewEncoder(cmd.OutOrStdout()).Encode(result)
}

Every one of these reduces to the same violation: code that should be a pure function is reaching back into the CLI framework to get its inputs and deliver its outputs.

Why it matters

The code worked. Tests passed. The contamination wasn't causing bugs — it was making certain things impossible.

I couldn't write a Go program that called the validation logic directly without spinning up a fake *cobra.Command to pass in. I couldn't reuse the exemption logic from a future scheduled job without scraping a CLI's stdout. I couldn't unit-test the Changed("format") branch without constructing the entire command tree.

The CLI framework had become load-bearing for code that had nothing to do with CLIs.

The mental model shift

The first instinct is defensive: decontaminate the core. Move things out of cmd/, ban the cobra import below a certain line.

The better framing — and the one that drives the design — is the opposite. The pure code isn't core that needs protection from the CLI. It's a library API that happens to have a CLI as its first caller. The CLI is one frontend. A scheduled job could be another. A test harness is another. An embedding into a larger Go program is another.

This sounds like a small distinction. It changes where the code lives.

If you treat the pure code as "internal stuff the CLI uses," it goes in internal/ and Go's visibility rules prevent anyone else from importing it. That's wrong. If the library is the product, it goes in pkg/, and the import path is part of the contract.

The refactor

One rule: only the RunE closure touches *cobra.Command. Everything below it takes plain inputs and returns data, or writes to an io.Writer passed in as a parameter.

Fix 1: Input structs replace cobra parameters

Per command, define an input struct with everything the work needs:

// pkg/validate/validate.go — the library API
package validate

type Input struct {
    Ctx     context.Context
    Stdout  io.Writer
    Stderr  io.Writer
    Logger  *slog.Logger
    Global  config.GlobalSettings
    Project string
}

func Run(in Input) error {
    // pure logic, no cobra anywhere
}

The closure becomes thin — it translates from CLI-world to library-world and gets out of the way:

// cmd/validate/cmd.go — the adapter
RunE: func(cmd *cobra.Command, args []string) error {
    return validate.Run(validate.Input{
        Ctx:     cmd.Context(),
        Stdout:  cmd.OutOrStdout(),
        Stderr:  cmd.ErrOrStderr(),
        Logger:  cmdctx.LoggerFromCmd(cmd),
        Global:  cliflags.GlobalSettingsFrom(cmd),
        Project: mustStr(cmd.Flags().GetString("project")),
    })
}

Fix 2: The transitive import trap

The first time I did this, I hit an invisible problem. My Input struct had a Global cliflags.GlobalFlags field. cliflags imports cobra. So every file that imported pkg/validate transitively imported cobra. The contamination was gone from the source but still in the dependency graph.

The fix is a hard split. The data type lives in pure-land; the function that builds it from a cobra command lives in adapter-land:

// pkg/config/global.go — pure, importable from anywhere
package config

type GlobalSettings struct {
    ConfigPath string
    Profile    string
    LogLevel   string
    NoColor    bool
}

// cmd/cliflags/global.go — adapter, imports cobra
package cliflags

func GlobalSettingsFrom(cmd *cobra.Command) config.GlobalSettings {
    return config.GlobalSettings{
        ConfigPath: mustStr(cmd.Flags().GetString("config")),
        Profile:    mustStr(cmd.Flags().GetString("profile")),
        LogLevel:   mustStr(cmd.Flags().GetString("log-level")),
        NoColor:    mustBool(cmd.Flags().GetBool("no-color")),
    }
}

Input.Global is typed as config.GlobalSettings. No transitive cobra import. Same trap applies to custom flag types implementing pflag.Value, to tri-state helpers, and to anything in a cmdctx-style helper package — pure types in pkg/, conversion functions in cmd/.

Fix 3: `Changed()` becomes an explicit type

Flags().Changed("format") is the closure asking cobra "did the user set this, or am I looking at a default?" That's a fair question for the adapter. It's not a question pure code should ask cobra. So resolve it at the boundary:

// pkg/config/optional.go
type Optional[T any] struct {
    Value T
    Set   bool
}

// in the closure
format := config.Optional[string]{
    Value: mustStr(cmd.Flags().GetString("format")),
    Set:   cmd.Flags().Changed("format"),
}

Pure code branches on format.Set, which carries no opinion about how the value got set. Aside: before doing this, check whether you need tri-state behavior. Several Changed() checks exist only because defaults aren't deterministic. If you can fix that, the check disappears entirely.

Fix 4: Output is data, not text

The hardest category. Eight instances of fmt.Fprintf(cmd.OutOrStdout(), ...) scattered through what was supposed to be business logic.

For batched output — return data, render at the boundary:

// pkg/exempt/exempt.go
type Result struct {
    Acknowledged []ExemptionID
    Revoked      []ExemptionID
    Upcoming     []Exemption
    Validation   []ValidationIssue
}

func Run(ctx context.Context, in Input) (Result, error) {
    // pure logic — no fmt, no JSON, no writers
}

// cmd/exempt/render.go
func renderText(w io.Writer, r exempt.Result) error { /* ... */ }
func renderJSON(w io.Writer, r exempt.Result) error { /* ... */ }

The four fmt.Fprintf calls for the upcoming-expirations table become a []Exemption field. The inline json.NewEncoder becomes a renderer choice. The validation output becomes structured []ValidationIssue that any frontend can format however it wants.

For streamed output — pass a reporter interface so progress can flow without buffering:

type Reporter interface {
    Health(report HealthReport)
    QueryRow(row QueryRow)
    QueryDone(stats QueryStats)
}

func Query(ctx context.Context, in Input, r Reporter) error

The CLI implements Reporter with stdout writes. A test implements it by appending to a slice. A future daemon implements it by pushing to a channel. The work doesn't know or care.

Making it stick

The refactor is useless if next month's PR re-introduces a cmd.Flags().Changed(...) call somewhere under pkg/. So golangci-lint enforces the rule mechanically:

linters-settings:
  depguard:
    rules:
      core:
        list-mode: lax
        files:
          - "!**/cmd/**"
          - "!**/cliflags/**"
          - "!**/cmdctx/**"
        deny:
          - pkg: "github.com/spf13/cobra"
            desc: "cobra is a CLI adapter; keep it out of library code"
          - pkg: "github.com/spf13/pflag"
            desc: "pflag is a CLI adapter; keep it out of library code"
          - pkg: "your.module/cmd/cliflags"
            desc: "cliflags imports cobra transitively; depend on pkg/config instead"
          - pkg: "your.module/cmd/cmdctx"
            desc: "cmdctx imports cobra transitively; receive resolved values"

Banning cobra alone isn't enough. The last two deny entries close the side door — without them, library code can re-acquire the cobra dependency by importing an adapter package that imports it.

A second rule blocking os.Stdout and os.Stderr writes outside cmd/ closes the I/O door the same way.

What changed in the design

The diff in the file tree is small. The diff in what's possible is large.

Before, the answer to "can I call this validation logic from a Go program without invoking the CLI?" was "technically yes, by constructing a fake cobra.Command and routing fake flags through it." Now it's import "your.module/pkg/validate" and call validate.Run(input).

Before, the test for "what does the exemption system do when a finding is upcoming-but-not-expired?" had to assert against formatted text from stdout. Now it asserts against Result.Upcoming, which is a []Exemption.

Before, there was a category of feature requests that would have required adding flags, plumbing them through a *cobra.Command, and wiring up new fmt.Fprintf calls. Now those features are method calls against the library, and the CLI optionally surfaces them.

The CLI didn't get smaller. The library got real.

The airgap dividend

There's an alternative design that I rejected: extracting the library and exposing it over HTTP or gRPC, the way Docker exposes a daemon. For an airgapped, single-binary tool, that's the wrong approach. There's no client and no server — just one process. The design is much simpler.

What I have instead is a library API consumed in-process by a CLI. The same Go types are the contract; there's no wire format to version, no schema to keep in sync, no serialization cost, no network surface to harden. A future scheduled job inside the same airgap doesn't shell out to the CLI and parse its output. It imports pkg/validate and calls the function. The binary stays static, the deployment stays one file, the trust boundary stays inside the process.

The contamination scan was nominally about the architecture. The result was an answer to "what is this project?" It's a library. The CLI is how I happened to ship it first. If you are scratching your head and thinking that I could have used testscript for this, I will explain why this is different in an upcoming article.

This refactoring is from a real project Stave, an offline configuration safety evaluator.

The Bucket You Deleted is Still in Your DNS: S3 Bucket Takeover at Bime

Bala Paranj — Sat, 25 Apr 2026 11:19:57 +0000

In 2016, a researcher found that a2.bime.io had a CNAME record pointing to bimeio.s3.amazonaws.com. The bucket bimeio did not exist. It was not owned by Bime. It was not owned by anyone.

The researcher created the bucket in their own AWS account. a2.bime.io was now serving their content — under Bime's domain, with Bime's SSL certificate, trusted by Bime's users.

This is HackerOne #121461. The fix was either claiming the bucket name or deleting the CNAME. Either takes under a minute. The window between bucket deleted and researcher claimed it was measured in days.

Why This Attack Requires Nothing

S3 bucket names are globally unique across all AWS accounts. When a bucket is deleted, the name becomes available to any AWS account immediately. If a DNS CNAME still points to that bucket's S3 endpoint, whoever registers the name first controls what the DNS record resolves to.

The attack requires no credentials, no exploit, no social engineering:

# Step 1: find the dangling CNAME
dig a2.bime.io
# a2.bime.io → bimeio.s3.amazonaws.com

# Step 2: check if the bucket exists
aws s3 ls s3://bimeio 2>&1
# NoSuchBucket

# Step 3: register it
aws s3 mb s3://bimeio --region us-east-1
# make_bucket: bimeio

# a2.bime.io now serves your content

Three commands. No special access. The domain is yours until Bime notices.

The Gap Traditional Tools Cannot See

CSPM tools inventory S3 buckets in the organization's AWS accounts. When a bucket is deleted, it disappears from the inventory. The scan finds nothing wrong — because there is nothing in the account to scan. The bucket does not exist.

The DNS record is in Route53 or Cloudflare or a registrar's control panel. It is not an AWS resource. It does not appear in AWS Config. It does not appear in Security Hub. It does not appear in any CSPM finding.

The NoSuchBucket response that a2.bime.io was returning is a valid HTTP response — monitoring does not alert on it. It looks like an outage, not a vulnerability.

The gap sits between two inventories: the AWS account (which has no bucket) and the DNS zone (which has a CNAME). Neither flags the mismatch. The organization has no tool that cross-references DNS records against S3 bucket ownership.

Why Teams Miss This

The sequence is common. A team deploys a feature using S3, sets up the CNAME, ships it. The feature is deprecated. The bucket is deleted. Deleting the bucket is in the AWS console. Removing the CNAME is in the DNS provider — a different system, often a different team. The CNAME removal is a separate task that does not block the deployment and gets forgotten.

Months later, nobody remembers that a2.bime.io exists. It does not appear in any active service inventory. It does not generate any alerts. It sits in the DNS zone file, pointing at nothing, waiting.

The System Invariant

The invariant is precise:

Every DNS CNAME pointing to an S3 endpoint must reference a bucket that exists and is owned by the same organization.

Observable in a snapshot without making any change to the infrastructure: the DNS record points to bimeio.s3.amazonaws.com, the bucket bimeio does not exist in the account inventory, the name is claimable. That is the full finding — no live exploitation required.

What Stave Detects

Stave models the DNS-to-S3 reference as a first-class asset with two properties:

{
  "id": "bime-a2-cname-ref",
  "type": "s3_bucket_reference",
  "properties": {
    "s3_ref": {
      "endpoint": "a2.bime.io",
      "bucket": "bimeio",
      "bucket_exists": false,
      "bucket_owned": false
    }
  }
}

The control evaluates the reference, not the bucket:

id: CTL.S3.BUCKET.TAKEOVER.001
name: Referenced S3 Buckets Must Exist And Be Owned
unsafe_predicate:
  any:
    - field: properties.s3_ref.bucket_exists
      op: eq
      value: false
    - field: properties.s3_ref.bucket_owned
      op: eq
      value: false

Either condition alone fires the control. Both being false — bucket does not exist and is not owned — means the name is available for registration by anyone.

The E2E Test

This report is one of 28 end-to-end tests in Stave's test suite. The test reconstructs the exact Bime configuration — a s3_bucket_reference asset with bucket_exists: false and bucket_owned: false — across two snapshots spanning 8 days, runs stave apply, and compares output byte-for-byte against a golden file.

./stave apply \
  --controls testdata/e2e/e2e-h1-bime-121461/controls \
  --observations testdata/e2e/e2e-h1-bime-121461/observations \
  --max-unsafe 168h \
  --now 2016-03-18T00:00:00Z

Expected output:

Status: NON_COMPLIANT
Finding: CTL.S3.BUCKET.TAKEOVER.001 — bime-a2-cname-ref
  Unsafe for 192 hours (threshold: 168 hours)
  Misconfigurations: bucket_exists=false, bucket_owned=false
Exit code: 3

The test proves that CTL.S3.BUCKET.TAKEOVER.001 detects the exact configuration state that enabled the Bime takeover — not in theory, but by evaluating a reconstructed snapshot against the control predicate with a golden file proving the output.

The Asset Type Distinction

The finding is on bime-a2-cname-ref, not on an S3 bucket. The asset type is s3_bucket_reference — the DNS record that points to S3, not the bucket itself.

This distinction matters. The bucket does not exist in any account. A bucket-level scanner has nothing to evaluate. The vulnerability lives in the reference — the DNS record that points to a name that is no longer owned. Stave models the reference as an asset precisely because the reference creates the risk.

This is the same principle as stave path — Stave reasons about relationships between assets, not just about assets in isolation. A CNAME record and the bucket it points to form a relationship. When the bucket end of that relationship is broken, the CNAME becomes a liability.

Remediation

Two options, both under a minute:

Option A — Claim the bucket name:

aws s3 mb s3://bimeio --region us-east-1

The bucket can be empty. The goal is to claim the namespace before an attacker does. Apply Block Public Access immediately after:

aws s3api put-public-access-block \
  --bucket bimeio \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,\
    BlockPublicPolicy=true,RestrictPublicBuckets=true

Option B — Remove the CNAME:

aws route53 change-resource-record-sets \
  --hosted-zone-id ZONE_ID \
  --change-batch '{
    "Changes": [{
      "Action": "DELETE",
      "ResourceRecordSet": {
        "Name": "a2.bime.io",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{"Value": "bimeio.s3.amazonaws.com"}]
      }
    }]
  }'

Option A is faster — no DNS propagation delay. Option B is cleaner — removes the unused reference entirely. Do Option B regardless, because the subdomain should not exist if the bucket is empty.

The process fix:
Before deleting any S3 bucket, search DNS records for references to that bucket name. Remove the CNAME before deleting the bucket.

Checklist

Audit DNS zone for CNAMEs pointing to *.s3.amazonaws.com or *.s3-*.amazonaws.com
For each: verify the referenced bucket exists and is owned by the account
Bucket deletion process includes DNS record cleanup as a required step
CTL.S3.BUCKET.TAKEOVER.001 runs in CI on every infrastructure change
DNS changes and bucket deletions are correlated in change management

The bucket was deleted. The DNS record was not deleted. The attack was three commands.

HackerOne #121461 — Bime S3 bucket takeover via dangling CNAME. Stave E2E test e2e-h1-bime-121461 reconstructs the vulnerable configuration and verifies detection against a golden file. Stave detects dangling S3 bucket references via CTL.S3.BUCKET.TAKEOVER.001, evaluated from local DNS and S3 inventory snapshots without cloud credentials.

8.7 billion records leaked from one misconfigured cluster. Eight findings would have prevented it.

Bala Paranj — Fri, 24 Apr 2026 12:40:01 +0000

A publicly exposed Elasticsearch cluster leaked billions of records including national IDs and plaintext passwords. No exploit. No zero-day. Just a database on the internet without authentication. Here's what prevention looks like for this class of incident.

No exploit required

In 2026, researchers discovered a massive Elasticsearch cluster exposed to the public internet. Billions of records — national IDs, addresses, phone numbers, plaintext passwords — accessible to anyone who knew the endpoint. No authentication. No VPC restriction. No encryption. The cluster sat open for weeks.

The breach wasn't sophisticated. Nobody exploited a vulnerability. Nobody bypassed security controls. There were no security controls to bypass. The cluster was deployed with default settings that allowed unauthenticated access from any IP address on the internet.

This is the most common class of data breach in cloud infrastructure: a managed data store left public because the access controls that should have been configured weren't. The same pattern that causes public S3 buckets, exposed RDS databases, and open Redis instances. Different service, identical root cause.

1. What went wrong

An Elasticsearch cluster (or AWS OpenSearch domain) has six security layers. Every layer was either disabled or left at its permissive default:

Public endpoint. The cluster was accessible from the internet. OpenSearch domains can be deployed inside a VPC (private, unreachable externally) or with a public endpoint. This one had a public endpoint.

No authentication. OpenSearch supports fine-grained access control — IAM-based authentication, SAML federation, internal user databases. None were enabled. Any HTTP request to the endpoint returned data.

No access policy restriction. OpenSearch resource-based policies can restrict which principals or IP ranges can access the domain. The policy either allowed Principal: "*" or had no restrictions.

No encryption in transit. HTTPS enforcement was not configured. Requests and responses, including the leaked records traveled in plaintext.

No encryption at rest. Data on disk was unencrypted. Anyone with storage-level access could read the raw data.

No audit logging. OpenSearch audit logs track who accessed what. Without them, there's no forensic trail of how many parties accessed the exposed data or what they downloaded.

Six layers of security. All six absent. The data store was as exposed.

2. Why this keeps happening

Elasticsearch and OpenSearch are developer tools. Teams deploy them for search, analytics, and log aggregation. The deployment path optimizes for "get it working". Getting it working means the endpoint is reachable and data flows in.

Security configuration is a separate step that happens after deployment or doesn't happen at all. The defaults don't help:

Public endpoint is often the path of least resistance during development
Authentication adds complexity to the client integration
VPC deployment requires networking setup that developers may not have permissions for
Encryption has a perceived performance cost (negligible in practice, significant in perception)

Every unsecured Elasticsearch cluster follows the same lifecycle: deployed for development, promoted to production, never hardened. The security review that should happen between development and production didn't happen or happened and didn't check this cluster.

This isn't unique to Elasticsearch. The same lifecycle applies to every managed data store: RDS, DynamoDB, Redis, Redshift. The service provides security controls. The deployment doesn't enable them. The data sits exposed until someone — a researcher, a journalist, or an attacker — finds it.

3. Eight findings, three critical

Running a security evaluation against this cluster's configuration produces eight findings that together paint the complete picture of exposure:

Finding 1: CTL.OPENSEARCH.PUBLIC.001 [CRITICAL]

  DEFECT:
    The OpenSearch domain has a public endpoint
    accessible from the internet without VPC
    restriction.

  INFECTION:
    Anyone on the internet can reach the domain's
    API endpoint. Automated scanners continuously
    enumerate public OpenSearch domains by probing
    known endpoint patterns. Exposure is not
    hypothetical — it's actively discovered within
    hours of deployment.

  FAILURE:
    Direct data access from the internet. Every
    document in every index is reachable without
    network-level barriers.

  DELTA:
    Change: domain public access
    Current: true
    Fix: set to false (disable), deploy in VPC

Finding 2: CTL.OPENSEARCH.AUTH.001 [CRITICAL]

  DEFECT:
    The OpenSearch domain has no authentication
    enabled. Requests are accepted without
    credentials.

  INFECTION:
    Any HTTP request to the domain endpoint returns
    data. No IAM signature, no username/password,
    no SAML token required. Combined with a public
    endpoint, this means anyone on the internet can
    query, modify, or delete data.

  FAILURE:
    Unauthenticated data access. The entire contents
    of the cluster are readable by any party that
    discovers the endpoint.

  DELTA:
    Change: authentication enabled
    Current: false
    Fix: set to true (enable)

Finding 3: CTL.OPENSEARCH.VPC.001 [CRITICAL]

  DEFECT:
    The OpenSearch domain is not deployed in a VPC.
    Network access is controlled only by the domain's
    access policy, not by VPC security groups or
    network ACLs.

  DELTA:
    Change: VPC deployment
    Current: false
    Fix: set to true (enable), deploy in VPC

Plus five high-severity findings for missing fine-grained access control, permissive access policy, no HTTPS enforcement, no encryption at rest, and no node-to-node encryption. Plus medium-severity findings for missing audit logging.

Three critical findings. Five high. Each with a specific DEFECT describing what's wrong, an INFECTION explaining how it enables attack, a FAILURE describing worst-case outcome, and a DELTA providing the exact configuration change that eliminates the finding.

You can see eight findings with triage context and counterfactual fixes and act on it.

4. Why individual findings aren't enough

A flat scanner produces the same eight findings as a list. The operator sees eight items and starts working through them. Which one first?

The critical findings are obvious: public endpoint, no auth, no VPC. But the relationship between them matters for triage. Public endpoint without authentication is catastrophic. Public endpoint with authentication is concerning but not an immediate breach. No VPC without a restrictive access policy is exposed. No VPC with a policy limiting to specific IPs is a calculated risk.

The findings compound. The risk isn't additive — it's multiplicative. Each missing security layer removes a barrier that could have compensated for another missing layer. When all six layers are absent simultaneously, the exposure is total.

Compound chain detection models this. When the public-endpoint, no-auth, and no-VPC findings fire on the same domain, a chain definition composes them into one compound finding representing total exposure. The compound finding scores higher than any individual finding — its ExposureScore reflects the multiplicative risk of all barriers being absent, not just the additive sum.

The operator sees "this domain has total exposure" as one triage unit, not three separate findings they mentally correlate.

5. The data store pattern

The Chinese leak is Elasticsearch. But the misconfiguration pattern is universal across managed data stores. Every service has the same security layers:

Layer	S3	RDS	OpenSearch	Others
Public access control	Block Public Access	PubliclyAccessible	VPC / public endpoint	Same pattern
Authentication	IAM policies	IAM DB auth	Fine-grained access	Same pattern
Access policy	Bucket policy	Security groups	Resource policy	Same pattern
Encryption in transit	TLS enforcement	force_ssl	HTTPS enforcement	Same pattern
Encryption at rest	SSE-S3/KMS	StorageEncrypted	EncryptionAtRest	Same pattern
Audit logging	Access logging	Audit logs	Audit logs	Same pattern

The controls that prevent the Chinese leak on Elasticsearch are structurally identical to the controls that prevent public S3 buckets and exposed RDS instances. Different service names, different property paths, same security model.

This is why the detection isn't per-incident. It's per-pattern. The publicly accessible data store without authentication pattern applies to every managed data store service. Detection that covers the pattern covers every incident in the class — past, present, and future.

6. What the operator does

The eight findings arrive with everything the operator needs:

DEFECT tells them where to look. "The domain has a public endpoint" — check the domain's endpoint configuration.

INFECTION tells them whether to care. "Automated scanners discover public OpenSearch domains within hours" — yes, this is urgent.

FAILURE tells them the consequence. "Every document in every index is reachable" — this is a data breach, not a theoretical risk.

DELTA tells them what to change. "Set public access to false, deploy in VPC" — the specific configuration change. Not generic advice. A verified counterfactual: make this change and this finding disappears.

The operator doesn't research the incident. Doesn't manually inspect the OpenSearch console. The finding carries the complete triage chain from "what's wrong" to "what to change." Prevention happens at the terminal.

Compare this to the alternative: the operator reads about the Chinese leak in the news, wonders "could this happen to us?", manually audits their OpenSearch domains, discovers the same misconfigurations, figures out the fixes, and applies them. Days of work. Or: they run a scan, get eight findings with full context, and fix the misconfigurations in an hour. Same outcome. Different timeline. The breach happens in the gap between those timelines.

7. Prevention, not forensics

The Chinese leak was discovered by researchers. Not by the organization's security team. Not by their monitoring. Not by their logging. By external researchers who found the open endpoint and reported it.

By the time the organization learned about the exposure, the data had been accessible for weeks. Any attacker who found it — and automated scanners find open Elasticsearch clusters within hours — had the data. The organization's incident response couldn't undo the exposure. They could only close the endpoint and assess the damage.

This is the forensics problem. Logging, monitoring, and alerting tell you about a breach after it happens. They're necessary for incident response. They don't prevent the incident.

Prevention means finding the public endpoint, the missing authentication, and the absent encryption before an attacker does. Before a researcher discovers it. Before the data is accessed. The scan runs continuously on every evaluation cycle. The misconfiguration is flagged the moment it appears, with the specific fix in the DELTA section.

The Chinese leak didn't require an exploit. It didn't require sophistication. It required a misconfigured deployment that nobody checked. The eight findings that would have caught it take seconds to evaluate. The fixes take minutes to apply. The breach took weeks to discover and affected billions of records.

Deployed Without Security Controls

The Chinese leak is not unusual. It's not even interesting from a technical perspective. A database was left on the internet without authentication. That's the whole story. No zero-day, no advanced persistent threat, no nation-state actor. Just a configuration that should have been set.

Public Elasticsearch clusters are discovered daily. Public S3 buckets are discovered daily. Public RDS instances, open Redis caches, exposed MongoDB databases — daily. Each one is the same pattern: a managed data store with security controls available, deployed without them.

The controls exist. The services provide them. The deployments don't enable them. The gap between security controls available and security controls enabled is where billions of records leak.

Eight findings close that gap before the breach.

Detection for publicly exposed data stores — including the OpenSearch pattern from the Chinese leak incident — is implemented in Stave, an open-source security CLI. Thirteen OpenSearch controls detect every layer of the exposure. Compound chains surface the multiplicative risk when multiple layers are absent simultaneously.

Your security tool should tell users what to change, not just what's wrong

Bala Paranj — Thu, 23 Apr 2026 12:10:10 +0000

Our findings said 'this bucket is public.' Users asked 'what do I change to fix it?' We derived the answer mechanically from the predicate AST — no per-rule authoring needed. Here's how counterfactual reasoning turns detection output into actionable fixes.

The finding that doesn't help

Finding: CTL.S3.PUBLIC.001
  Asset:     arn:aws:s3:::prod-assets
  Severity:  high

  DEFECT:
    The bucket's ACL grants read access to the
    AllUsers principal.

  REMEDIATION:
    Remove public access from the bucket ACL,
    or enable Block Public Access.

An engineer reading this knows what's wrong. But does not know:

Which specific property in their configuration to change
The current value of the property
What value would eliminate the finding
Whether there are multiple independent fixes (change any one)

DEFECT says "the ACL grants AllUsers read access." REMEDIATION says "remove public access." Neither tells the engineer which line to edit and what to put there.

The engineer opens the console, finds the bucket, reads the ACL, identifies the grant, figures out the fix. Per finding. Fifty times a week.

We added a DELTA section that answers the question directly:

  DELTA:
    Change: bucket ACL grantee
    Current: AllUsers
    Fix: change to any value other than AllUsers,
         or remove the grant

The engineer reads the delta, edits the configuration, re-runs. No console. No manual investigation. The finding told them what to change.

1. The delta comes from the predicate

The delta isn't authored. Nobody wrote "change bucket ACL grantee" for this control. It's derived mechanically from the same predicate that produced the finding.

Every control has a predicate — the condition it checks against observation data. For CTL.S3.PUBLIC.001, the predicate is:

storage.access.acl.grants[].grantee == "AllUsers"

This predicate has three components:

Property path: storage.access.acl.grants[].grantee
Operator: ==
Value: "AllUsers"

The finding fires because the property has a value matching the predicate. The delta inverts this: what change to the property would make the predicate stop matching?

== "AllUsers"  →  "change to any value other than AllUsers"
== true        →  "set to false (disable)"
== false       →  "set to true (enable)"
contains "X"   →  "remove X from the list"
> 90           →  "reduce to 90 or below"

Each operator has a natural inverse. The inverse, applied to the observed value, is the counterfactual fix.

2. Why it's a counterfactual, not advice

The REMEDIATION field is advice. It's authored by a human who understands the vulnerability: "Remove public access from the bucket ACL." Good advice. Generic. The same text for every bucket that triggers this control, regardless of the specific configuration.

The DELTA field is a counterfactual. It's derived from the specific observation data the engine evaluated:

DELTA:
  Change: bucket ACL grantee
  Current: AllUsers          ← YOUR bucket has this now
  Fix: change to any value   ← this makes YOUR finding
       other than AllUsers      disappear

Advice says "you should probably do X." A counterfactual says "if you do X, this specific finding provably disappears." We verified this: modify the observation data per the delta's suggestion, re-run Stave, finding eliminated. The delta isn't a recommendation. It's a mechanical fact about the predicate.

This is Andreas Zeller's counterfactual causality applied to configuration: "if this value were different, the failure would not occur." The delta computes the minimal difference.

3. Walking the predicate AST

Our predicates aren't strings. They're structured trees — parsed and typed before evaluation. The derivation walks the tree, not a regex.

func DeriveDelta(pred *UnsafePredicate, observed []ObservedProperty) []DeltaPath {
    var paths []DeltaPath
    for _, clause := range pred.Misconfigurations {
        if isKindGate(clause) {
            continue // scope condition, not actionable
        }

        label := registry.Label(clause.PropertyPath)
        if label == "" {
            continue // unlabeled path, skip rather than show schema names
        }

        current := findObserved(observed, clause.PropertyPath)
        fix := invertOperator(clause.Operator, clause.Value)

        paths = append(paths, DeltaPath{
            PropertyLabel: label,
            CurrentValue:  current,
            FixAction:     fix,
        })
    }
    return paths
}

Three moving parts:

The property registry. Maps schema paths to human-readable labels. storage.access.acl.grants[].grantee becomes "bucket ACL grantee." Authored once for the observation schema (~150 hand-tuned labels), with an algorithmic fallback that handles the rest by stripping namespaces and expanding abbreviations. Covers 99.6% of controls.

The operator inverter. Maps each operator to its counterfactual phrase. == becomes "change to any value other than." contains becomes "remove from the list." > N becomes "reduce to N or below." Boolean-aware: == true becomes "set to false (disable)" not "change to any value other than true."

The observed-value lookup. Pairs each predicate clause with the actual value the engine read during evaluation. The delta shows what YOUR configuration has, not what the predicate checks in the abstract.

4. Compound predicates: independent fix paths

Simple predicates produce one delta. Compound predicates (AND) produce multiple independent fix paths:

Finding: CTL.IAM.ESCALATION.001
  Asset: arn:aws:iam::123456:role/DeployerRole

  DEFECT:
    The role grants iam:PassRole and
    lambda:InvokeFunction without resource
    constraints.

  DELTA:
    Any ONE of these changes eliminates this finding:

    1. role permissions
       Current: [iam:PassRole, lambda:InvokeFunction, ...]
       Fix: remove iam:PassRole from the list

    2. role permissions
       Current: [iam:PassRole, lambda:InvokeFunction, ...]
       Fix: remove lambda:InvokeFunction from the list

The predicate is permissions contains "iam:PassRole" AND permissions contains "lambda:InvokeFunction". Both clauses must be true for the finding to fire. Negating either one eliminates the finding. The delta shows both options; the engineer picks whichever is cheaper.

This is the practical value of walking the AST. A string-based approach would have to parse "A AND B" with regex. The AST already has the conjunction structure — each child of an AND node is an independent fix path.

5. What the derivation skips

Not every predicate clause produces a useful delta:

Kind-gates. Many predicates start with a scope condition: asset.kind == "bucket". This isn't an actionable defect — you can't "change the asset kind" to fix a security issue. The derivation filters these out. Any clause matching *.kind == value or *.type == value is a scope condition, not a delta candidate.

Parameter references. Some predicates compare against configurable thresholds: password_length < $min_length. The threshold is a parameter, not a fixed value. The delta for these would be "increase to at least $min_length" — useful but requires resolving the parameter. Skipped in the current implementation; the REMEDIATION field covers these cases with authored guidance.

Complex OR branches. AND predicates produce independent fix paths (fix any one). OR predicates require fixing all branches (any one independently triggers the finding). The rendering for "ALL of these changes are needed" is less intuitive than "any ONE." Currently skipped — OR predicates show no DELTA section and fall back to REMEDIATION.

Unlabeled property paths. If the property registry doesn't have a human-readable label for a path, the derivation skips it rather than showing raw schema names like identity.credentials.access_key.last_rotated. Schema paths in user-facing output look like implementation leaking through. Better to show nothing than to show noise.

6. Coverage without authoring

The derivation covers 672 of 675 controls. No per-control authoring. The same three inputs — property registry, operator inverter, observed values — produce deltas for every control whose predicate the AST walker can handle.

Compare with the defect description, which uses the same infrastructure:

Output section	Source	Coverage	Authoring needed
DEFECT	Predicate-derived or per-control override	672/675 (99.6%)	~150 registry labels (one-time)
INFECTION	Family template or per-control override	675/675	47 family templates
FAILURE	Family template or per-control override	675/675	47 family templates
OBSERVED	Engine property-access trace	675/675	Zero
DELTA	Predicate-derived counterfactual	672/675 (99.6%)	Zero (uses defect registry)

The DELTA section reuses the property registry from defect derivation. Authoring the registry once serves both purposes. The operator inverter is ~30 lines of Go. The AST walker is shared with defect derivation.

Total new code for the delta: the inverter function and the rendering. The infrastructure was already built.

7. Verifying the counterfactual

A delta that says "change X to Y" but doesn't eliminate the finding is worse than no delta at all. The user follows the suggestion, re-runs, and the finding persists. Trust is destroyed.

We verified the counterfactual by testing it:

Run Stave against a fixture → finding fires, delta says "change public_read to false"
Modify the observation: set public_read to false
Re-run Stave → finding eliminated

The delta's suggestion genuinely eliminates the finding. This isn't a proof for every possible observation (the predicate logic guarantees it — negating any clause in an AND predicate makes the conjunction false), but running it confirms the derivation doesn't have bugs the logic guarantees shouldn't exist.

When to add counterfactual output

The pattern applies to any tool that evaluates conditions against data:

Linters that flag rule violations can show "change this token/value to eliminate the warning." The lint rule's AST encodes what it checks; the inverse is the fix.
Policy engines that evaluate policies against configurations can show "this policy clause fails because of this value; changing it to X makes the policy pass."
Compliance scanners that check controls against evidence can show "this control fails because this property is X; the control passes when the property is Y."
Validators that check schemas against data can show "this field fails validation because its value is X; valid values are Y."

The common prerequisite: the tool's rules must be structured (AST, typed predicates, parsed expressions) rather than opaque (arbitrary code, black-box functions). If you can walk the rule's structure, you can invert it. If the rule is a function pointer, you can't.

Reducing the Triage Time

Most security tools stop at detection. They tell you what's wrong. Some add remediation — authored advice about what to do. Very few tell you the specific, mechanically-verified change that eliminates the specific finding on your specific configuration.

The gap between "this bucket is public" and "change grants[0].grantee from AllUsers to a restricted principal" is where triage time lives. The first is a finding. The second is an action. Engineers act on actions, not findings.

The delta closes that gap without per-rule authoring. The predicate already knows what it checks. The observation already records what exists. The counterfactual is the mechanical inverse of the match. The only work is building the inversion — once — and letting it scale to every rule in the catalog.

Your security tool already knows why the finding fired. It should tell the user what to change.

The code discussed in this article is from Stave, an open-source security CLI that evaluates cloud configurations against a catalog of controls.

AWS patched the logging. Your data already left.

Bala Paranj — Wed, 22 Apr 2026 12:57:36 +0000

Varonis found that anonymous S3 requests via VPC endpoints were invisible to CloudTrail. AWS added logging. But logging is reactive — by the time you see the entry, the attacker's upload is complete. The endpoint policies that allow the attack are still wide open.

Forensic evidence doesn't undo a breach

In April 2026, Varonis Threat Labs disclosed a finding that should concern every organization running VPC endpoints for S3: anonymous requests made through VPC endpoints did not appear in CloudTrail Network Activity events. Regardless of whether the bucket's permissions allowed or denied the request — no logs.

An attacker who compromised an application server inside a private VPC could use the existing VPC endpoint to connect to an external S3 bucket they controlled. Upload sensitive data. Download malware. All without generating a single log entry in the source account.

AWS responded by patching CloudTrail to log anonymous API requests via VPC endpoints as Network Activity events. The industry treated this as resolution.

It isn't. A murder has occurred. AWS's patch ensures there's now forensic evidence at the scene — fingerprints, DNA, security camera footage. That evidence helps investigators reconstruct what happened. It doesn't bring the victim back. It doesn't prevent the next crime.

Logging is forensics. The breach already happened. The data already left your account. The attacker already has it. The log entry tells you what was taken, when, and through which endpoint — after the fact. Your incident response team writes a better post-mortem. Your data is still gone.

The VPC endpoint policies that allow the attack — permissive defaults, no anonymous-request deny, no bucket restriction — are unchanged by the patch. These prevent the crime. And they're still wide open in most accounts.

1. Two misconfigurations enable the attack. A third makes it invisible.

The Varonis scenario has two layers — the attack itself and the evasion of detection. They're different problems with different fixes.

The attack requires two conditions:

The VPC endpoint policy didn't deny anonymous requests. Most organizations deploy VPC endpoints for S3 with default or permissive policies. The default policy allows all actions by all principals — including unsigned, anonymous requests. Unless the endpoint policy explicitly denies requests without authentication, anonymous access passes through.

The VPC endpoint policy didn't restrict target buckets. Without a Resource restriction in the endpoint policy, any S3 bucket globally — including attacker-controlled buckets — is reachable through the organization's endpoint. The endpoint becomes a bidirectional channel to the entire S3 namespace.

These two misconfigurations are the attack surface. Fix either one and the attack fails — deny anonymous requests OR restrict target buckets. The attacker can't exfiltrate data if they can't make anonymous requests, and they can't reach their own bucket if the endpoint restricts targets.

The invisibility requires a third condition:

Network Activity event logging wasn't enabled. Even after AWS's patch, anonymous requests appear as Network Activity events only if the customer has this event type enabled on their CloudTrail trail. Without it, the attack proceeds AND leaves no forensic trail.

But here's what matters: enabling Network Activity logging doesn't prevent the attack. It's installing security cameras in a building with no locks. The cameras record the intruder walking in, taking what they want, and leaving. Excellent footage. The intruder still took everything.

The distinction is fundamental: fixing endpoint policies prevents the breach. Enabling logging documents the breach for your incident response team. Both are necessary. They are not interchangeable. And only one of them keeps your data in your account.

2. What AWS patched vs. what prevents the breach

AWS's response addressed forensics: anonymous API requests via VPC endpoints now generate Network Activity events. Before the patch, the crime was invisible. After the patch, the crime scene has evidence.

Evidence doesn't prevent crime. The distinction:

Component	Layer	Effect	AWS patched?
VPC endpoint denies anonymous requests	Prevention	Attacker can't make the request	No
VPC endpoint restricts target buckets	Prevention	Attacker can't reach their bucket	No
VPC endpoint requires IAM conditions	Prevention	Attacker can't act anonymously	No
CloudTrail logs anonymous VPC requests	Forensics	You learn about the breach afterward	Yes
Monitoring alerts on anonymous access	Forensics	You're notified about the breach afterward	No

AWS patched one forensics row. The three prevention rows — the ones that stop data from leaving — are configuration you own, unchanged by the patch.

An organization that enables logging will have a well-documented breach report. An organization that fixes its endpoint policies won't need one.

3. Detecting the misconfigurations that enable the crime

Prevention means finding the unlocked doors before the intruder walks through them. Five controls detect the component conditions — each a YAML predicate the evaluation engine processes. The controls identify which doors are open so they can be locked. No Varonis-specific engine code; the same engine that evaluates 700+ other security controls processes these identically.

Endpoint anonymous access. A control checks whether the VPC endpoint policy explicitly denies unsigned requests. If it doesn't, the endpoint allows anonymous S3 access — the first link in the attack.

The finding tells the operator exactly what's wrong:

DEFECT:
  The VPC endpoint policy does not deny anonymous
  (unsigned) requests. Unauthenticated S3 requests
  can transit the endpoint without identity
  information.

DELTA:
  Change: endpoint policy denies anonymous
  Current: false
  Fix: set to true (enable)

The DELTA section is mechanically derived from the control's predicate — it tells the operator the specific configuration change that eliminates this finding. Not generic advice; a verified counterfactual.

Endpoint target bucket restriction. A second control checks whether the endpoint policy restricts which S3 buckets are reachable. Without this restriction, the endpoint is a channel to any bucket globally — including attacker-controlled ones.

Endpoint IAM conditions. A third control checks whether the endpoint policy requires IAM conditions (aws:PrincipalArn or aws:PrincipalOrgID) on all requests. Without conditions, any principal — including anonymous ones — can use the endpoint.

Network Activity event logging. A fourth control verifies that CloudTrail Network Activity events are enabled. Without this, the organization has no forensic trail even after AWS's patch — anonymous requests complete successfully and leave no record. Enabling logging doesn't stop the attack; it produces evidence for post-breach investigation.

Anonymous access alerting. A fifth control verifies that CloudWatch alarms are configured to detect anonymous VPC endpoint requests. Even with logging enabled, without alarms the log entries sit unread — the breach is documented but nobody is notified.

The compound chain. Three of the five controls compose into a chain representing the full Varonis scenario. The chain fires when all three member controls find issues on related assets — the attack surface is open AND invisible:

Chain: vpc_endpoint_evasion
  Escalation threshold: 3 (all must fire)
  Members:
    1. Endpoint allows anonymous requests
    2. Endpoint allows any target bucket
    3. No Network Activity event logging

The chain models the complete Varonis disclosure: anonymous requests pass through the endpoint (member 1), reach any bucket including attacker-controlled ones (member 2), and leave no log entries (member 3). Findings on the chain get a ChainBonus multiplier on their ExposureScore, surfacing them above individual findings.

The prevention/forensics distinction still applies to the operator's response: fixing either endpoint policy control (member 1 or 2) prevents the breach; enabling logging (member 3) helps investigate if prevention fails. The chain surfaces all three together so the operator sees the full picture and locks the doors before worrying about the cameras.

4. What the operator sees — and does

An operator running the scan against their VPC infrastructure sees the full context per finding — not just "something is wrong" but the complete chain from misconfiguration to consequence, with the specific change that prevents the breach:

DEFECT — what specifically is misconfigured. The unlocked door. Mechanically derived from the control's predicate against their actual observation data.

INFECTION — how the misconfiguration enables attack. What happens if the door stays unlocked. Authored per control, explaining the specific mechanism.

FAILURE — worst-case outcome. What the attacker achieves.

OBSERVED — which properties the engine consulted. The operator can verify the finding against their own configuration.

DELTA — the minimum change that prevents this specific breach path. Not generic advice — a verified counterfactual. "Change this property from X to Y and this finding disappears." The operator applies the delta, re-runs, confirms the door is locked.

The operator doesn't research the vulnerability. They don't read the Varonis disclosure to understand the attack path. They don't manually inspect their VPC endpoint policies. The finding carries the context to decide and the delta to act. Prevention happens at the terminal, not after a research cycle.

5. Why compound detection matters here

A scanner that checks VPC endpoint policies individually might flag "endpoint policy is permissive" as a medium-severity finding. An operator with 200 security findings triages it below the critical and high items. It sits in the backlog.

But "permissive endpoint policy" alone doesn't convey the risk. The risk is "permissive endpoint policy AND unrestricted bucket targets" — together enabling data exfiltration through the endpoint. Add "no Network Activity logging" and the exfiltration is invisible. Each component is low-to-medium severity alone. Together they're an undetectable exfiltration channel.

Compound chain detection surfaces the combination. The three chain-member findings are linked, their ExposureScores are boosted by ChainBonus, and the operator sees them as one triage unit.

The operator's response follows the prevention/forensics layers:

Prevention: "Fix either endpoint policy control to prevent the breach. Deny anonymous requests OR restrict target buckets. Either one locks the door the attacker would walk through."

Forensics: "Enable Network Activity logging and configure alerts. If prevention fails or another path exists, this gives your incident response team the evidence to scope the damage. It doesn't prevent the damage."

Prevention first. Forensics as the fallback. The chain surfaces both so the operator addresses prevention before spending time on logging configuration.

6. Prevention at catalog speed, not code speed

The implementation for the Varonis scenario contains zero engine modifications. Five YAML control definitions, five triage override files, one chain definition, and ten test fixtures. The evaluation engine processes them identically to every other control in the 700+ control catalog.

This matters because novel attack vectors appear continuously. If responding to each one required custom engine code — new parsers, new evaluation paths, specialized handling — prevention would lag behind disclosure by weeks or months. Instead, the catalog is the extension mechanism. A new attack vector means new YAML files describing what to prevent, not new Go code changing how prevention works.

The Varonis disclosure was published. Within the same development cycle, five controls detecting every component of the attack were authored, tested, and deployed. The engine that runs them didn't change. Prevention keeps pace with disclosure because the catalog is the boundary, not the codebase.

7. The configuration lifecycle

The Varonis disclosure illustrates a pattern that repeats across cloud security:

A platform capability (VPC endpoints) ships with permissive defaults
Organizations adopt it without tightening the defaults
A researcher discovers the permissive configuration enables attack
The platform patches the forensics layer (logging)
The underlying misconfiguration remains the customer's responsibility

Steps 1-4 happen once. Step 5 is ongoing. Every VPC endpoint deployed before the organization learns about this disclosure has the default permissive policy. Every new endpoint deployed by a team that hasn't updated their templates inherits it.

Prevention that runs continuously — not once after reading a disclosure but on every scan — catches both existing misconfigurations and new ones introduced by teams deploying endpoints without the updated policy. The scan finds the unlocked doors before the attacker does. That's the difference between prevention and forensics: prevention is proactive and repeatable. Forensics is reactive and too late.

8. Applying this to your environment

Two actions prevent the breach. Two actions help you investigate after one.

Prevent: Audit your endpoint policies. Check whether each endpoint's policy explicitly denies anonymous requests and restricts target buckets to your organization's S3 resources. Default policies don't include either restriction. Fixing either one prevents the Varonis scenario entirely — an attacker can't exfiltrate anonymously through an endpoint that requires authentication, and can't reach their own bucket through an endpoint that restricts targets. This is the lock on the door.

Prevent: Add IAM conditions. Require aws:PrincipalArn or aws:PrincipalOrgID on endpoint policies. This ensures every request through the endpoint carries verified identity — closing the anonymous access path at the policy layer. No identity, no access.

Investigate (after the fact): Enable Network Activity events. Verify your CloudTrail trails are configured to log Network Activity events for VPC endpoints. This doesn't prevent anything — the data leaves before the log is written. But when prevention fails (misconfigured endpoint, new attack path, insider threat), the forensic trail is the difference between "we know what was taken" and "we have no idea."

Investigate (after the fact): Monitor for anonymous access. Configure CloudWatch metric filters or EventBridge rules to alert on anonymous requests through VPC endpoints. Logging without monitoring means nobody reads the evidence until the breach is discovered through other means — customer complaints, dark web listings, regulatory notification.

Prevention keeps your data in your account. Forensics helps you write the incident report. Do both. But if you can only do one thing today, fix the endpoint policies.

The uncomfortable truth

AWS's patch was necessary. Before it, the attack was invisible. After it, the attack is logged. That's progress — from no evidence to forensic evidence.

But forensic evidence doesn't undo a breach. The crime has occurred. The data is gone. The attacker has disappeared. Your incident response team has excellent logs to reconstruct what happened. They can tell you exactly which endpoint was used, which bucket received the data, and when the exfiltration completed. The post-mortem will be thorough. None of it brings the data back.

Security tools that focus on logging and alerting are building better forensics. They help you investigate faster. They don't prevent the breach.

Prevention means finding the misconfigured endpoint policy before the attacker does. Identifying that anonymous requests are allowed before they're exploited. Flagging the unrestricted bucket target before data transits through it. Prevention is the lock on the door. Forensics is the camera that records someone walking through an unlocked one.

AWS fixed the camera. The doors are still unlocked. That's the gap this tool closes.

Prevention for the Varonis "Invisible Footprint" scenario is implemented in Stave, an open-source security CLI that finds misconfigurations before attackers do. Five controls detect the unlocked doors. The vpc_endpoint_evasion chain surfaces them as one triage unit so teams fix the prevention gaps first.

Design by Contract in Go: Panics, Preconditions, and checkContracts()

Bala Paranj — Tue, 21 Apr 2026 11:18:40 +0000

How panic for programming errors, error for user input, CONTRACT comments, checkContracts() invariant methods, and sorted-slice preconditions create a defense layer that catches bugs before they corrupt security verdicts.

Your function receives a time value. It computes a duration. The duration is negative. The comparison says "exposure is less than the threshold." The control passes. The bucket is public. The security verdict is wrong.

This happened because the caller passed now as a time before the exposure window started — a programming error, not a user input error. The function should have refused to compute with an impossible input.

Design by Contract gives you three tools to prevent this:

Preconditions: what must be true before a function runs
Postconditions: what must be true after a function returns
Invariants: what must always be true about an object's state

Go doesn't have language-level contracts. But you can enforce them with panics, errors, and methods — each for a different kind of violation.

The Decision: Panic vs Error vs Ignore

Before writing any contract check, answer one question: who caused the violation?

Violator	Response	Go Mechanism
The programmer (impossible state, broken invariant)	Crash immediately — this is a bug	`panic("contract violated: ...")`
The user (bad input, missing file, invalid config)	Return an error — this is expected	`return fmt.Errorf(...)`
Neither (optional field, empty collection, zero value)	Accept and handle gracefully	Default value or early return

This distinction is the foundation. Mixing them up creates either a tool that crashes on bad user input (terrible UX) or a tool that silently continues with corrupted state.

1. Constructor Preconditions — Panic for Programming Errors

The Problem

An ExposureLifecycle tracks how long a cloud resource has been unsafe. It requires a non-empty asset ID — without one, the lifecycle can't be correlated to anything. An empty ID is not "missing input" — it's a programming error in the code that constructs the lifecycle.

The Contract

func NewExposureLifecycle(a Asset) *ExposureLifecycle {
    if a.ID.IsEmpty() {
        panic("contract violated: NewExposureLifecycle requires non-empty asset ID")
    }
    return &ExposureLifecycle{ID: a.ID, asset: a}
}

Why panic, not error: The caller is internal code (the evaluation engine), not the user. If the engine constructs a lifecycle with an empty asset, that's a bug — the engine should have validated the asset before reaching this point. Returning an error would force every caller to handle a condition that should never happen.

Why not silently default: Returning a lifecycle with an empty ID would propagate the bug further — findings would be generated with no asset correlation, reports would have empty IDs, and the researcher would see "violations for asset (empty)" with no way to trace back to the source.

The panic message format: "contract violated: <what was expected>". This format is grep-able. Every contract violation in the codebase starts with "contract violated:" — you can find them all with one search.

2. Invariant Checking — checkContracts() After Mutation

The Problem

ObservationStats tracks observation timestamps incrementally. After each RecordObservation() call, three invariants must hold:

observationCount >= 0
firstSeenAt <= lastSeenAt (when count > 0)
coverageSpan == lastSeenAt - firstSeenAt

If any of these break, every duration calculation that uses the stats will produce wrong results. The security engine will compute wrong exposure durations, wrong SLA comparisons, wrong verdicts.

The Contract

// CONTRACT: coverageSpan is always derived from (lastSeenAt - firstSeenAt).
// CONTRACT: out-of-order timestamps are ignored.
type ObservationStats struct {
    firstSeenAt      time.Time
    lastSeenAt       time.Time
    maxGap           time.Duration
    coverageSpan     time.Duration
    observationCount int
}

func (s *ObservationStats) RecordObservation(t time.Time) error {
    if t.IsZero() {
        return ErrZeroTimestamp
    }

    s.observationCount++

    if s.observationCount == 1 {
        s.firstSeenAt = t
        s.lastSeenAt = t
        s.checkContracts()
        return nil
    }

    // Out-of-order timestamps are silently ignored (CONTRACT comment above)
    if t.Before(s.firstSeenAt) {
        s.checkContracts()
        return nil
    }

    gap := t.Sub(s.lastSeenAt)
    if gap > s.maxGap {
        s.maxGap = gap
    }
    s.lastSeenAt = t
    s.coverageSpan = s.lastSeenAt.Sub(s.firstSeenAt)

    s.checkContracts()
    return nil
}

// checkContracts panics on invariant violations that indicate a programming error.
func (s *ObservationStats) checkContracts() {
    if s.observationCount < 0 {
        panic("contract violated: ObservationStats.observationCount must be >= 0")
    }
    if s.observationCount > 0 && s.firstSeenAt.After(s.lastSeenAt) {
        panic("contract violated: ObservationStats.firstSeenAt must be <= lastSeenAt when count > 0")
    }
}

Why Check After Every Mutation

checkContracts() is called at the end of RecordObservation() — after every state change. This catches bugs at the point of corruption, not hours later when a downstream function produces a wrong result.

Without the check, a bug that sets firstSeenAt after lastSeenAt would silently produce a negative coverageSpan. The coverage validator would see "coverage span is -24 hours, which is less than the required 168 hours" and mark the evaluation as inconclusive. The researcher would see "insufficient observation coverage" and think they need more data, when actually the engine has a bug.

With the check, the panic fires immediately: "contract violated: firstSeenAt must be <= lastSeenAt". The developer sees the exact invariant that broke and can trace it to the mutation that caused it.

3. Precondition Errors — For User-Facing Boundaries

The Problem

The Assessor needs a Clock to compute deterministic timestamps. If no clock is provided, the assessor can't function. But this isn't a programming error in all cases — it could be a configuration mistake by the user (forgetting --now in a test script).

The Contract

func (a *Assessor) Assess(inventory []asset.Snapshot, opts ...AssessmentOptions) (evaluation.ComplianceReport, error) {
    if a.Clock == nil {
        return evaluation.ComplianceReport{}, errors.New("precondition failed: Assessor requires a Clock")
    }
    // ...
}

Why error, not panic: The Assessor is constructed by the app layer, which wires dependencies from user configuration. A missing clock could be a wiring bug or a missing --now flag. Returning an error gives the caller a chance to show a helpful message: "the --now flag is required for deterministic evaluation."

Why "precondition failed" prefix: Same grep-ability as "contract violated". Different prefix signals different severity — "contract violated" means "fix the code," "precondition failed" means "fix the configuration."

The Lifecycle Precondition

func (l *ExposureLifecycle) ExposureDuration(now time.Time) (time.Duration, error) {
    if l.activeWindow == nil || !l.activeWindow.IsActive() {
        return 0, nil  // No active exposure — zero duration is correct
    }
    if now.Before(l.activeWindow.OpenedAt()) {
        return 0, fmt.Errorf("exposure duration: 'now' (%s) must not be before window start (%s)",
            now.Format(time.RFC3339), l.activeWindow.OpenedAt().Format(time.RFC3339))
    }
    return now.Sub(l.activeWindow.OpenedAt()), nil
}

This is the function that would produce a negative duration if now is before the window start. Instead of silently returning a negative number (which would pass threshold comparisons), it returns an error with both timestamps — the caller can diagnose why now is wrong.

4. CONTRACT Comments — The Human Contract

The Pattern

// CONTRACT: only resolved windows are archived.
func (h *ExposureHistory) Record(w ExposureWindow) {
    if w.IsActive() {
        return  // Silently ignore active windows — they're not archivable
    }
    // ... archive the resolved window
}

// CONTRACT: Property paths are dot-separated breadcrumbs (e.g., "properties.cpu.cores").
func diffProperties(before, after map[string]any, path string) []PropertyChange {
    // ...
}

// Items MUST be sorted by CapturedAt ascending (oldest first). The function
// exits early once it encounters an item newer than the cutoff.
func PlanPrune(items []Candidate, criteria Criteria) []Candidate {
    // ...
}

// CONTRACT: vs // MUST: Both express preconditions. CONTRACT: documents structural invariants (data shape, ownership rules). MUST documents caller obligations (sort order, non-nil values).

These comments don't enforce anything at runtime. They're contracts between the author and future maintainers. When a function says // Items MUST be sorted by CapturedAt ascending, the caller is responsible for sorting. If they don't, the function produces wrong results — silently.

When to Upgrade a Comment to a Check

If the contract violation:

Corrupts security verdicts → runtime check (error or panic)
Produces wrong but non-dangerous output → comment only
Is caught by the type system → neither (the compiler enforces it)

The PlanPrune function has a sort-order precondition but no runtime check. Adding a sort-order check would cost O(n) per call. The comment documents the contract; the caller (PlanPrune is called from one place) is audited manually.

The ExposureLifecycle constructor has a non-empty-ID precondition with a runtime panic. An empty ID corrupts findings — it's worth the check.

5. Postcondition Guarantees — Deterministic Output

The Problem

The evaluation engine processes controls × assets. The iteration order of maps in Go is non-deterministic. If findings are appended in iteration order, two runs with identical inputs produce different output — different finding order, different JSON, different hashes.

For a security tool, non-deterministic output destroys trust. "I ran the same command twice and got different results" is the end of credibility.

The Contract

func (s *assessmentSession) compileReport() evaluation.ComplianceReport {
    // POSTCONDITION: findings are sorted deterministically
    evaluation.SortFindings(s.collector.findings)

    // POSTCONDITION: exempted assets are sorted by ID
    slices.SortFunc(s.collector.exemptedAssets, func(a, b asset.ExemptedAsset) int {
        return cmp.Compare(a.ID, b.ID)
    })

    // POSTCONDITION: checks are sorted by control+asset
    slices.SortFunc(s.collector.checks, func(a, b evaluation.ResourceCheck) int {
        if c := cmp.Compare(a.ControlID, b.ControlID); c != 0 {
            return c
        }
        return cmp.Compare(a.AssetID, b.AssetID)
    })

    // ... assemble report from sorted data
}

func SortFindings(fs []Finding) {
    slices.SortFunc(fs, func(a, b Finding) int {
        return cmp.Or(
            cmp.Compare(a.ControlID, b.ControlID),
            cmp.Compare(a.AssetID, b.AssetID),
            cmp.Compare(a.Evidence.TemporalRisk, b.Evidence.TemporalRisk),
        )
    })
}

Three postcondition sorts enforce deterministic output. The compileReport function is the only place that assembles the final report — putting the sorts here guarantees that every report, regardless of how it was built, has deterministic ordering.

The Iteration Guard

The engine also sorts asset IDs before iterating:

func (s *assessmentSession) applyControl(ctl *policy.ControlDefinition, lifecycles map[asset.ID]*asset.ExposureLifecycle) {
    // PRECONDITION for deterministic evaluation order
    assetIDs := make([]asset.ID, 0, len(lifecycles))
    for id := range lifecycles {
        assetIDs = append(assetIDs, id)
    }
    slices.Sort(assetIDs)

    for _, id := range assetIDs {
        // Evaluate in deterministic order
    }
}

This is a precondition on the loop (sorted iteration) that guarantees a postcondition on the output (deterministic finding order). Without the sort, the same map with the same keys produces different iteration orders between runs.

6. Structural Invariant Panics — Catching Impossible States

The Pattern

func (s DriftSummary) matchesChangeCount(changeCount int) bool {
    total := s.provisioned + s.decommissioned + s.reconfigured
    if s.total != total {
        panic("structural contract violation: summary total mismatch")
    }
    return s.total == changeCount
}

DriftSummary has four counters: provisioned, decommissioned, reconfigured, and total. The invariant is that total == provisioned + decommissioned + reconfigured. If this is ever false, the counters are corrupted — some mutation incremented one counter but not another.

Why panic here: This is an "impossible state." The counters are private fields mutated only by Record(). If the invariant breaks, Record() has a bug. No amount of error handling downstream can fix a corrupted counter. The panic points directly at the corruption.

The Contract Hierarchy

Level	Mechanism	When to Use	Example
Type system	Compiler enforces it	Always, when possible	`kernel.ControlID` instead of `string`
Constructor panic	`panic("contract violated: ...")`	Impossible states from programming errors	Empty asset ID in lifecycle constructor
Invariant method	`checkContracts()` after mutation	State corruption that affects downstream logic	`firstSeenAt > lastSeenAt` in stats
Precondition error	`return fmt.Errorf(...)`	Missing configuration or invalid input	Assessor without a Clock
Postcondition sort	`slices.SortFunc(...)` before return	Non-deterministic output	Findings sorted before report assembly
CONTRACT comment	`// CONTRACT: ...`	Caller obligations not worth runtime checking	Sort-order precondition on PlanPrune

The hierarchy goes from strongest (type system — impossible to violate at runtime) to weakest (comment — relies on code review). Use the strongest mechanism that's practical for each contract.

When NOT to Use Contracts

// DON'T panic on user input
func ParseDuration(s string) (time.Duration, error) {
    // This is user input, not a programming error
    if s == "" {
        return 0, fmt.Errorf("empty duration")  // Error, not panic
    }
}

// DON'T check obvious things
func (s Status) String() string {
    // Status is an int enum — it's always valid by type system
    // No contract check needed
}

// DON'T check in hot loops
for _, finding := range findings {
    // Don't checkContracts() inside a loop that runs 1000 times
    // Check once after the loop if needed
}

Contracts have a cost — runtime panics add conditional branches, postcondition sorts add O(n log n) cost, and comment contracts add maintenance burden. Use them at trust boundaries (constructors, mutation methods, output assembly) and skip them inside trusted computation where the type system already provides guarantees.

These design-by-contract patterns are used in Stave, a Go CLI for offline security evaluation. The checkContracts() pattern catches state corruption at the point of mutation. The panic-vs-error distinction ensures programming errors crash immediately while user errors produce actionable messages.

The Most Important Refactoring Was Deleting 500 Lines I Was Proud Of

Bala Paranj — Mon, 20 Apr 2026 12:02:39 +0000

How I deleted a generic Pipeline[T] framework and a pass-through workflow layer, and why the codebase got better by having less code.

The hardest refactoring isn't adding something new. It's deleting something you built.

I built a generic Pipeline[T] framework for the output rendering layer of a Go CLI. It had a fluent API with NewPipeline().Then().Then().Error().Steps(). It had logging decorators. It had error recovery. It handled step sequencing with generics.

It was 500 lines of clever Go.

I deleted all of it and replaced it with 3 sequential function calls.

The Pipeline Framework

The output layer needed to: enrich evaluation results with remediation data, marshal the enriched data to JSON, and write it to stdout. Three steps. Sequential. No branching.

Here's what I built:

// BEFORE: Generic pipeline framework
type Pipeline[T any] struct {
    steps []Step[T]
    errFn func(error) error
}

func NewPipeline[T any]() *Pipeline[T] { ... }
func (p *Pipeline[T]) Then(fn func(T) (T, error)) *Pipeline[T] { ... }
func (p *Pipeline[T]) Error(fn func(error) error) *Pipeline[T] { ... }
func (p *Pipeline[T]) Execute(input T) (T, error) { ... }

// Usage
result, err := pipeline.NewPipeline[EvalResult]().
    Then(enrich).
    Then(marshal).
    Then(write).
    Error(decorateError).
    Execute(rawResult)

It looked elegant. It was reusable. It handled errors uniformly. It was a framework.

It was wrong.

Why It Was Wrong

1. Three steps don't need a framework

// AFTER: Three function calls
enriched, err := enrich(rawResult)
if err != nil {
    return decorateError(err)
}
marshaled, err := marshal(enriched)
if err != nil {
    return decorateError(err)
}
return write(marshaled)

6 lines. No generics. No framework. No learning curve. A junior developer reads this and understands it in 3 seconds.

2. The framework hid the error handling

In the pipeline version, decorateError was registered as a callback via .Error(). When debugging a marshaling failure, you had to trace through the pipeline's Execute method to understand when and how the error decorator was applied.

In the sequential version, decorateError(err) is right there at the call site. You can see it.

3. The framework prevented simple changes

When we needed to add a validation step between enrich and marshal — only for JSON format — the pipeline couldn't express it cleanly. We'd need conditional steps, or a pipeline builder that accepted format-dependent configurations.

In the sequential version:

enriched, err := enrich(rawResult)
if err != nil {
    return decorateError(err)
}
if format.IsJSON() {
    if err := validate(enriched); err != nil {
        return decorateError(err)
    }
}
marshaled, err := marshal(enriched)

An if statement. No framework changes needed.

The Pass-Through Layer

The same pattern appeared at a different level. An app/workflow package existed solely to forward calls:

// BEFORE: Pass-through package
package workflow

func RunEvaluation(deps Deps, cfg Config) (Result, error) {
    return domain.Evaluate(deps.Controls, deps.Snapshots, cfg.MaxUnsafe)
}

Every method in workflow called exactly one domain function with the same arguments. It added no logic, no validation, no transformation. It existed because "the architecture diagram has an app layer between cmd and domain."

// AFTER: Callers invoke domain directly
result, err := domain.Evaluate(controls, snapshots, maxUnsafe)

The entire package was deleted. One fewer layer to navigate, one fewer package to understand, one fewer indirection to trace.

How to Spot Premature Abstractions

The "what does this add?" test

For every abstraction layer, ask: "If I inline this, does the caller get simpler or more complex?"

Pipeline → inlining made callers simpler (3 sequential calls vs fluent chain)
Workflow → inlining made callers simpler (direct domain call vs wrapper)
Adapter → inlining would make callers more complex (CLI concerns would leak into domain)

The third one stays. The first two go.

The "second consumer" test

An abstraction earns its existence when the second consumer appears. The Pipeline framework had exactly one consumer. The workflow layer had exactly one caller per method. Neither had earned its abstraction.

The "grep test"

Search for the abstraction's type name. If every result is either the definition or a single usage, it's premature:

grep -rn "Pipeline\[" --include='*.go' | wc -l
# 2: one definition, one usage. Delete it.

The Lesson

The codebase needed fewer abstractions, not more.

The Pipeline was built because "we might need a complex output pipeline later." We didn't. The workflow layer was built because "hexagonal architecture requires an app layer." It doesn't — not when the app layer adds zero logic.

Both took significant effort to build and significant effort to remove. The build cost was visible (lines of code, review time). The ongoing cost was invisible (cognitive load, debugging indirection, onboarding friction) — until it wasn't.

Deleting your own clever code is the hardest skill in software engineering. It means admitting that the 500 lines you wrote, reviewed, and merged made the project worse, not better.

But 3 lines of sequential Go are more maintainable than a 500-line generic fluent API. Every time. It feels good to eliminate bloat in your codebase.

This was one of the big lessons learned during the development of Stave, an offline configuration safety evaluator.

We Forgot defer — 6 Resource Leaks We Found During Refactoring

Bala Paranj — Sun, 19 Apr 2026 12:07:11 +0000

We had a progress spinner. It animated on stderr while the evaluation ran. When the evaluation panicked, the spinner kept spinning. The terminal was corrupted. We had to reset the terminal every time.

The fix was one line: defer stop().

We found six patterns like this during a refactoring phase — resource leaks that only appeared under error conditions, panics, or signals. The happy path worked. The unhappy path leaked.

1. The Spinner That Survives a Panic

Before: Cleanup after computation

func (r *runner) Run(ctx context.Context, cfg config) error {
    stop := r.runtime.BeginProgress("Computing observation delta")

    delta, err := r.computeDelta(ctx, cfg.ObservationsDir, cfg.Filter)
    stop()  // <-- Never runs if computeDelta panics

    if err != nil {
        return err
    }
    return writeOutput(r.Stdout, cfg.Format, delta)
}

BeginProgress starts a goroutine that writes ANSI escape codes to stderr every 100ms. stop() sends a signal to the goroutine to stop and write the final "Done" message. If computeDelta panics, stop() is never called. The goroutine keeps running. The terminal keeps receiving escape codes. The panic message is interleaved with spinner frames.

After: defer guarantees cleanup

func (r *runner) Run(ctx context.Context, cfg config) error {
    stop := r.runtime.BeginProgress("Computing observation delta")
    defer stop()

    delta, err := r.computeDelta(ctx, cfg.ObservationsDir, cfg.Filter)
    if err != nil {
        return err
    }
    return writeOutput(r.Stdout, cfg.Format, delta)
}

defer stop() runs after the function returns — whether by normal return, error return, or panic. The spinner is always cleaned up.

But there's a subtlety: the stop function itself runs in a goroutine. If the goroutine panics (say, writing to a closed stderr), the panic propagates to the caller. Fix the goroutine too:

func (r *Runtime) BeginProgress(label string) func() {
    errOut := r.stderr()
    stopCh := make(chan struct{})

    go func() {
        defer func() {
            if r := recover(); r != nil {
                fmt.Fprintf(errOut, "\rprogress render panic: %v\n", r)
            }
        }()
        ticker := time.NewTicker(100 * time.Millisecond)
        defer ticker.Stop()
        for {
            select {
            case <-stopCh:
                return
            case <-ticker.C:
                fmt.Fprintf(errOut, "\r%s Running: %s...", frames[i%len(frames)], label)
                i++
            }
        }
    }()

    var once sync.Once
    return func() {
        once.Do(func() {
            close(stopCh)
            // ... write final "Done" message
        })
    }
}

Three layers of protection:

defer stop() in the caller guarantees the stop signal is sent
defer recover() in the goroutine prevents render panics from crashing the process
sync.Once in the stop function prevents double-close panics if stop is called multiple times

2. The Signal Handler That Skips Cleanup

Before: os.Exit skips all defers

func (a *App) installInterruptHandler() {
    sigCh := make(chan os.Signal, 1)
    signal.Notify(sigCh, os.Interrupt)

    go func() {
        <-sigCh
        fmt.Fprintln(os.Stderr, "Interrupted")
        os.Exit(130)  // <-- All deferred cleanup skipped
    }()
}

When the user hits Ctrl+C, os.Exit(130) terminates the process immediately. No deferred functions run. Open file handles aren't closed. Temp files aren't removed. Log files aren't flushed. CPU profile output is lost.

After: Context cancellation allows defer chain to complete

func (a *App) installInterruptHandler() func() {
    sigCh := make(chan os.Signal, 1)
    done := make(chan struct{})
    signal.Notify(sigCh, os.Interrupt, syscall.SIGTERM)

    go func() {
        defer func() {
            if r := recover(); r != nil {
                fmt.Fprintf(os.Stderr, "signal handler panic: %v\n", r)
            }
        }()
        select {
        case <-sigCh:
            fmt.Fprintln(os.Stderr, "Interrupted")
            if a.cancel != nil {
                a.cancel()  // Cancel context — operations unwind naturally
            }
        case <-done:
            return
        }
    }()

    return func() {
        signal.Stop(sigCh)
        close(done)
    }
}

The main execution path sets up deferred cleanup:

func (a *App) Execute(args []string) {
    cleanup := a.installInterruptHandler()
    defer cleanup()
    defer a.recoverExecutePanic()

    a.executeRootCommand(args)
    // All defers run whether command succeeds, fails, or is interrupted
}

Now Ctrl+C cancels the context. Operations check ctx.Err() and return errors. The normal return path runs all defers. File handles close. Temp files are removed. The exit code is set from the error chain, not hardcoded.

3. The Temp File That Outlives the Process

Before: Error paths skip cleanup

func WriteFileAtomic(path string, data []byte, perm os.FileMode) error {
    dir := filepath.Dir(path)
    tmp, err := os.CreateTemp(dir, ".stave-*.tmp")
    if err != nil {
        return err
    }
    tmpPath := tmp.Name()

    if _, err := tmp.Write(data); err != nil {
        tmp.Close()
        os.Remove(tmpPath)  // Manual cleanup on write error
        return err
    }
    if err := tmp.Sync(); err != nil {
        tmp.Close()
        os.Remove(tmpPath)  // Manual cleanup on sync error
        return err
    }
    if err := tmp.Close(); err != nil {
        os.Remove(tmpPath)  // Manual cleanup on close error
        return err
    }
    return os.Rename(tmpPath, path)
}

Four error paths. Each one manually closes and removes the temp file. If you add a fifth step (like Chmod), you must remember to add cleanup. Miss one path and temp files accumulate.

After: defer handles all cleanup paths

func WriteFileAtomic(path string, data []byte, perm os.FileMode) error {
    dir := filepath.Dir(path)
    tmp, err := os.CreateTemp(dir, ".stave-*.tmp")
    if err != nil {
        return err
    }
    tmpPath := tmp.Name()

    // Cleanup: remove temp file on ANY failure. On success, rename
    // moves it to the final path and remove becomes a no-op.
    closed := false
    defer func() {
        if !closed {
            tmp.Close()
        }
        os.Remove(tmpPath)
    }()

    if _, err := tmp.Write(data); err != nil {
        return fmt.Errorf("write: %w", err)
    }
    if err := tmp.Sync(); err != nil {
        return fmt.Errorf("sync: %w", err)
    }
    if err := tmp.Close(); err != nil {
        return fmt.Errorf("close: %w", err)
    }
    closed = true

    return os.Rename(tmpPath, path)
}

The closed flag prevents double-closing: tmp.Close() is called explicitly for the success path (so we can check its error), and the deferred tmp.Close() only runs if the explicit close wasn't reached.

os.Remove(tmpPath) in the defer always runs. On the success path, Rename already moved the temp file to its final name — Remove tries to delete the old path, which no longer exists, and silently fails. On error paths, the temp file is cleaned up.

Adding a new step (Chmod, Chown, etc.) requires zero cleanup code — the defer handles it.

4. The Mutex That Never Unlocks

Before: Error returns skip unlock

func (cp *CountedProgress) Update(processed, total int) {
    cp.mu.Lock()

    if processed < 0 || total < 0 {
        cp.mu.Unlock()
        return  // Must remember to unlock before every return
    }

    cp.processed = processed
    cp.total = total
    cp.render()

    cp.mu.Unlock()
}

Two unlock calls. If you add a third return path (say, for a cancelled context), you must add a third unlock. Miss one and the mutex deadlocks.

After: defer unlock is unconditional

func (cp *CountedProgress) Update(processed, total int) {
    cp.mu.Lock()
    defer cp.mu.Unlock()

    if processed < 0 || total < 0 {
        return  // Unlock runs automatically via defer
    }

    cp.processed = processed
    cp.total = total
    cp.render()
    // Unlock runs automatically via defer
}

One line. Every return path — including future ones added during refactoring — automatically unlocks.

5. The sync.Once That Replaced a Race

Before: Bool flag with race condition

type Progress struct {
    stopped bool
    ch      chan struct{}
}

func (p *Progress) Stop() {
    if p.stopped {
        return
    }
    p.stopped = true
    close(p.ch)
}

Two goroutines call Stop() concurrently. Both read p.stopped as false. Both set it to true. Both call close(p.ch). Second close panics: "close of closed channel."

After: sync.Once eliminates the race

type Progress struct {
    once sync.Once
    ch   chan struct{}
}

func (p *Progress) Stop() {
    p.once.Do(func() {
        close(p.ch)
    })
}

sync.Once guarantees the closure runs exactly once, regardless of how many goroutines call Stop() concurrently. No race. No double-close. No panic.

Combined with defer:

done := rt.BeginProgress("Evaluating controls")
defer done()  // done() uses sync.Once internally — safe to call twice

If the function calls done() explicitly (e.g., to stop the spinner before printing results) and then returns (triggering the deferred done()), sync.Once ensures the channel is closed only once.

6. The Future-Proof Cleanup Contract

Before: No cleanup mechanism

deps, err := builder.Build(ctx, plan)
if err != nil {
    return err
}
// ... use deps ...
// What if deps acquires resources later? No cleanup contract exists.

Today ApplyDeps holds only values — no file handles, no connections. But tomorrow you might add a database connection, a log file, or a metric exporter. Without a cleanup contract, the caller doesn't know it needs to release resources.

After: Establish the contract now, implement later

type ApplyDeps struct {
    Runner *AuditWorkflow
    Config AssessmentConfig
}

func (d *ApplyDeps) Close() {
    // No-op today. Future resources cleaned up here.
}

The caller:

deps, err := builder.Build(ctx, plan)
if err != nil {
    return err
}
defer deps.Close()
// ... use deps ...

defer deps.Close() runs whether the function succeeds or fails. When you add a file handle to ApplyDeps next month, the cleanup is already wired — you just add d.handle.Close() to the Close() method. No caller changes needed.

The Anti-Pattern: defer in Loops

The deferInLoop gocritic check catches this:

// BAD: defer accumulates — all files stay open until loop ends
for _, path := range files {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer f.Close()  // <-- Runs after the LOOP, not after the iteration

    process(f)
}
// If files has 1000 entries, 1000 file handles are open simultaneously

Fix: extract to a function where defer scopes correctly:

// GOOD: defer scopes to the function, which returns per iteration
for _, path := range files {
    if err := processFile(path); err != nil {
        return err
    }
}

func processFile(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer f.Close()  // Runs when processFile returns — per iteration
    return process(f)
}

Or use explicit close when the logic is simple:

for _, path := range files {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    err = process(f)
    f.Close()
    if err != nil {
        return err
    }
}

When We Added defer vs When We Should Have

Every defer we added during refactoring was a bug we shipped without. The happy path worked. The tests passed. But:

Resource	Happy Path	Panic/Error Path	Signal Path
Spinner stop	Worked	Leaked	Leaked
Signal cleanup	N/A	N/A	Skipped
Temp file remove	Worked	Leaked on some paths	Leaked
Mutex unlock	Worked	Deadlocked on new returns	N/A
Channel close	Worked	Panicked on double-close	Panicked

The pattern is consistent: we tested the success path. The failure path was invisible until a panic happened during development or a user hit Ctrl+C at the wrong moment.

The lesson: write defer on the line after resource acquisition. Not "later." Not "when we add error handling." Immediately. The cost is zero when everything works. The cost of forgetting is a corrupted terminal, a deadlocked process, or a temp directory full of orphaned files.

These 6 defer patterns were added during refactoring of Stave, a Go CLI for offline security evaluation. The deferInLoop gocritic check now prevents the most common defer mistake at CI time.

Value Objects, Entities, and Aggregates in Go — Without a Framework

Bala Paranj — Sat, 18 Apr 2026 12:19:26 +0000

Domain-Driven Design in Go doesn't look like DDD in Java. There are no annotations, no repository interfaces from a framework, no @Entity markers. The building blocks — Value Objects, Entities, and Aggregates — emerge from Go's type system and encapsulation rules.

Here's how each pattern appeared in a security CLI through refactoring, with the actual before/after code.

Value Objects: Equality by Content, Not Identity

A Value Object has no identity. Two instances with the same content are interchangeable. They're immutable, they validate at construction, and they carry domain behavior as methods.

Before: Raw Strings Everywhere

// BEFORE: ControlID is string — no validation, no behavior
type Finding struct {
    ControlID string `json:"control_id"`
    AssetID   string `json:"asset_id"`
}

// Any string is accepted. No validation. No domain methods.
f := Finding{
    ControlID: "not a valid id",
    AssetID:   "also anything",
}

After: kernel.ControlID Value Object

// AFTER: ControlID is a Value Object with validation and behavior
type ControlID string

var controlIDPattern = regexp.MustCompile(`^CTL\.[A-Z][A-Z0-9]*(\.[A-Z][A-Z0-9]*){1,}\.\d{3}$`)

func NewControlID(raw string) (ControlID, error) {
    if err := ValidateControlIDFormat(raw); err != nil {
        return "", err
    }
    return ControlID(raw), nil
}

// Domain behavior lives on the type
func (id ControlID) Provider() string {
    parts := strings.Split(id.String(), ".")
    if len(parts) < 2 { return "" }
    return parts[1]  // "CTL.S3.PUBLIC.001" → "S3"
}

func (id ControlID) Category() string { ... }  // → "PUBLIC"
func (id ControlID) Sequence() string { ... }  // → "001"

// JSON round-trip validates
func (id *ControlID) UnmarshalJSON(b []byte) error {
    var s string
    if err := json.Unmarshal(b, &s); err != nil { return err }
    val, err := NewControlID(s)
    if err != nil { return err }
    *id = val
    return nil
}

Value Object properties:

Equality by content: Two ControlID("CTL.S3.PUBLIC.001") are equal
Validated at construction: NewControlID rejects invalid formats
Immutable: ControlID is a string — no mutation methods
Domain behavior: Provider(), Category(), Sequence() extract meaning
Self-validating at boundaries: UnmarshalJSON validates on deserialization

The codebase has 12 Value Objects in the kernel package:

Value Object	Underlying	Domain Meaning
`ControlID`	`string`	Structured security control identifier
`AssetType`	`string`	Cloud resource category (s3_bucket, iam_role)
`Schema`	`string`	Schema version (obs.v0.1, ctrl.v1)
`Duration`	`time.Duration`	Human-formatted duration (7d, 24h)
`Vendor`	`string`	Cloud provider (aws, azure)
`Digest`	`string`	SHA-256 hex digest
`ObjectPrefix`	`string`	S3 key prefix with matching semantics
`NetworkScope`	`int`	Network boundary classification
`PrincipalScope`	`int`	Identity trust boundary
`TimeWindow`	`struct`	Start/end time pair with containment checks
`Severity`	`int`	Control severity with ordering
`Status`	`int`	Check result (Pass/Warn/Fail/Skipped)

kernel.Duration: A Value Object with Custom Serialization

// kernel.Duration wraps time.Duration with human-friendly formatting
type Duration time.Duration

func (d Duration) String() string { return FormatDuration(time.Duration(d)) }
// 168h → "7d", 36h → "1d12h", 1h → "1h"

func (d Duration) MarshalJSON() ([]byte, error) {
    return json.Marshal(d.String())  // Serializes as "7d", not 604800000000000
}

func (d *Duration) UnmarshalJSON(data []byte) error {
    var s string
    json.Unmarshal(data, &s)
    parsed, err := ParseDuration(s)  // Accepts "7d", "1.5d", "168h"
    *d = Duration(parsed)
    return err
}

Before: time.Duration serialized as "168h0m0s" in JSON. Users had to parse Go's duration format.
After: kernel.Duration serializes as "7d". ParseDuration accepts "7d", "1.5d", "1d12h" — human input formats.

Entities: Identity + Lifecycle

An Entity has a unique identity that persists across state changes. Two entities with the same data but different IDs are different entities. They have lifecycle methods that enforce state machine transitions.

Before: Flat Data Struct

// BEFORE: Flat struct with no lifecycle enforcement
type Timeline struct {
    AssetID       string
    Unsafe        bool
    UnsafeSince   time.Time
    LastChecked   time.Time
    EpisodeCount  int
}

// Caller manages state transitions manually
tl.Unsafe = true
tl.UnsafeSince = time.Now()
// What if caller sets Unsafe=true but forgets UnsafeSince?

After: ExposureLifecycle Entity

// AFTER: Entity with enforced state transitions
type ExposureLifecycle struct {
    ID    ID            // ← unique identity
    asset Asset         // ← private state

    activeWindow   *ExposureWindow   // ← lifecycle state
    lastObservedAt time.Time

    history ExposureHistory   // ← encapsulated history
    stats   ObservationStats  // ← encapsulated metrics
}

// Construction enforces identity invariant
func NewExposureLifecycle(a Asset) *ExposureLifecycle {
    if a.ID.IsEmpty() {
        panic("contract violated: requires non-empty asset ID")
    }
    return &ExposureLifecycle{ID: a.ID, asset: a}
}

// State transitions through methods — caller can't set fields directly
func (l *ExposureLifecycle) RecordCheck(a Asset, ts time.Time) { ... }
func (l *ExposureLifecycle) IsExposed() bool { ... }
func (l *ExposureLifecycle) IsSecure() bool { ... }
func (l *ExposureLifecycle) ExposureDuration() time.Duration { ... }
func (l *ExposureLifecycle) ExceedsSLA(max time.Duration) bool { ... }

// Read-only accessors return values, not pointers
func (l *ExposureLifecycle) Stats() ObservationStats { return l.stats }
func (l *ExposureLifecycle) History() ExposureHistory { return l.history }

Entity properties:

Identity: ID field persists across state changes
Lifecycle: RecordCheck drives the state machine — callers can't set activeWindow directly
Encapsulation: stats and history are private, returned by value (no pointer aliasing)
Contract enforcement: panic on empty ID at construction

The ExposureWindow that the lifecycle manages is itself a Value Object:

// ExposureWindow is a Value Object — no identity, immutable after creation
type ExposureWindow struct {
    openedAt   time.Time
    resolvedAt time.Time
    active     bool
}

func NewActiveWindow(openedAt time.Time) ExposureWindow {
    return ExposureWindow{openedAt: openedAt, active: true}
}

func (w ExposureWindow) Resolve(end time.Time) ExposureWindow {
    // Returns a NEW window — doesn't mutate
    return ExposureWindow{
        openedAt:   w.openedAt,
        resolvedAt: end,
        active:     false,
    }
}

func (w ExposureWindow) IsActive() bool { return w.active }
func (w ExposureWindow) OpenedAt() time.Time { return w.openedAt }
func (w ExposureWindow) DwellTime(now time.Time) time.Duration { ... }

ExposureWindow.Resolve() returns a new window — it doesn't mutate the existing one. This is the Value Object pattern: operations produce new values.

Aggregates: Consistency Boundary

An Aggregate is a cluster of objects treated as a unit. External code accesses the aggregate through its root. Internal state is protected by the root's methods.

ComplianceReport: The Root Aggregate

// ComplianceReport is the root aggregate of an evaluation execution.
type ComplianceReport struct {
    Run              RunInfo               `json:"run"`
    Summary          ComplianceSummary     `json:"summary"`
    SecurityState    SecurityState         `json:"security_state"`
    RiskSignals      risk.ThresholdItems   `json:"risk_signals,omitempty"`
    Findings         []Finding             `json:"findings"`
    ExceptedFindings []ExceptedFinding     `json:"excepted_findings,omitempty"`
    SkippedControls  []SkippedControl      `json:"skipped_controls,omitempty"`
    ExemptedAssets   []asset.ExemptedAsset `json:"exempted_assets,omitempty"`
    Checks           []ResourceCheck       `json:"checks,omitempty"`
}

The ComplianceReport is constructed by the Assessor (the evaluation engine). It contains:

Value Objects: RunInfo, ComplianceSummary, SecurityState
Entity collections: []Finding (each has a ControlID+AssetID identity pair)
Derived state: SecurityState is computed from findings + risk signals

Before: Fat Struct with Mixed Concerns

// BEFORE: Summary mixed counts, gating, and metadata
type Summary struct {
    TotalControls     int           // counting
    PassCount         int           // counting
    FailCount         int           // counting
    FailOn            Severity      // gating logic
    Gated             bool          // gating logic
    StaveVersion      string        // metadata
    EvidenceFreshness time.Duration // metadata
}

RecomputeSummary had to reset counts while preserving metadata — a recipe for bugs.

After: Split into Cohesive Value Objects

// AFTER: Three Value Objects, each with single concern
type ComplianceSummary struct {
    TotalAssets      int `json:"total_assets"`
    ExposedResources int `json:"exposed_resources"`
    Violations       int `json:"violations"`
}

type GatingInfo struct {
    FailOn            Severity
    Gated             bool
    GatedFindingCount int
}

type AuditMeta struct {
    VulnSourceUsed    string
    EvidenceFreshness time.Duration
    StaveVersion      string
}

Each is a Value Object — no identity, no lifecycle, just data. They compose into the aggregate without coupling their concerns.

The Assessor Builds the Aggregate

func (s *assessmentSession) compileReport() ComplianceReport {
    // Sort for deterministic output
    SortFindings(s.collector.findings)

    // Partition findings through exception rules
    activeFindings, exceptedFindings := partitionFindings(
        s.collector.findings, s.assessor.Exceptions, s.auditTime,
    )

    // Derive security state from findings + risk
    riskSignals := risk.ComputeItems(...)
    posture := DeriveSecurityState(len(activeFindings), riskSignals)

    // Construct the aggregate
    return ComplianceReport{
        Run:              RunInfo{...},
        Summary:          ComplianceSummary{...},
        SecurityState:    posture,
        RiskSignals:      riskSignals,
        Findings:         activeFindings,
        ExceptedFindings: exceptedFindings,
        SkippedControls:  s.collector.skippedControls,
        ExemptedAssets:   s.collector.exemptedAssets,
        Checks:           s.collector.checks,
    }
}

The aggregate is assembled inside the assessmentSession — a private type. External code receives the completed ComplianceReport and cannot modify the internal assessment state.

How These Map to Go Constructs

DDD doesn't need a framework in Go. The language provides everything:

DDD Concept	Go Construct	Example
Value Object	Defined type + methods	`kernel.ControlID`, `kernel.Duration`
Value Object equality	`==` on defined types	`id1 == id2`
Value Object immutability	Return new values from methods	`window.Resolve()` returns new `ExposureWindow`
Entity identity	ID field + constructor	`ExposureLifecycle{ID: a.ID}`
Entity lifecycle	Methods with state transitions	`RecordCheck()`, `IsExposed()`
Entity encapsulation	Unexported fields + value receivers	`stats ObservationStats` (private), `Stats()` returns copy
Aggregate root	Struct with composed value objects	`ComplianceReport{Summary, Findings, ...}`
Aggregate construction	Factory method in private session	`compileReport()` on `assessmentSession`
Invariant enforcement	`panic` on contract violation	`NewExposureLifecycle` panics on empty ID
Boundary validation	`UnmarshalJSON` with validation	`ControlID.UnmarshalJSON` rejects invalid formats

The Key Insight

In Go, the DDD building blocks aren't declared — they're enforced by the type system:

Value Objects are defined types with MarshalJSON/UnmarshalJSON and no mutation methods
Entities have private fields, construction invariants, and lifecycle methods
Aggregates are structs assembled by private factory methods that external code receives read-only

No framework needed. No annotations. No base classes. Just types, methods, and encapsulation.

These patterns evolved through 60 refactorings in Stave, an offline configuration safety evaluator. The kernel package contains 12 Value Objects. The asset package contains the ExposureLifecycle Entity. The evaluation package contains the ComplianceReport Aggregate.

Subdomain Takeover is Not Just Phishing: How Acronis Nearly Lost Authenticated API Access

Bala Paranj — Fri, 17 Apr 2026 12:46:34 +0000

Every subdomain takeover writeup ends the same way: "an attacker could host a phishing page under your trusted domain."

That is the low-severity version.

In 2020, a researcher discovered four Acronis subdomains pointing to unclaimed Marketo endpoints and found something more serious buried in the HTTP response headers of a completely different endpoint. The subdomain takeover was not the vulnerability. It was the key that unlocked one.

The Setup: Four Dangling CNAMEs

@ashmek ran subdomain enumeration against acronis.com and found four marketing subdomains all pointing to Marketo landing page infrastructure:

register.acronis.com    → acronis.mktoweb.com
promo.acronis.com       → acronis.mktoweb.com
promosandbox.acronis.com → acronissandbox2.mktoweb.com
info.acronis.com        → mkto-h0084.com

Each target returned 404. Each target was unclaimed. @ashmek confirmed with Marketo support that none of the listed domains were in use or configured anymore.

Standard subdomain takeover. Standard remediation: remove the CNAME records or reclaim the Marketo workspaces. At this point, severity is medium — phishing, content injection, brand impersonation.

Then they looked at the API response headers.

The Escalation: CORS With Credentials

While examining the Acronis account API at account.acronis.com, @ashmek intercepted a request and found this in the response:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://register.acronis.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Accept, Authorization, Content-Type, ...
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS

Access-Control-Allow-Origin: https://register.acronis.com with Access-Control-Allow-Credentials: true.

register.acronis.com is one of the four dangling subdomains. The one that is unclaimed on Marketo. The one any attacker can register right now.

The attack chain is now:

1. Attacker registers register.acronis.com on Marketo (free)
2. Attacker hosts malicious JavaScript on register.acronis.com
3. Victim visits register.acronis.com while logged into account.acronis.com
4. JavaScript calls account.acronis.com/v2/account with credentials
5. Browser sends the authenticated request — CORS policy allows it
6. account.acronis.com responds with the victim's account data
7. JavaScript reads the response — CORS + credentials = full access
8. Attacker exfiltrates account data, tokens, or session information

This is not phishing. The user does not need to enter their password on a fake form. They need only visit a subdomain that Acronis's own CORS policy trusts — a subdomain that anyone can claim.

Why this CORS Configuration is Dangerous

The browser's CORS model has one rule that matters here: when Access-Control-Allow-Credentials: true is set, the browser will include cookies and authorization headers in the cross-origin request. The response is readable by the requesting JavaScript.

This is explicitly why the spec prohibits Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true — the combination would allow any site to make authenticated API calls on behalf of the visitor. Browsers reject it.

But Access-Control-Allow-Origin: https://register.acronis.com is not a wildcard. It is a specific trusted origin. The browser allows it. The credentials are included. The response is readable.

The security assumption embedded in that CORS policy is: we control register.acronis.com. When that assumption is false — when the subdomain is unclaimed — the CORS policy has granted an arbitrary attacker the same cross-origin access that Acronis's own first-party applications have.

The Compound Vulnerability

Neither issue alone reaches this severity:

Dangling CNAME alone: medium — phishing, content injection
CORS with credentials alone: informative — only exploitable from a trusted origin
Together: high — authenticated cross-origin API access from an attacker-controlled page

This is the compound chain that individual controls miss. CTL.DNS.DANGLING.001 fires on the dangling CNAME. A CORS policy check fires on the Allow-Credentials: true configuration. Neither control alone captures the full attack path — only the combination does.

In Stave's compound chain model:

chain: subdomain_cors_credential_theft
members:
  - CTL.DNS.DANGLING.001       # CNAME points to unclaimed endpoint
  - CTL.CORS.CREDENTIALS.001   # Allow-Credentials: true with dynamic origin

preconditions:  [internet_access]
postconditions: [credential_access]

narrative: >
  A dangling CNAME on a subdomain that is explicitly trusted
  by a CORS policy with Allow-Credentials: true enables an
  attacker who claims the subdomain to make authenticated
  cross-origin API calls on behalf of any victim who visits
  the attacker-controlled page while logged in.

The chain fires when both controls fail simultaneously on related assets. One control finding remediated — either remove the dangling CNAME or remove Allow-Credentials: true — breaks the chain.

The Wildcard CORS Pattern

The Acronis case used an explicit origin (register.acronis.com), but the more common and more dangerous pattern is a wildcard subdomain CORS policy:

# Dangerous: any subdomain is trusted
Access-Control-Allow-Origin: https://anything.acronis.com
Access-Control-Allow-Credentials: true

When an API reflects the Origin header back as Access-Control-Allow-Origin without validation — a common misconfiguration — any subdomain the attacker controls becomes a trusted CORS origin. Combined with Allow-Credentials: true, any subdomain takeover on any *.acronis.com host unlocks authenticated API access.

The correct configuration trusts only the specific origins that legitimately need cross-origin access:

# Safe: explicit allowlist of known first-party origins
Access-Control-Allow-Origin: https://console.acronis.com
Access-Control-Allow-Credentials: true

Or, if credentials are not required:

# Safe: wildcard only when credentials are not needed
Access-Control-Allow-Origin: *
# Access-Control-Allow-Credentials omitted (defaults to false)

What Stave Detects

Running the Acronis scenario through Stave:

CTL.DNS.DANGLING.001    CRITICAL  initial_access
  "DNS CNAME Must Not Point to Unclaimed Third-Party Service"
  fires on: register.acronis.com → acronis.mktoweb.com (404, unclaimed)
  fires on: promo.acronis.com, promosandbox.acronis.com, info.acronis.com

CTL.CORS.CREDENTIALS.001  HIGH  credential_access
  "API Endpoints Must Not Allow Credentials from Untrusted Origins"
  fires on: account.acronis.com returning Allow-Credentials: true
            for an origin not in the explicit safe list

The compound chain subdomain_cors_credential_theft fires because both controls fail on related assets — the dangling subdomains and the CORS policy reference the same domain namespace.

Neither control alone justifies the chain's severity. Together, they describe a path from "attacker registers a free Marketo account" to "attacker reads authenticated account data for any victim who visits the page."

The Infrastructure Invariants

Two System Invariants were false simultaneously:

Invariant 1: Every DNS CNAME record must point to a target owned by the same organization.

register.acronis.com → acronis.mktoweb.com where acronis.mktoweb.com was unclaimed. False.

Invariant 2: API endpoints that set Access-Control-Allow-Credentials: true must only trust origins that are verified to be owned by the same organization.

account.acronis.com trusted register.acronis.com. The trust was not verified against actual ownership. False.

When both are false at the same time, on overlapping domain namespaces, the compound attack path opens.

Remediation

For the dangling CNAMEs — remove them or reclaim the Marketo workspaces. Five minutes per subdomain.

For the CORS policy — audit every endpoint that returns Access-Control-Allow-Credentials: true and verify that every origin in the allowlist is actively owned and monitored.

# Find all responses with Allow-Credentials from your API
# (run against your own API in a security review context)
curl -s -I -H "Origin: https://register.example.com" \
  https://api.example.com/v2/account | \
  grep -i "access-control"

If Access-Control-Allow-Origin reflects back an origin from *.yourcompany.com, check every subdomain in that namespace for dangling CNAMEs. Any unclaimed subdomain that matches the CORS reflection pattern is exploitable.

Checklist

All DNS CNAMEs point to targets owned and actively maintained by the organization
Access-Control-Allow-Credentials: true endpoints have an explicit, audited origin allowlist
No CORS policy reflects Origin header directly without validation
Subdomain enumeration run against all domains in the CORS allowlist
CTL.DNS.DANGLING.001 and CTL.CORS.CREDENTIALS.001 run together in CI
Deprovisioning process removes DNS records before canceling third-party service accounts

The subdomain takeover gave the attacker a trusted origin. The CORS policy gave that origin authenticated API access. Neither was the vulnerability alone. Together they were.

Based on the publicly disclosed Acronis subdomain takeover report on HackerOne. The compound chain analysis — dangling CNAME × CORS credentials — is detected by Stave, an open-source infrastructure invariant engine that evaluates configuration snapshots without cloud credentials.

DEV Community: Bala Paranj

Every scanner checks what exists. Nobody checks what's missing

The assumption every scanner makes

What deletion leaves behind

Three classes of orphaned references

Class 1: Reclaimable names with active permissions

Class 2: Silent monitoring failures

Class 3: Compute dependencies

Why per-resource scanners can't detect this

What about AWS-native tools?

The temporal dimension

The lifecycle gap

What this means in practice

Deleted and forgotten

Detection without execution

Ghost References are Risky and Dangerous

Debugging theory solved our security triage problem

50 findings. 4 hours of triage.

The insight from debugging theory

1. What the output looks like now

2. Authored vs. mechanical

3. Why three sections, not one

4. The scaling problem

5. The authoring guide

6. What changed for engineers

When to apply this

Understanding vs Detection Accuracy

The Airgap Test: Refactoring a Cobra CLI into a Library API

The contamination

Why it matters

The mental model shift

The refactor

Fix 1: Input structs replace cobra parameters

Fix 2: The transitive import trap

Fix 3: Changed() becomes an explicit type

Fix 4: Output is data, not text

Making it stick

What changed in the design

The airgap dividend

The Bucket You Deleted is Still in Your DNS: S3 Bucket Takeover at Bime

Why This Attack Requires Nothing

The Gap Traditional Tools Cannot See

Why Teams Miss This

The System Invariant

What Stave Detects

The E2E Test

The Asset Type Distinction

Remediation

Checklist

8.7 billion records leaked from one misconfigured cluster. Eight findings would have prevented it.

No exploit required

1. What went wrong

2. Why this keeps happening

3. Eight findings, three critical

4. Why individual findings aren't enough

5. The data store pattern

6. What the operator does

7. Prevention, not forensics

Deployed Without Security Controls

Your security tool should tell users what to change, not just what's wrong

The finding that doesn't help

1. The delta comes from the predicate

2. Why it's a counterfactual, not advice

3. Walking the predicate AST

4. Compound predicates: independent fix paths

5. What the derivation skips

6. Coverage without authoring

7. Verifying the counterfactual

When to add counterfactual output

Reducing the Triage Time

AWS patched the logging. Your data already left.

Forensic evidence doesn't undo a breach

1. Two misconfigurations enable the attack. A third makes it invisible.

2. What AWS patched vs. what prevents the breach

3. Detecting the misconfigurations that enable the crime

4. What the operator sees — and does

5. Why compound detection matters here

6. Prevention at catalog speed, not code speed

7. The configuration lifecycle

8. Applying this to your environment

Fix 3: `Changed()` becomes an explicit type