When Snyk IaC flags a misconfigured Terraform resource — say, a security group open to 0.0.0.0/0 on port 22 — it doesn't just report "this is bad." It attaches a severity: Critical, High, Medium, or Low. That rating drives which tickets get filed at 2 a.m. and which sit in a backlog for the next sprint, so understanding how it's calculated matters more than most teams realize. Snyk's public documentation describes a two-part model: a static, rule-level severity assigned by its security research team based on worst-case impact, and a layer of exploitability reasoning — how exposed the resource is, what an attacker would need to actually reach it, and what happens next if they do. This post walks through that methodology mechanically, using real rule examples, so security and platform teams can calibrate their own triage instead of treating severity labels as a black box.
What severity levels does Snyk IaC assign to misconfigurations?
Snyk IaC uses four tiers — Critical, High, Medium, and Low — assigned per detection rule rather than computed dynamically at scan time. Each rule in Snyk's policy catalog (covering Terraform, CloudFormation, Kubernetes manifests, ARM templates, and Helm charts) ships with a default severity baked in by Snyk's security research team, based on the type of misconfiguration it detects. For example, a publicly readable S3 bucket (rule family covering aws_s3_bucket ACL and policy checks) is typically rated High, an IAM policy statement using "Action": "*" combined with "Resource": "*" is rated Critical, and a missing resource tag or an unset description field on a security group is usually Low. This is a fundamentally different model from CVE scoring: there's no NVD entry or vendor advisory to anchor the number, so the severity is Snyk's own qualitative judgment about the class of misconfiguration, published and documented per rule in its rules reference rather than computed from a public vulnerability database.
How does exploitability factor into a misconfiguration's severity rating?
Exploitability enters through the same reasoning CVSS uses for its exploitability sub-score — attack vector, attack complexity, and privileges required — just applied qualitatively to configuration state instead of a software flaw. A misconfiguration that's remotely reachable with no authentication (an internet-facing load balancer with no security group restrictions) sits at the top of the scale because the attack vector is network-based and attack complexity is low: no credentials, no pivot, no social engineering required. A misconfiguration that requires an attacker to already hold valid IAM credentials inside the account (an overly permissive but non-public IAM trust policy) is rated lower, because the effective attack surface assumes a prerequisite compromise has already happened. Snyk's rule descriptions typically spell this reasoning out in plain language — for instance, describing a public RDS instance as exploitable "by any actor with network access to the endpoint," versus an internal misconfiguration described as exploitable "by an authenticated principal with sufficient permissions." The severity number reflects that gap in required attacker capability, not just the theoretical worst case.
Why do two similar-looking misconfigurations get different severity scores?
Two findings that look alike in a diff can land in different tiers because Snyk's rules encode the specific resource, exposure path, and data sensitivity involved, not just the generic pattern of "overly permissive." An unencrypted EBS volume attached to a private subnet instance is rated Medium, while an unencrypted RDS instance holding structured data and reachable via a public subnet is rated High — same underlying gap (missing encryption at rest), different blast radius because one asset type is presumed to store more sensitive data and sit closer to the network edge. Similarly, a security group rule opening port 443 to the internet is treated very differently from one opening port 3389 (RDP) or 22 (SSH), because the latter two expose remote administrative access rather than an expected public-facing service. This is why teams that only filter by keyword ("any public exposure") end up over-triaging: the rule catalog already differentiates exposure of a web port from exposure of a management port, and collapsing that distinction back into one bucket throws away the exploitability judgment Snyk built into the rule.
Can teams override or customize Snyk's default severity scoring?
Yes — Snyk IaC supports custom severity overrides at the organization level through both the web UI and the Policies API, letting teams re-rate a rule's default severity to match their own risk model. A team running short-lived ephemeral dev environments, for instance, might downgrade a publicly-exposed-storage rule from High to Medium for that specific environment tag, while a team handling regulated customer data might upgrade a Medium-rated logging gap to High because audit requirements make it a compliance blocker regardless of direct exploitability. This override sits on top of, not instead of, Snyk's default rating — the base severity remains Snyk's published assessment, and the custom policy is an organization-specific delta applied at ingestion. It's a meaningful distinction for audit purposes: if a finding shows up as Medium in a Snyk report, you can trace whether that's Snyk's default judgment or a deliberate organizational override, which matters when a regulator or customer questionnaire asks why a given misconfiguration wasn't treated as higher risk.
How does cloud runtime context change severity after a resource is deployed?
Once IaC-detected resources are actually running, Snyk's cloud-context products (Snyk Cloud) layer live exposure signals on top of the static IaC severity to re-prioritize what was flagged at plan time. A misconfigured S3 bucket policy that Snyk IaC rated High at scan time can be escalated in a live-context view if runtime data shows the bucket is actually internet-reachable and contains objects, versus the same rule firing on a bucket that turned out to be behind a VPC endpoint with no public route in practice. This is the mechanism by which Snyk claims to reduce noise between "theoretically possible" and "practically exploitable" — the IaC scan catches the pattern before deployment, and the cloud layer confirms or downgrades the practical exploitability once the resource exists with real network topology and real IAM bindings attached to it. Teams relying solely on the pre-deployment IaC severity are working from the worst-case assumption; teams with the cloud layer connected get a second data point about whether that worst case is actually reachable in their specific account.
How Safeguard Helps
Snyk IaC's severity model is a useful, transparent piece of the puzzle — but it's one scanner's opinion, scoped to one stage of the pipeline (plan-time infrastructure code), running against one rule catalog. Most engineering organizations don't run Snyk IaC in isolation: they're also pulling SCA findings, container scan results, SAST output, and CSPM alerts from other tools, each with its own severity vocabulary and its own definition of "Critical." Safeguard's software supply chain security platform is built for exactly that seam. It ingests findings from IaC scanners, dependency scanners, and runtime cloud posture tools into a single normalized risk view, so a High-severity Snyk IaC finding on a security group can be correlated against the actual workload running behind it, the SBOM of the software deployed there, and any active exploitation signals — rather than living as an isolated line item in a Snyk dashboard. That correlation is where exploitability judgments get sharper: a misconfiguration rated High in isolation might be low priority if the resource behind it has no sensitive data and no external dependency exposure, and a Medium-rated finding might deserve immediate attention if it sits in front of a service with a known-vulnerable, internet-facing dependency. Safeguard doesn't replace the scanner-level severity work that Snyk and others publish — it consumes it as one input among several, giving security teams a supply-chain-wide picture instead of a tool-by-tool one, so the question isn't "what did this one scanner call it" but "what does this misconfiguration actually mean once every other signal about the environment is accounted for."