Investigate, prioritize, and remediate IaC misconfiguration issues

To effectively manage IaC misconfigurations, follow this lifecycle, moving from an open backlog to a resolved and prevented issue.

Stage	Decision	Primary tenant surface
Assess	How much capacity to commit, and to what	Urgency widget and SLA widget above the IaC Misconfigurations table
Prioritize	Which misconfiguration to work on next	Insights widget above the IaC Misconfigurations table
Investigate	Whether the template is deployed, what the blast radius is, and who owns the fix	Issue side panel
Remediate	Which remediation path to apply	Resolution tab in the issue side panel
Prevent	Which enforcement point blocks recurrence	Unified Application Security Policies

Important: The remediation target for an IaC misconfiguration is always the template, never the deployed resource. Correcting the running resource without correcting the template leaves the misconfiguration in the source of truth, and the next apply reintroduces the misconfiguration as drift.

---

Assess

Before selecting an issue, read the shape of the backlog. Two widgets above the IaC Misconfigurations table answer that question, and neither is a work queue — each describes a distribution, so that you commit capacity against a measured posture rather than against the first issue you happen to open.

The Urgency widget charts the count of open issues per Urgency level. Read the proportions rather than the absolute counts.

Shape	What the shape means	What to do
A visible Top Urgent segment	Misconfigured templates have provisioned live, internet-exposed resources	Commit capacity to Top Urgent before anything else
A backlog concentrated in Not Urgent and Not Applicable	Either templates that were never applied, or missing YOR traceability that suppresses the deployment metrics	Verify YOR tag coverage before trusting the shape. See When the backlog itself is unreliable
A large Urgent middle	Deployed misconfigurations on internal resources	Plan scheduled remediation rather than an incident response

Select a segment to filter the table to that Urgency level.

The SLA widget — how much of the backlog is already late.

The SLA widget charts open issues by SLA status. An overdue population is a commitment already broken, independent of Urgency. Read the SLA widget alongside the Urgency widget: overdue issues at a low Urgency level are a process problem, while overdue issues at Top Urgent are an escalation.

Note: The Urgency widget and the SLA widget describe the backlog. The Insights widget builds the work queue and belongs to the next stage.

Prioritize

Prioritize by Urgency, and use Severity as the tie-breaker within an Urgency tier. Severity rates the insecure condition in isolation; Urgency rates the condition in your environment by adding whether the template was applied, how many resources the template provisioned, and whether those resources are internet-exposed.

Use the Insights widget. Each insight card pairs an Urgency level with a second risk dimension and states how many issues satisfy both conditions. Selecting a card applies both filters to the IaC Misconfigurations table.

Start with the cards that combine the highest Urgency level with either a committed remediation deadline or the largest affected asset count.

Filter on Is Fixable to build the throughput queue. The Is Fixable column reports whether Cortex computed an automated fix for the issue. Is Fixable is hidden by default — display Is Fixable from the Table Settings menu, then filter Is Fixable to True within an Urgency tier, or sort on Is Fixable to group the fixable issues together.

Important: Is Fixable is set per detection rule and IaC framework. A rule that carries no automated remediation for the framework the template is written in returns Is Fixable as False even when the same rule is fixable in another framework. Treat False as "no generated fix for this template," not as "harder to fix."

When no card fits the objective, sort the issue table by Urgency in descending order, then sort by Severity within each Urgency tier.

Sort by Affected Assets Count to find leverage. One misconfigured module reused across environments provisions many live resources, and correcting the module resolves every resource at once. Sorting by Affected Assets Count in descending order identifies the template corrections with the highest resource-per-fix ratio, which is the IaC-specific throughput strategy.

Investigate

An Urgency level tells you an issue ranks highly. It does not tell you what the misconfiguration exposes, or what the correction will cost. Investigation answers three questions, and each answer changes the action you take.

Is this misconfiguration live?

A misconfiguration in a template that was never applied is a code defect. The same misconfiguration in an applied template is live exposure on running infrastructure.

The Urgency Details section in the issue side panel supplies the deployment evidence: whether the template Is Deployed, the Affected Assets Count of live resources the template provisioned, and whether those resources are Internet Exposed.

Evidence	Consequence
Deployed, internet-exposed, high affected asset count	The insecure condition is live and externally reachable across many resources. Treat as an incident and escalate
Deployed, internet-exposed, single resource	The insecure condition is live and externally reachable. Remediate ahead of the SLA deadline
Deployed, internal only	The insecure condition is live but reachable only from inside the network boundary. Remediate on the SLA schedule
Not deployed	The template has not been applied. Confirm the gap is real and not a YOR traceability gap before deprioritizing

What is exposed if the misconfiguration is exploited?

Blast radius determines the escalation level and how much capacity the issue justifies.

The Urgency Details section reports the criticality and environment of the owning application, whether the affected resources hold privileged capabilities or access sensitive data, and the effectiveness of any compensating control already in place. The Code-to-Cloud graph shows the same exposure as a path — the template, the pipeline that applies the template, and every cloud resource the pipeline provisioned.

A reusable module is the IaC-specific multiplier. One insecure default in a shared module propagates into every environment that instantiates the module, which is why two issues with the same detection rule and the same Severity can justify entirely different responses.

An existing compensating control at the network or identity layer reduces the exposure but does not remove the insecure definition. Record the control, and keep the issue open against the template correction.

Who owns the fix, and what does the fix cost?

The code evidence names the repository, the branch, the template file path, and the commit that introduced the resource block, along with the commit author. That identifies the team to route the work to and the template to change.

The relationship between the template and its deployed resources determines the cost. Correcting a template that provisions no live resources is a code change that merges and completes. Correcting a template that provisions live resources requires an apply against running infrastructure, which is change-managed, may interrupt service, and requires a maintenance window. Establish the deployment state during the investigation, because the deployment state — not the misconfiguration — drives the remediation timeline.

Important: The Urgency Details section is populated for issues from periodic scans. PR scan issues and CI scan issues have no deployment context, because unmerged templates have not been applied. For PR scan and CI scan issues, prioritize by Severity.

Remediate

Procedure

1. Navigate to Application Security > Issues > IaC Misconfigurations.
2. Select the issue row to open the issue side card. The issue side card displays the current SLA status of the issue.
3. Select the Resolution tab.
4. Select a fix card, then apply the fix.

Path	What the path does	Use when
Automatic Pull Request	Cortex has already computed the corrected resource block. Selecting Create Fix PR opens a pull request against the branch that contains the template, replacing the misconfigured block with the corrected block	The issue reports Is Fixable as True. This is the fastest path and the default choice
Infrastructure as Code	Presents the corrected template code so that you apply the change yourself in the resource block that triggered the detection rule, then merge the change through your own review process	No automated fix exists for the rule and framework, or the generated fix conflicts with a local convention that your review process enforces
Manual Steps	Presents the ordered remediation steps from the detection rule — the attribute to add or change and the value to set	The correction spans more than a single block, such as a shared module that every consumer instantiates, or the change requires a coordinated version bump
CLI	Presents the commands that apply the change	You are correcting the resource through a command-line workflow rather than through a template edit
Cloud Console	Presents the steps to change the setting in the cloud provider console	Used to stop live exposure while the template correction is in review. This path does not resolve the issue

Important: Automatic Pull Request is offered only for issues from periodic scans. A PR scan issue or a CI scan issue presents the manual paths instead, because the branch the fix would target is the branch already under review.

Caution: A Cloud Console change corrects the running resource, not the template. The misconfiguration remains in the source of truth, and the next apply reintroduces the misconfiguration — as an IaC drift issue if the console change survives, or as the same misconfiguration if the apply overwrites the console change. Treat a Cloud Console change as a temporary control and keep the issue open against the template correction.

Sequence the queue by fix availability inside the Urgency tier. Working the issues that report Is Fixable as True first inside a tier converts the tier into merged pull requests fastest. Between two issues that both carry an automated fix, correct the template that provisions live internet-exposed resources first — that correction removes real exposure, while correcting an unapplied template removes only future exposure.

Escalate to a Case when the correction requires an apply against production infrastructure and a coordinated maintenance window.

Result: The remediated issue moves to a resolved state and stops the SLA clock at its resolution timestamp. An Automatic Pull Request fix resolves the issue when the pull request merges and the next scan confirms the corrected block, not when the pull request opens.

Prevent

A corrected template that the next commit re-breaks has not been resolved. Close the loop with a Unified Application Security Policy that blocks the misconfiguration pattern at the earliest enforcement point.

Select the trigger in shift-left order: a PR Scan trigger blocks the misconfiguration before the template merges, and a CI Scan trigger blocks the template before the apply stage. Align the policy grace period to the Urgency level — shorter grace periods for issues that reach Top Urgent, longer grace periods for issues that remain Not Urgent.

Match the framework to the scan type. Selecting the TERRAFORM framework applies the detection rule to Terraform Plan scans, and selecting KUBERNETES applies the rule to Helm and Kustomize scans. A rule authored against the wrong framework does not evaluate at the enforcement point you intended.

Add a Compliance Standards condition to convert prevention into evidence. Policies support a Compliance Standards condition filter for the IaC Misconfigurations finding type, which makes the enforcement point auditable against the standard rather than only against the rule.

Note: For policy triggers, actions, conditions, and grace period configuration, see Unified Application Security Policies. For authoring custom IaC rules across the supported frameworks, see Application Security rules.

When the backlog itself is unreliable

Incomplete YOR tag coverage suppresses the deployment-dependent Urgency metrics — Is Deployed, Affected Assets Count, and Internet Exposed — which pushes issues toward the Not Urgent and Not Applicable levels. The resulting backlog resembles low risk and is in fact reduced visibility.

Without YOR trace tags, the Asset Lineage Graph cannot link a template resource to the cloud resource the template provisioned, so a live misconfiguration on an internet-exposed production resource is indistinguishable from a defect in a template that no one ever applied.

Retrieve the Not Urgent issues whose templates report no deployment. For each issue, apply YOR trace tags to the IaC resources and verify CI/CD pipeline integration, then re-triage after the next periodic scan. Treat YOR coverage as a prerequisite to trusting the Urgency distribution across the IaC backlog.

Note: For YOR traceability and the Asset Lineage Graph, see Code to Cloud.