Policy as code stops a misconfiguration before it deploys.
Policy as code is the practice of writing security rules that run against infrastructure code before it deploys. A plan that violates a rule fails the pipeline, and the misconfiguration never reaches the account. Done well, policy as code is the prevention half of the loop that Tamnoon's State of Cloud Remediation 2026 found missing: the top eight misconfigurations in 2026 are nearly identical to 2025's, and they make up roughly 20% of all alerts. This post covers which rules to write first and where policy as code stops.
The report measured 14.86 million CNAPP detections. Closing alerts faster did not eliminate the categories that produce them. The eight most common findings account for roughly a fifth of everything the scanners raised, and the list barely moved year over year.
Six of the eight are settings a rule can check at plan time, by our reading of the list. The report groups the other two with vulnerability work: Critical and High vulnerabilities at 3.9% of all alerts, and missing vulnerability assessment at 1.8%. The full list, with each row's share, is in our post on configuration drift, which covers the other half of this problem: a fix made at runtime that the next deploy removes.
Container read-only filesystems and health checks alone are nearly 6% of the dataset. The report calls container security an established problem for two decades that remains largely unaddressed. That is a prevention failure, not a detection failure.
Our recommendation: start from your own scanner's top findings by volume, not from a vendor's rule library. The dataset's top eight is a reasonable default for any multi-cloud estate. Six rules cover the six settings, and a seventh turns on the assessment that the eighth row misses.
Each rule should fail the plan with a message that names the fix. A rule that only warns is a rule that gets ignored under deadline.
Four gaps remain after the gate is in place.
The existing backlog. Policy as code prevents new instances of a finding. Anything already open is already running, and 53% of detections in the dataset were still open as of May 2026. A plan-time rule does not close anything that is already running.
Resources that bypass the pipeline. A console-created resource never passes through a plan, so no policy runs on it. The report's self-assessment asks where shift-left is preventing new alerts and where the same misconfiguration is being introduced repeatedly. The second half of that question is the measure of how much of your estate bypasses the gate.
Rules that only warn. A warning in a pipeline under deadline is a rule nobody reads. If a rule matters, the plan fails. If a plan can fail for a reason the team disputes, the rule needs an exception path with a named approver, not a warning.
The vulnerability row. Vulnerability Management is the slowest-closing category at 282 days and the largest recurring one at roughly 19% of 2026 alerts. The report is clear that closure depends on vendor patch availability, regression-testing cycles, approved release windows and supply-chain coordination, none of which a plan-time rule controls.
The report says plainly that scanners find problems, but without a closure-and-prevention loop, that is all they do. Policy as code is the prevention half. The closure half is the layer that takes the open backlog and ships fixes with the stack in view, so the gate and the fix agree.
The two halves share one artifact: the template. A fix that is applied at runtime and never written back to the template will be undone by the next deploy, and the policy will not catch it because the template never changed. A fix that lands in the template is both the closure and the prevention.
Our recommendation is two numbers per quarter. Plan failures by rule, which tells you which misconfigurations your teams keep writing. Re-detections per resource, which tells you how much of the estate is bypassing the pipeline. The first number should be high at first and fall. The second should fall to zero.
The gate stops new findings. Tamnoon works on the ones already open. In the site's own words, Tamnoon converts recommendations into verified engineering initiatives ready for execution, complete with CLI commands, IaC templates and validation scripts, so a closure can land in the same code the policy checks. That is the handoff between the two halves of the loop: the policy decides what may deploy, and the closure arrives as a template change the policy can read.
Security rules written as code and run against infrastructure plans before deployment. A plan that violates a rule fails, so the misconfiguration never reaches the account.
The ones that match your scanner's highest-volume findings. In the 2026 dataset, six settings in the top eight add up to about 14.5% of all alerts, and the eight together are roughly 20%.
No. A plan-time rule prevents new findings. Anything already running needs a closure layer, and 53% of detections in the dataset are still open.
The report found the remediation gap is structurally an unowned-coordination gap. Our reading for IaC: prevention and closure are owned by different teams, and the template change that connects them is owned by nobody.
Not at plan time. Vulnerability Management closes in 282 days on average because the fix waits on vendor patches and release windows that no rule controls.
The category close times and the top misconfigurations are in the State of Cloud Remediation 2026. The rules above are our recommendation.
Teardowns, CTF write-ups and field notes from the people who close cloud findings for a living.
You're subscribed.
That did not go through. Try again in a minute.
At most one email a month. Unsubscribe from any of them.
