Guide
Policy as code, tested before it counts
Policy as code means writing your security rules as code: versioned, reviewed and tested like any other change. It replaces a rules document nobody reads with checks that run the same way every time, and a history of who changed what.
Rules that run the same way twice
A policy in code gives the same answer for the same input, wherever it runs.
Changes you can review
Turning a rule off is a diff with an author and a reason, not a quiet setting.
No surprises on rollout
Simulating a policy against real results shows its effect before it is enforced.
The idea
Rules as versioned code
A policy is a rule such as “storage must not allow public access.” Written as code, it takes structured input, such as a resource’s configuration or a planned change, and returns a result: pass, fail or unknown.
Because the rule is code, it lives in version control, has tests, goes through review and can be traced to the framework controls it supports.
Where policies run
Three places to enforce
In the pipeline
Against a planned infrastructure change, before it deploys. Catches problems before they exist.
At admission
Against a workload as a cluster admits it. Stops a non-compliant manifest at the door.
Against live state
Against the cloud as it is now. Catches drift and console changes the pipeline never saw.
A healthy lifecycle
From draft to enforced
- Write and testWrite the rule with fixtures for passing, failing and unknown cases.
- SimulateRun it against recent real results to see how many resources it would flag and how scores would move.
- Review and approveLoosening a rule should need a second person. Tightening one can apply at once.
- Roll out and recordApply the new version, record which version each result came from, and keep the history.
Pitfalls
Where policy quietly fails
Unknown as pass
A rule that can’t read its input returns pass by default, and the gap looks like compliance.
Silent disabling
A rule turned off with no reason or approval, so the score improves for the wrong reason.
Two sets of rules
The pipeline and the live checks drift apart, so a change passes one and fails the other.
Exceptions in comments
An accepted risk recorded only in a code comment, with no owner and no expiry.
How ACSE approaches it
One policy, from scan to fix
ACSE’s checks are policy as code, evaluated by an open-source policy engine in your runtime. The same policy that raises a finding re-checks the planned state of every proposed fix, so a fix can’t pass review while failing the rule it was meant to satisfy.
On the Policies screen your team simulates a change first: would-flag counts and score effects, without creating findings. Turning a check off needs a second person, and its controls then read not evaluated and count as unknown. Framework content arrives as signed packs, and adopting a new version takes two people.
- Unknown never counts as a pass
- Every policy version recorded and applied per scan
- Thresholds set within the bounds each check declares
Questions
What people ask us
Is policy as code only for infrastructure as code?
No. The same rules can check a planned change in a pipeline and the live configuration of the cloud. Using one set of rules for both avoids drift between them.
Why should loosening a rule need two people?
Because it weakens a control. Tightening a rule makes you safer and can apply at once; loosening one should have a reason and a second approver on record.
Can I write my own checks in ACSE?
You can set the thresholds each check declares, within its bounds, and build custom frameworks from existing checks. Uploading your own policy code is not offered today.
Keep reading
Related
Approvals and governance
Every ACSE fix needs a person’s approval with step-up MFA, bound to the exact view they saw. Authors don’t approve their own changes, and two people where policy says.
ReadLearnCompliance evidence
A dashboard shows status; an auditor needs evidence. Learn what makes cloud compliance evidence hold up, why raw and governed scores differ and how to check it.
ReadACSEFrameworks
ACSE maps its cloud checks to CIS, PCI DSS, NIST 800-53, FedRAMP Moderate, CCCS Medium, ISO 27001 and SOC 2, with signed, versioned framework content.
ReadTalk to us
See ACSE on your cloud.
Tell us what you run and what your auditors ask for. We’ll show you the loop end to end: a real finding, a fix as code, an approval with MFA and the sealed record.