PontoAntiCrack is finished: from documentation fixtures to real AWS events

The first live PontoAntiCrack finding ended with no remediation.

That was the correct result.

The event reached EventBridge, the Lambda inspected the resource, and the current state did not require a safe change. plan() returned no action. The system did not create a dramatic Slack alert just to prove it was online.

After weeks of building handlers, it was reassuring to watch one decide to do nothing.

PontoAntiCrack is now deployed, tested against real AWS events, and complete for its three-detection scope.

Dry-run earned its place

The first AWS deployment had all mutations disabled.

I triggered the lab scenarios, captured the resulting events, and compared them with the documentation-based fixtures. The overall shapes were close enough for the implementation to be useful, but the comparison still found assumptions that needed correction before enforcement.

Those corrections are exactly why I refused to treat the fixture suite as operational evidence.

For every matched event, dry-run performed the full pre-mutation path:

1. It inspected the current resource.

2. It created a structured plan.

3. It checked for the exclusion tag.

4. It saved the original state in DynamoDB.

5. It counted the planned remediation for the circuit breaker.

6. It recorded that enforcement was disabled.

7. It sent a redacted summary to Slack.

This gave me a record of what the system would have changed and how often, without asking me to trust the planner on its first contact with real AWS data.

Enabling remediation one detection at a time

I did not flip one global switch.

sg-open went first because its intended change was the most bounded. In the lab scenario, the unsafe public range was removed while the permitted private range remained. The audit record contained the original permission before the EC2 API call ran.

I repeated the scenario to check idempotency. Once the public range was gone, the next inspection did not invent another change.

s3-public came next after the condition classifier had been tightened. An organization-restricted access path remained untouched. A truly public test case followed the configured remediation path. Ambiguous conditions were escalated instead of being simplified into "public" or "safe" without enough information.

The credential detection was enabled last. A standard IAM access-key case followed its bounded containment action and preserved the relevant before state. The root fixture and root test path produced an escalation without automated root changes.

The difference between REMEDIATED and ESCALATED is part of the contract, not an error category.

The circuit breaker test

I tested the breaker with controlled repeated events rather than waiting for an accidental storm.

The early events created plans and moved through the allowed path. Once the configured threshold was reached, later events stopped before apply(). Their audit records showed that the breaker, rather than a Lambda failure or IAM deny, prevented the change.

The same test in dry-run produced the expected state transition. This confirmed that event volume can be evaluated before write permissions are enabled.

A breaker can still be configured badly. Too low, and it blocks a real response after a few incidents. Too high, and it does little to contain a broad pattern. The selected values are documented as lab values, with the event rate observed during the tests. I am not presenting them as universal production defaults.

What happened to the 167 tests

The original suite remains, but the real captures now anchor the fixtures.

I kept synthetic variants for edge cases that would be unreasonable or unsafe to reproduce in AWS. I also kept the negative cases around private CIDRs, intended HTTPS access, unrelated findings, low-severity findings, organization-restricted S3 policies, exclusion tags, duplicate processing, failed snapshots, and Slack failures.

The live tests did not replace the unit suite. They answered a different question.

The unit tests ask whether the code's decisions remain stable across known inputs.

The live exercises ask whether AWS produces the input, whether EventBridge selects it, whether IAM permits only the expected operations, and whether the resource ends in the intended state.

I need both.

The original state comes first

The design decision I care about most survived deployment: evidence is written before remediation.

If DynamoDB cannot accept the snapshot, the mutation does not proceed. A Slack failure does not remove or rewrite the audit result. A handler cannot opt out of this order.

This makes the automation less available during an audit-store failure. That is deliberate. A system that changes security configuration while losing the before state would fail in the direction I least want.

There is a practical limit here. A snapshot is not automatically a rollback button. AWS resources have dependencies, concurrent changes, and state that may not be safe to restore blindly. The audit record preserves evidence and supports a reasoned recovery. It does not promise that every incident can be undone by copying JSON back into an API.

What I would watch in a larger environment

The lab confirmed behavior, not scale.

In a larger organization I would pay close attention to event deduplication across regions, concurrency around the same resource, DynamoDB capacity and retention, breaker scope, Slack rate limits, and the permissions required for cross-account remediation.

I would also put deployment promotion behind an observation period per account group. One clean lab account does not justify immediate organization-wide write access.

The project already separates detection roles and keeps their permissions narrow. Scaling the account model would require similarly narrow cross-account roles, not one security role with unlimited authority everywhere.

Three AWS detections are enough for this project

There are dozens of additional detections I could add.

Unencrypted storage, public snapshots, risky IAM policy changes, disabled logging, exposed databases, unusual role assumptions, and network changes would all be reasonable.

I am stopping at three because the point was to build the safety framework around detection and response:

1. Positive and negative matching.

2. Current-state inspection.

3. Bounded plans.

4. Evidence before mutation.

5. Dry-run.

6. Circuit breaking.

7. Least-privilege handlers.

8. Escalation when automation is not safe.

Adding a fourth event source would prove less than finishing the end-to-end path for the first three.

Moving to ProvenancePipeline

AwLZ controls the AWS foundation. KateClusters controls and observes the Kubernetes runtime. PontoAntiCrack reacts to dangerous AWS changes.

The remaining TrustStack question begins earlier: why should the cluster trust the container image at all?

ProvenancePipeline builds a small Go service, records its components in an SBOM, scans it, signs the image with a short-lived GitHub identity, attaches build provenance, and verifies the result from a clean job.

The final part connects back to KateClusters. Kyverno will inspect the image before admission. The expected identity and issuer must match. An unsigned image should fail before its process exists.

I have spent this project making sure automation knows when not to act.

The next one finishes when the cluster refuses to act.