> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/code-security/code-security-scanners/iac-drift-detection-scans/investigate-and-remediate-iac-drift-issues.md). # Investigate, prioritize and remediate IaC drift issues To effectively manage IaC drift, follow this lifecycle, moving from an open backlog to a resolved and prevented issue. This guide covers IaC drift issues surfaced in the **IaC Drifts** issue table, where a deployed cloud resource violates a security policy that the source template does not violate. **IMPORTANT:** The Drift finding type does not receive **Urgency** classification. Urgency metrics are calculated only for vulnerability, code weakness, IaC misconfiguration, and secret issues. This guide orders work by severity, by the internet exposure of the drifted resource, and by the criticality of the application the resource supports. | Stage | Decision | Primary surface | | --------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------- | | **Assess** | How much capacity to commit, and to what | Severity widget and SLA widget above the IaC Drifts table | | **Prioritize** | Which divergence to reconcile next | Insights widget above the IaC Drifts table | | **Investigate** | Which control the change weakened, what the blast radius is, and who made the change | Issue side panel | | **Remediate** | Which reconciliation direction to apply | **Resolution** tab in the issue side panel | | **Prevent** | How to close the path that allowed the out-of-band change | Unified Application Security Policies | > **Important:** Drift inverts the usual triage question. For every other issue type, the first question is whether the finding is live. A drift issue is raised against a deployed resource by definition, so the finding is always live and the first question becomes which security control the runtime change weakened. ### Assess Before selecting an issue, read the shape of the backlog. Two widgets above the IaC Drifts 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 severity widget — how risk is distributed.** Because the Drift finding type does not calculate Urgency, the histogram widget displays a severity breakdown. Read the proportions rather than the absolute counts. Because every drifted resource is deployed, deployment status does not differentiate one drift issue from another. Severity, internet exposure, and application criticality do. | Shape | What the shape means | What to do | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------- | | A visible Critical segment | Controls have been weakened in ways the platform rates as severe. Every row is a live regression | Commit capacity here before anything else, and establish internet exposure in Stage 3 | | A concentration in one cloud account across severities | One team or one automation path is applying changes outside of Git | Close the access path before reconciling the individual resources | | A large Medium and Low population | Weakened controls on internal resources supporting low-criticality applications | Reconcile on schedule rather than as an incident response | Select a segment to filter the table to that severity 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 severity. Read the SLA widget alongside the severity widget: overdue issues at a low severity are a process problem, while overdue Critical issues are an escalation. > **Note:** The severity widget and the SLA widget describe the backlog. The Insights widget builds the reconciliation queue and belongs to the next stage. > **Caution:** A rising drift count is a signal about process, not only about configuration. A cluster of new drift issues in one cloud account indicates that a team is applying changes outside of Git. Reconciling the individual resources without addressing the access path guarantees the same backlog returns. ### Prioritize Prioritize by **severity**, and use the exposure of the drifted resource to break ties within a severity tier. Severity rates the weakened control itself. Because no Urgency classification is computed for this finding type, the environmental context that Urgency would supply — internet exposure, application criticality, and the privileges the drifted resource holds — is established manually during Stage 3 rather than delivered as a precomputed level. **Use the Insights widget.** Each insight card pairs a severity level with a second risk dimension and states how many issues satisfy both conditions. Selecting a card applies both filters to the IaC Drifts table. Start with the cards that combine the highest severity level with either a committed remediation deadline or internet exposure. **When no card fits the objective,** sort the issue table by Severity in descending order, then filter to internet-exposed resources within each severity tier. **Sort by Created to detect an active pattern.** Drift is a process failure as much as a configuration failure. Sorting by **Created** in descending order and grouping by cloud account surfaces whether the recent drift originates from one team or one automation path, which is the drift-specific triage strategy. A concentrated cluster warrants closing the access path before reconciling the individual resources. > **Note:** For the column and filter model of the table itself, see Understand the IaC Drifts table. ### Investigate A severity level tells you how dangerous the weakened control is in principle. It does not tell you which control was weakened in this instance, or which reconciliation direction is correct. Investigation carries more weight for this finding type than for finding types that calculate Urgency, because no precomputed environmental context exists — the answers below are established manually. Investigation answers three questions, and each answer changes the action you take. #### Which control did the change weaken? Reachability is established — the resource is deployed. The question is what protection the runtime change removed. The issue side panel supplies both sides of the divergence: the **Declared Value** the template specifies and the **Runtime Value** observed on the deployed resource, along with the security policy the deployed resource violates. | Evidence | Consequence | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | The change opened network access to the internet | The resource is now externally reachable. Treat as an incident and escalate | | The change removed or weakened encryption | Data at rest or in transit is no longer protected. Reconcile ahead of the SLA deadline | | The change broadened an identity permission | The resource now holds more privilege than the reviewed baseline granted. Reconcile ahead of the SLA deadline | | The change disabled logging or monitoring | The regression itself is now harder to detect. Reconcile on the SLA schedule and verify no further undetected changes occurred | > **Note:** The Drift scanner raises a finding only when the deployed resource violates a security policy that the source template does not violate. Routine operational changes made outside of Git do not enter the backlog, so every row already represents a security-relevant regression. #### What is exposed by the weakened control? Blast radius determines the escalation level and how much capacity the issue justifies. Establish whether the drifted resource is internet-exposed, the criticality and environment of the owning application, and whether the resource holds privileged capabilities or accesses sensitive data. The **Code-to-Cloud graph** shows the same exposure as a path — the template that declared the resource, the pipeline that applied the template, and the deployed resource that diverged. The exposure window is the drift-specific dimension. A vulnerability is exposed from disclosure; a drift is exposed from the moment the change was applied. Establish when the change occurred, because the interval between the change and the detection is the period during which the control was absent. #### Who made the change, and which direction is correct? Two evidence sources answer different halves of this question. The **code evidence** names the repository, the branch, the template file path, and the commit author of the declared state, which identifies the team that owns the baseline. The cloud provider audit log names the identity that applied the runtime change, which identifies who diverged from the baseline. The reconciliation direction is the central determination of the investigation, and it is not a technical judgment. Establish whether the runtime change was intentional: * **The change was intentional and correct** — the template is out of date, and the template must be updated to record the change. * **The change was unintentional, or intentional but unreviewed** — the resource must be reverted to the declared state. Establish the direction during the investigation, because the direction — not the drift itself — determines who does the work and how long it takes. > **Important:** A drift issue has no PR scan or CI scan equivalent. Drift is detected only after deployment, by comparing the declared state against the runtime state, so every drift issue originates from a periodic scan and always carries full deployment context. ### Remediate Open the **Resolution** tab in the issue side panel. The **Resolution** tab presents the reconciliation paths available for the issue. Reconciliation moves in one of two directions, and choosing the direction is the remediation decision. | Path | Use when | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Revert the deployed resource to the declared state** | The runtime change was unintentional, or was intentional but bypassed review. Restores the reviewed baseline and closes the exposure. The default direction when the change weakened a control | | **Update the template to record the change** | The runtime change was intentional and correct, and the template is out of date. Requires the change to pass review as code. Restores Git as the source of truth without reverting a needed change | | **Document an approved exception** | The runtime change is required and cannot be expressed in the template. Record the justification, apply a compensating control, and keep the exception under review | Sequence within a severity level by exposure. Among equally severe issues, reverting a control on an internet-exposed resource closes real exposure immediately, while updating a template closes only the documentation gap. Escalate to a Case when the reconciliation requires coordination between the team that owns the template and the team that applied the change. > **Important:** Resolving a drift issue without reconciling either side leaves the divergence in place, and the next scan raises the drift again. Record the reconciliation direction in the resolution comment so that a recurring drift is distinguishable from an unresolved one. > **Note:** For inspecting the declared-state baseline and the deployed resource that diverged, see IaC resource as an asset. ### Prevent Prevention for drift differs from prevention for every other issue type. A drift is not introduced by a commit, so a **PR Scan** or **CI Scan** trigger cannot block it. Drift is introduced by a change applied outside of Git, which means prevention operates on the change path rather than on the code path. **Apply the Drift Detection Scanner policy type.** Configure the **Drift Detection Scanner** policy type to define how the platform responds when the Drift finding type appears, including the severity assigned and the notification path. Align the policy grace period to the severity level — shorter grace periods for Critical and High drift, longer grace periods for Medium and Low drift. **Close the out-of-band change path.** A policy detects drift faster; it does not stop the change that caused the drift. Reduce recurrence by restricting direct write access to production cloud resources, so that infrastructure changes are applied through the pipeline rather than through the console or the provider CLI. Treat a recurring drift on the same resource as evidence that the access path remains open. **Shorten the detection interval.** The exposure window for a drift is the interval between the change and the detection. Verify that periodic scanning runs frequently enough that the window is acceptable for your most exposed accounts. > **Note:** For policy triggers, actions, conditions, and grace period configuration, see Unified Application Security Policies. ### When the backlog itself is unreliable Drift requires both the declared state and the runtime state. A gap in either source produces silence rather than a finding, and silence is indistinguishable from a clean posture. **Missing YOR tags.** Without YOR trace tags, the Asset Lineage Graph cannot link a template resource to the deployed cloud resource, and drift cannot be computed for that resource at all. The resource is not reported as clean — the resource is not evaluated. **Missing cloud account integration.** Drift detection requires the runtime state supplied by a Cloud Security Posture Management integration. A tenant with IaC scanning but no cloud account integration produces IaC misconfiguration issues and no drift issues whatsoever. An empty **IaC Drifts** table on such a tenant reflects missing telemetry, not an absence of drift. Verify both prerequisites before concluding that the environment matches its declared state. Treat coverage of the linked template-to-resource pairs as the denominator against which the drift count is meaningful. > **Note:** For the drift detection logic and the YOR traceability that makes drift computable, see [Code-to-Cloud](/application-security/code-to-cloud/code-to-cloud.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/application-security/code-security/code-security-scanners/iac-drift-detection-scans/investigate-and-remediate-iac-drift-issues.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.