Select any row in the IaC Misconfigurations table to open the issue side panel. The side panel provides detailed context for investigation and remediation.
Details
Issues include general, Urgency, code evidence, and code to cloud details.
General details:
The top section of the side panel displays the following fields:
Field | Description |
|---|---|
Severity | The severity level of the misconfiguration |
Status | The current resolution status (New, In Progress, Resolved) |
Assignee | The user assigned to the issue |
SLA | The SLA compliance status, calculated from the issue creation date and the severity-based target resolution window |
Backlog Status | The backlog classification of the issue (New, Backlog) |
Urgency details
The Urgency details section provides the contextual risk signals that determine the urgency classification of the IaC misconfiguration issue. Urgency extends beyond static severity by incorporating runtime and business context.
Signal | Description |
|---|---|
Urgency Level | The computed urgency classification: Top Urgent, Urgent, Not Urgent, or Not Applicable. The urgency level is determined by the combination of all contextual signals |
Application Criticality | The highest criticality level among all applications linked to the affected assets. If no application is attached, the value is None. Link the affected asset to the relevant application to ensure accurate urgency calculation |
Application Environment | The highest-risk environment among all applications associated with the issue (Production, Staging, Pre-Staging, Dev, Testing) |
Access Sensitive Data | Indicates whether at least one deployed asset affected by the misconfiguration has access to sensitive data |
Leverage Privileged Capabilities | Indicates whether at least one deployed asset affected by the misconfiguration has the ability to leverage privileged capabilities |
Affected Assets | The number of deployed cloud assets affected by the misconfiguration |
Is Deployed | Indicates whether the misconfiguration affects any deployed assets. A deployed misconfiguration represents a higher risk than a misconfiguration that exists only in code |
Internet Exposed | Indicates whether at least one affected deployed asset is accessible from the internet, increasing the likelihood of exploitation |
Important: Urgency signals are populated only when the IaC asset is traced to deployed cloud resources through the Code-to-Cloud mapping. If no Code-to-Cloud trace exists, urgency signals display as Not Applicable.
Code evidence
The Code evidence section displays the source code context of the misconfiguration:
Repository Name: The name of the repository containing the misconfigured IaC template.
File Path: The full path to the affected file with a link to the VCS provider.
Code Block: The source code snippet with highlighted lines indicating the specific misconfiguration.
Commit Details: The Git author, commit hash, and commit timestamp of the commit that introduced the misconfiguration.
Code to cloud graph
The Code to cloud graph visualizes the traceability path from the IaC template in the repository to the deployed cloud resource. The Code to Cloud graph enables you to understand the blast radius of the misconfiguration by identifying which production assets inherit the misconfigured resource definition.
Prioritize IaC misconfiguration issues
Effective prioritization of IaC misconfiguration issues requires evaluating multiple contextual signals beyond static severity. Application Security provides two complementary prioritization mechanisms: Urgency-based prioritization and Severity-based prioritization.
Urgency-based prioritization
Urgency incorporates runtime and business context to surface the IaC misconfigurations that pose the greatest operational risk. Prioritize IaC misconfiguration issues using the following urgency hierarchy:
Urgency Level | Criteria | Recommended Action |
|---|---|---|
Top Urgent | The misconfiguration affects a deployed, internet-exposed asset in a production environment with critical application criticality | Remediate immediately. Open an automated fix PR or escalate to a Case |
Urgent | The misconfiguration affects a deployed asset in a staging or production environment, or the affected asset accesses sensitive data | Remediate within the current SLA window |
Not Urgent | The misconfiguration exists only in code (not deployed), or the affected asset is in a development or testing environment with low application criticality | Schedule for remediation during the next maintenance cycle |
Not Applicable | No Code-to-Cloud trace exists for the affected asset. Urgency signals cannot be computed | Establish Code to Cloud traceability by linking the repository to the relevant application |
Severity-based prioritization
Severity reflects the inherent risk of the misconfiguration based on the detection rule. Use severity as the baseline filter:
Severity | Remediation Priority |
|---|---|
Critical | Immediate remediation required. The misconfiguration introduces a directly exploitable attack vector. |
High | Remediate within the current sprint. The misconfiguration weakens a security control. |
Medium | Schedule for remediation. The misconfiguration deviates from best practices. |
Low | Address during routine maintenance. The misconfiguration has minimal security impact. |
Informational | No action required. The finding is advisory. |
Take action on IaC misconfiguration issues
The IaC Misconfigurations page supports the following actions for individual issues and bulk selections: change resolution status, assign an issue, open a fix pull request, apply manual fix guidance.
Change resolution status
Update the resolution status to track remediation progress.
From the main issues table: → →
From the side-card: →
Status values: New: The issue has not been triaged, In Progress: Remediation is underway, Resolved: The misconfiguration has been fixed and verified.
Assign an issue
Assign an IaC misconfiguration issue to a specific user for remediation.
From the main issues table: → →
From the side-card: →
Open a fix pull request
For IaC misconfiguration issues where an automated fix is available, Application Security can generate a pull request with the corrected IaC configuration.
Filter the issue table by Automatic Fix Available = Yes displays.
→ .
Select a naming method automated (default) or custom PR title and branch name.
Click .
Cortex Cloud generates a pull request in the source repository with the automated fix applied to the affected file.
Note
The Open Fix PR action is available only for issues detected through periodic scans where an automated fix exists. The action is not available for issues detected through PR scans.
Apply manual fix guidance
For IaC misconfiguration issues without an automated fix, the side panel provides manual remediation guidance.
Select an issue in the table to open the side panel.
Review the Manual Fix Suggestion field in the issue details.
The manual fix guidance includes:
A description of the misconfiguration and the expected secure configuration
Framework-specific remediation code samples (such as Terraform HCL, Kubernetes YAML)
The specific resource and arguments that require modification
Example: manual fix for a Terraform misconfiguration
```hcl resource "aws_autoscaling_group" "passtag" { launch_configuration = aws_launch_configuration.foobar.name tags = concat([ { "key" = "interpolation1" "value" = "value3" "propagate_at_launch" = true }, ]) } ```
Understand SLA compliance
Each IaC misconfiguration issue is tracked against an SLA target based on the issue severity. The SLA status is displayed in the issue side panel under General Details. The SLA calculation uses the issue creation timestamp and the configured severity-to-target-days mapping. Resolved issues stop the SLA clock at the resolution timestamp.
SLA Status | Description |
|---|---|
Within SLA | The issue is within the severity-based remediation window |
Approaching | The issue is nearing the SLA deadline. Prioritize remediation |
Overdue | The issue has exceeded the SLA deadline. Escalate or reassign |