Business Challenge
#43 put Inspector in the security account and moved on. This is what the severity column on its findings list actually means.
AWS is precise about the derivation, and the precision is the problem: “Amazon Inspector uses the NVD/CVSS score as the basis of severity scoring for software package vulnerabilities”, and that score is “a base score because it reflects the severity of a vulnerability according to its intrinsic characteristics, which are constant over time. This score also assumes the reasonable worst-case impact across different deployed environments.”
Constant over time, and worst-case across environments. Those are not defects — they are what a base score is for. They do mean the column you sort by was computed without reference to your account.
There is a number that knows about your estate. “Amazon Inspector determines the score by correlating CVSS base score information with information from your compute environment, such as network reachability data and exploitability data.”
That is exactly the right idea, and then read its scope. It is for “Amazon Elastic Compute Cloud (Amazon EC2) instance findings”, and “These details are only available for package vulnerability findings.” And:
“Note: The Amazon Inspector score is not available for Linux instances running Ubuntu. Ubuntu uses a custom severity rating system that differs from CVSS scores.”
So container images, Lambda functions, code vulnerabilities, network reachability findings and every Ubuntu instance are ranked by the environment-blind number only. On a lot of estates that is most of it.
FixKnow which of your resources can produce an Inspector score before building a process that assumes one. Where it is absent, severity is a property of the CVE, not of your exposure — so the exposure has to come from somewhere else.
"Continuous" is doing a lot of work in the marketing and very little in the documentation: “Amazon Inspector performs network reachability scans once every 12 hours and package vulnerability scans on a variable cadence that depends on the scan method associated with the EC2 instance.”
Twelve hours is a number. The one that matters for patching is the one AWS declines to give — and the reason is in the mechanism. Inspector does not look at the instance; it looks at an inventory of the instance. “Amazon EC2 scanning extracts metadata from your EC2 instance before comparing the metadata against rules collected from security advisories.”
So a finding closes when the inventory says the package changed, not when the package changes. Patch at 09:00 and the finding stands until the next collection — by SSM agent, or by “Amazon EBS snapshots” under agentless scanning. The patch is not the event Inspector observes.
FixMeasure remediation from the scan that confirms it, not from the change ticket, and treat a persisting finding as unconfirmed rather than unfixed until a collection has run.
A package vulnerability finding carries, in AWS's own list: “EPSS score”, “Inspector score”, “CVSS 3.1 from Amazon CVE”, “CVSS 3.1 from NVD”, and “CVSS 2.0 from NVD (where applicable)”.
Two of those are the same metric from different publishers, because “Amazon Inspector supports Amazon, Debian, and RHEL vendors. Each vendor provides a CVSS v3.1 base score. For other vendors, Amazon Inspector uses a CVSS base score provided by the National Vulnerability Database (NVD).” Amazon and NVD can score the same CVE differently.
AWS builds a UI around the disagreement rather than resolving it: the finding detail panel “shows the difference between the base score and the Inspector score… If the scores differ this panel shows an explanation of why.” Which is a good design, and is also an admission that the single severity label is a reduction of five numbers.
FixUse EPSS for "how likely is this to be exploited" and the Inspector score for "how exposed is this instance". They answer different questions and neither is the severity column.
Architecture
Two inventory paths, a scoring pipeline with an optional environment-aware stage, and a severity label at the end of it.
What a scan actually reads
The sentence that reframes the whole service: “Amazon EC2 scanning extracts metadata from your EC2 instance before comparing the metadata against rules collected from security advisories.”
Inspector is a comparison between two lists — your package inventory and a rules set built from advisories. It does not execute anything, probe anything, or verify that the vulnerable code path is reachable in your application. Both halves can go stale independently: the advisory rules on AWS's side, and the inventory on yours.
The inventory arrives one of two ways, and on first activation both are on: “Agent-based scanning collects software inventory from your instances using the Amazon EC2 Systems Manager (SSM) agent, and agentless scanning collects software inventory using Amazon EBS snapshots”, with “your account is automatically enrolled in hybrid scanning, which uses both scan methods”.
“For agent-based scanning, the Amazon EC2 instance must be managed by SSM in same AWS account.”
Same account, not the organisation. An estate where SSM management is centralised into a tooling account does not satisfy that for agent-based scanning, and the failure is an instance that simply produces fewer findings rather than an error. Hybrid enrolment softens it — agentless can still snapshot — which also means the gap is invisible as long as the other method covers it, and appears the moment somebody switches to agent-based only.
The two numbers, side by side
| CVSS base score → severity | Inspector score | |
|---|---|---|
| What it reflects | “intrinsic characteristics, which are constant over time” | “information from your compute environment, such as network reachability data and exploitability data” |
| Environment assumption | “reasonable worst-case impact across different deployed environments” | Correlated with yours |
| Resource scope | All finding types | EC2 instance findings |
| Finding-type scope | All | “only available for package vulnerability findings” |
| OS exceptions | None stated | “not available for Linux instances running Ubuntu” |
| Drives the severity column | Yes | Contributes, where it exists |
Read the scope rows together and the asymmetry is the finding. The environment-blind score is universal. The environment-aware score is conditional on three things at once. Any process that says "prioritise by exposure" is, for a container image or an Ubuntu host, prioritising by something else.
The bands, and where they put the weight
| Score | Rating | Width of the band |
|---|---|---|
| 0 | Informational | a single value |
| 0.1–3.9 | Low | 3.8 |
| 4.0–6.9 | Medium | 2.9 |
| 7.0–8.9 | High | 1.9 |
| 9.0–10.0 | Critical | 1.0 |
The bands narrow as they rise, which is sensible — precision matters more at the top. It also means a 6.9 and a 4.0 share a label while a 6.9 and a 7.0 do not, and the 0.1 between them is the difference between two queues in most organisations' process.
And there is a sixth state that is not a number at all: “Package vulnerability findings can also have a severity of Untriaged. This means that the vendor hasn't yet set a vulnerability score for the detected vulnerability.” AWS recommends “using the reference URLs for the finding to research that vulnerability and respond accordingly” — that is, do it yourself. An Untriaged finding sorts nowhere and is the one most likely to be new.
Other finding types are scored by other systems entirely
Code vulnerabilities. “For code vulnerability findings Amazon Inspector uses the severity levels defined by the Amazon Q detectors that generated the finding. Each detector is assigned a severity using the CVSS v3 scoring system.” So the severity is a property of the detector, fixed in advance, rather than of the instance of the problem it found.
Network reachability. A lookup table on service, port and path type, and the path type matters as much as the port: “The value in the Open path rating column represents open paths from virtual gateways, peered VPCs, and AWS Direct Connect networks.” SSH on 22 is Medium from the internet and Low from an open path; Telnet on 23 is High and Medium. Everything unlisted is “Informational”, which is a design decision worth knowing about before you filter the informational tier out of a dashboard.
Why This Architecture Holds Up
The default is the conservative one, for a stated reason
“Due to FedRAMP requirements, Amazon Inspector uses the CVSS v3.1 base score as the default score. However, a CVSS 4.0 base score will be included in your vulnerability metadata when one is available.”
That is an unusually candid "why": the default is not the newest standard because a compliance regime pins it. The newer score is carried alongside rather than suppressed, which is the right call — and it means a team reporting CVSS 4.0 figures and a team reporting the Inspector default are both reading the same finding correctly and will disagree.
Vendor-supplied scores are a feature, and a source of divergence
“Amazon Inspector supports Amazon, Debian, and RHEL vendors. Each vendor provides a CVSS v3.1 base score. For other vendors, Amazon Inspector uses a CVSS base score provided by the National Vulnerability Database (NVD).”
Preferring the distribution's own score is correct — the distribution knows whether it compiled the vulnerable feature, and backports routinely make an upstream CVE inapplicable. It also means the same CVE on Amazon Linux and on an unsupported distribution in the same account can come out at two severities, from two publishers, both accurate.
Which is why the finding carries both “CVSS 3.1 from Amazon CVE” and “CVSS 3.1 from NVD” rather than one reconciled figure. The divergence is data.
In the recommendation to move to Enhanced EC2 Scanning: the VM Scanner “uses the same scanning mechanism across operating systems and across other Amazon Inspector supported resources, which produces more consistent findings than the Amazon Inspector SSM plugin. On Windows in particular, it avoids the per-query timeouts that can cause the Amazon Inspector SSM plugin to report findings inconsistently.”
Inconsistent findings from a timeout is the worst failure shape a scanner has, because it is indistinguishable from a clean result. If you are on the SSM plugin and your Windows fleet looks quieter than your Linux fleet, that sentence is the first thing to rule out. Upgrading is opt-in, under Settings > Scan Settings, so nothing happens by waiting.
The base metrics are published, which makes the ranking arguable
The comparison panel lists the CVSS base metrics, and two of them carry most of the prioritisation argument in practice.
Attack Vector — “for Amazon Inspector findings this can be Network, Adjacent Network, or Local”. A Local vector on an instance nothing logs into is a different problem from a Network vector on a public one, and the base score cannot know which you have. The Inspector score can, where it exists, because reachability is one of its inputs.
Scope — “If this value is Unchanged the affected resource and the impacted resource are the same. If this value is Changed then the vulnerable component can be exploited to impact resources managed by different security authorities.” Changed is the blast-radius flag, and it is the metric worth filtering on when a list of criticals is too long to work through in order.
Two cadences, and only one of them is published
“once every 12 hours” for network reachability — twice a day, so a security group change is reflected within half a day. Package vulnerability scanning gets “a variable cadence that depends on the scan method” and no number.
Declining to publish it is defensible: it genuinely varies by method, instance state and inventory behaviour, and a published figure would become an SLO it is not. The consequence for you is that remediation time cannot be measured against a documented interval, so it has to be measured against observed behaviour in your own account.
Key Architecture Decisions
| Decision | Choice | Reasoning |
|---|---|---|
| Sorting a findings queue | Severity plus Scope and Attack Vector, not severity alone | Severity comes from a base score assuming “worst-case impact across different deployed environments”. |
| Relying on the Inspector score | Confirm it exists for the resource first | EC2 instance findings, package vulnerabilities only, and absent on Ubuntu. |
| Ubuntu fleets | Expect the environment-aware score to be missing | “not available for Linux instances running Ubuntu” — a stated exception, not a gap. |
| Likelihood of exploitation | Read EPSS, which is on the finding | It is a different axis from severity and is already there. |
| Measuring remediation | From the confirming scan, not the change ticket | Findings close on inventory, and the package cadence is “variable”. |
| Scan method | Keep hybrid unless you have a reason | It is the activation default, and each method has a different blind spot. |
| Agent-based coverage | Audit SSM management per account | “must be managed by SSM in same AWS account”, and a miss is quiet. |
| Windows fleets on the SSM plugin | Upgrade to Enhanced EC2 Scanning | AWS names per-query timeouts that “report findings inconsistently”. |
| Untriaged findings | Route them to a human, not to the bottom of a sort | No vendor score yet, so they sort nowhere and are often the newest. |
| Reporting CVSS figures | State the version and publisher | v3.1 is the default “due to FedRAMP requirements”; 4.0 and NVD-vs-Amazon both appear. |
| Filtering out Informational | Know what falls into it | For network reachability, everything unlisted is Informational by design. |
The audit worth running
Take your critical and high findings and ask how many carry an Inspector score at all. The ones that do can be re-read against reachability; the ones that cannot are ranked on intrinsic severity alone, and splitting the queue on that basis is more useful than sorting it harder.
Then count findings by severity against findings by EPSS. Where a high-severity, low-EPSS item is above a medium-severity, high-EPSS one in your work queue, the queue is ordered by the wrong column for the question "what is likely to be used against us".
Closing Thought
Inspector publishes more about its own scoring than most services publish about anything. Five scores per finding, the base metrics tabulated, a panel that explains the disagreement between two of them, and a note telling you the environment-aware score is missing on Ubuntu. None of it is hidden.
What is easy to miss is that the column the console sorts by is one of the environment-blind ones, by definition rather than by oversight — AWS defines a base score as assuming worst-case impact across deployed environments. It is the right default, because a base score is the one figure available for every finding type. It also answers "how bad is this vulnerability" when the question in front of an on-call engineer is "how bad is this vulnerability here".
Which is where this run of posts ends up. #74, #75 and #76 were each about a number read as answering a question it was not computing. The pattern underneath all four is the same: the figure is correct, the documentation is honest about what it measures, and the reading happens at a glance from a column heading. Sometimes the answer is a better metric — the Inspector score is exactly that, where it exists. More often it is knowing which question the number in front of you is answering.
Security & Identity — Amazon Cognito user pools: what a token actually asserts after a group is removed, why the ID token and the access token expire on different clocks, and how refresh token revocation propagates.
Official AWS Reference
- Understanding severity levels for your Amazon Inspector findings — the NVD/CVSS basis, the base-score definition, the v3 band mapping, Untriaged, the five scores carried on a package finding, and the network reachability severity table
- Viewing the Amazon Inspector score and understanding vulnerability intelligence details — the correlation with compute-environment data, the EC2 and package-vulnerability scope, the Ubuntu exception, vendor-supplied base scores, the FedRAMP default, and the base metric definitions
- Scanning Amazon EC2 instances with Amazon Inspector — metadata extraction against advisory rules, the 12-hour network reachability cadence and the variable package cadence, agent-based and agentless inventory, hybrid enrolment, the same-account SSM prerequisite, and the Enhanced EC2 Scanning recommendation
- Suppressing Amazon Inspector findings — further reading on suppression rules, which interact with everything above; no claims in this post are drawn from it
Comments