{"id":4245,"date":"2026-06-05T11:11:55","date_gmt":"2026-06-05T11:11:55","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/06\/05\/risk-based-review-for-infrastructure-as-code-pull-requests\/"},"modified":"2026-06-05T11:11:55","modified_gmt":"2026-06-05T11:11:55","slug":"risk-based-review-for-infrastructure-as-code-pull-requests","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/06\/05\/risk-based-review-for-infrastructure-as-code-pull-requests\/","title":{"rendered":"Risk-Based Review for Infrastructure as Code Pull Requests\u00a0"},"content":{"rendered":"
\"infrastructure,<\/div>\n

\"infrastructure,<\/p>\n

Not every infrastructure pull request deserves the same review path. A tag change in a development account and a network-policy change in production should not create identical reviewer load. When every change is treated as high risk, reviewers stop trusting the signal.<\/span>\u00a0<\/span><\/p>\n

In\u00a0IaC review, I have seen reviewers spend too much attention on low-risk changes while subtle production changes move through with weak context. Risk scoring is useful when it redirects human judgment instead of pretending to replace it.<\/span>\u00a0<\/span><\/p>\n

Risk-based review gives platform teams a more useful pattern. The system scores an IaC<\/a> change using evidence from the diff, environment, resource type, dependency criticality, recent incidents, ownership and rollout plan. The score does not replace reviewers. It decides how much review the change deserves.<\/span>\u00a0<\/span><\/p>\n

What the Score Should Consider<\/span>\u00a0<\/span><\/h3>\n

A good score is boring and explainable. It should include blast radius, production exposure, stateful resource impact, identity or network changes, rollback difficulty, missing evidence and whether the affected service has recent incidents. The goal is not machine judgment. The goal is consistent triage.<\/span>\u00a0<\/span><\/p>\n

risk_inputs<\/span>:<\/span><\/b>
\n\u00a0\u00a0<\/span>environment<\/span>:<\/span><\/b>\u00a0production<\/span>
\n\u00a0\u00a0<\/span>resource_type<\/span>:<\/span><\/b>\u00a0iam_policy<\/span>
\n\u00a0\u00a0<\/span>blast_radius<\/span>:<\/span><\/b>\u00a0account-wide<\/span>
\n\u00a0\u00a0<\/span>rollback<\/span>:<\/span><\/b>\u00a0manual<\/span>
\n\u00a0\u00a0<\/span>owner_present<\/span>:<\/span><\/b>\u00a0<\/span>true<\/span>
\n\u00a0\u00a0<\/span>recent_incidents<\/span>:<\/span><\/b>\u00a0<\/span>1<\/span>
\n\u00a0\u00a0<\/span>missing_evidence<\/span>:<\/span><\/b>\u00a0<\/span>false<\/span>\u00a0<\/span><\/p>\n

The output should be equally clear:\u00a0Fast\u00a0path, owner review, platform review, security review, staged rollout or block until evidence is complete.<\/span>\u00a0<\/span><\/p>\n

Why Pull Requests\u00a0are\u00a0the Right Surface<\/span>\u00a0<\/span><\/h3>\n

The pull request already has context:\u00a0Author, diff, reviewers, checks, target branch and deployment environment. That makes it the best place to explain risk while the change is still cheap to adjust. A weekly governance report may be useful for leaders, but it is too late for the engineer trying to merge safely.<\/span>\u00a0<\/span><\/p>\n

The comment should not dump raw policy output. It should say which resources changed, which risk factors mattered, what review path was selected and what would lower the risk.<\/span>\u00a0<\/span><\/p>\n

Implementation Sketch<\/span>\u00a0<\/span><\/h3>\n

def<\/span><\/b>\u00a0risk(change):<\/span>
\n\u00a0\u00a0\u00a0 score\u00a0<\/span>=<\/span>\u00a0<\/span>0<\/span>
\n\u00a0\u00a0\u00a0\u00a0<\/span>if<\/span><\/b>\u00a0change.environment\u00a0<\/span>==<\/span>\u00a0<\/span>\u201cproduction\u201d<\/span>:<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 score\u00a0<\/span>+=<\/span>\u00a0<\/span>25<\/span>
\n\u00a0\u00a0\u00a0\u00a0<\/span>if<\/span><\/b>\u00a0change.resource\u00a0<\/span>in<\/span><\/b>\u00a0{<\/span>\u201ciam_policy\u201d<\/span>,\u00a0<\/span>\u201csecurity_group\u201d<\/span>,\u00a0<\/span>\u201croute_table\u201d<\/span>}:<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 score\u00a0<\/span>+=<\/span>\u00a0<\/span>25<\/span>
\n\u00a0\u00a0\u00a0\u00a0<\/span>if<\/span><\/b>\u00a0<\/span>not<\/span><\/b>\u00a0change.owner:<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 score\u00a0<\/span>+=<\/span>\u00a0<\/span>20<\/span>
\n\u00a0\u00a0\u00a0\u00a0<\/span>if<\/span><\/b>\u00a0change.rollback\u00a0<\/span>==<\/span>\u00a0<\/span>\u201cmanual\u201d<\/span>:<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 score\u00a0<\/span>+=<\/span>\u00a0<\/span>15<\/span>
\n\u00a0\u00a0\u00a0\u00a0<\/span>return<\/span><\/b>\u00a0<\/span>min<\/span>(score,\u00a0<\/span>100<\/span>)<\/span>\u00a0<\/span><\/p>\n

This example is intentionally simple. Production systems should use tested rules, not mysterious weights. If a score changes, reviewers should know which input changed.<\/span>\u00a0<\/span><\/p>\n

Avoiding Reviewer Fatigue<\/span>\u00a0<\/span><\/h3>\n

The biggest risk is over-escalation. If every production change goes to a central team, the system becomes a bottleneck. Use thresholds carefully. A production tag change with complete evidence may need only normal owner review. A production identity change with a missing rollback deserves more attention.<\/span>\u00a0<\/span><\/p>\n

Track false positives, false negatives, review latency, override rate and repeated high-risk patterns. If a category repeatedly scores high because the platform lacks a safer workflow, that is roadmap input.<\/span>\u00a0<\/span><\/p>\n

Evidence and Replay<\/span>\u00a0<\/span><\/h3>\n

Each scored decision should be stored with policy version, inputs, score, selected path, reviewer and final outcome. This matters during incidents. If a change later causes a problem, the team can reconstruct why the review path seemed reasonable at the time.<\/span>\u00a0<\/span><\/p>\n

The evidence record should not be treated as compliance paperwork. It is operational memory for the delivery system.<\/span>\u00a0<\/span><\/p>\n

Rollout Plan<\/span>\u00a0<\/span><\/h3>\n

Start in advisory mode for a month. Compare the score with human judgment. Look for missing context and confusing explanations. Then enforce one narrow case, such as production changes with missing owner or missing rollback. Expand only after the system earns trust.<\/span>\u00a0<\/span><\/p>\n

Risk-based review is strongest when it reduces noise. The platform should make safe changes faster and risky changes clearer, not simply add another required check.<\/span>\u00a0<\/span><\/p>\n

Calibrating the Score<\/span>\u00a0<\/span><\/h3>\n

Risk scoring fails when teams cannot see how the number was produced. Keep the first model simple and publish the scoring table.\u00a0If identity changes add\u00a025\u00a0points and missing rollback adds\u00a015, say that.\u00a0Reviewers do not need a mysterious model; they need a consistent way to decide where to spend attention.<\/span>\u00a0<\/span><\/p>\n

A monthly calibration review should compare score, reviewer decision, deployment outcome and incident follow-up. If low-score changes repeatedly cause issues, the model is missing a signal. If high-score changes routinely pass without concern, the model may be too sensitive.<\/span>\u00a0<\/span><\/p>\n

Example Workflow Output<\/span>\u00a0<\/span><\/h3>\n

Risk score: 72 \/ 100<\/span>
\nReason: production IAM policy change, account-wide scope, manual rollback<\/span>
\nDecision: platform owner review required<\/span>
\nRemediation: add rollback plan or reduce policy scope<\/span>
\nEvidence: policy-v4, commit 7a91c2, service owner payments-platform<\/span>\u00a0<\/span><\/p>\n

This\u00a0output\u00a0offers\u00a0the engineer something to act on. It also gives reviewers a shared language. The discussion becomes about specific risk factors rather than general discomfort.<\/span>\u00a0<\/span><\/p>\n

Anti-Patterns<\/span>\u00a0<\/span><\/h3>\n

Avoid scores with too many hidden inputs. Avoid global thresholds that ignore environment. Avoid blocking changes without explaining remediation. Avoid treating the model as finished. Infrastructure platforms change constantly, and the review model should evolve with them.<\/span>\u00a0<\/span><\/p>\n

The best risk-based review systems become quieter over time because the platform learns which changes are routine and which patterns deserve deeper attention.<\/span>\u00a0<\/span><\/p>\n

Keeping\u00a0it\u00a0Practical<\/span>\u00a0<\/span><\/h3>\n

The review model should be easy to explain to a new engineer. If a team cannot describe why a change was routed to security review, the scoring system is too opaque. Good risk\u00a0scoring gives engineers a shared vocabulary:\u00a0Production\u00a0exposure, blast radius, rollback difficulty, ownership and missing evidence.<\/span>\u00a0<\/span><\/p>\n

Final Check<\/span>\u00a0<\/span><\/h3>\n

Before requiring the score, replay it against the last month of infrastructure changes. Ask whether the model would have escalated the changes that engineers actually worried about.<\/span>\u00a0<\/span><\/p>\n

Read More<\/a><\/p>\n

\u200b<\/p>","protected":false},"excerpt":{"rendered":"

Not every infrastructure pull request deserves the same review path. A tag change in a development account and a network-policy […]<\/p>\n","protected":false},"author":1,"featured_media":4246,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[5],"tags":[],"class_list":["post-4245","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4245","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4245"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4245\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/4246"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4245"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4245"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4245"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}