Security risk scoring
Every finding carries a security score from 0 to 100 alongside its cost, so you can tell which unused resources are merely wasteful from the ones that are also a way in.
What the score measures
Cost tells you what a forgotten resource is charging you. It tells you nothing about what it would cost if someone found it first. An unattached 8 GiB volume and an unused IAM user with console access, no MFA and administrator rights can bill roughly the same amount, and they are not the same problem.
The security score is computed independently of the dollar figure and shown next to it. On the Resources page you can sort by either, which lets you work the list two different ways: by what saves the most money, or by what closes the most exposure.
How a score is built
Each finding starts from a base value for its resource type — an unused IAM role starts higher than an unattached volume, because of what it can do rather than what it costs. Observed exposure signals then add to it, and the total is scaled by how long the resource has been sitting unused.
A worked example
A security group attached to nothing, open to the world on port 22, first seen eight months ago:
| Contribution | Points | Why |
|---|---|---|
| Base — unused security group | 40 | Rules nobody reviews, waiting to be attached |
| Open ingress | +20 | Reachable from any address |
| Administrative port | +30 | Port 22, not an application port |
| Unused 8 months | ×1.2 (+18) | Scales what is already there. Shown as points in the app, so the figures add up |
| Total | 100 — Critical | 108 before the cap; scores stop at 100 |
Every finding carries this breakdown. Hover or focus the risk badge and you get the band’s meaning followed by each contribution, signed. A score never appears without the reasoning that produced it — a number on its own is a verdict, and you cannot check a verdict.
Why age multiplies rather than adds
Time does not create exposure; it compounds whatever exposure is already there. An unused role is dangerous partly because it is unused — nobody is watching it, nobody would notice it being assumed, and nobody will miss it if it is removed. So staleness scales the signals rather than contributing points of its own, and a resource with no exposure signals stays low no matter how long it sits.
The five bands
Bands answer the question a number cannot: what does this mean, and what should I do about it? Each band is defined by exploitability and consequence, not by where it happens to fall on the scale.
| Band | Score | What it means |
|---|---|---|
| Critical | 90–100 | Directly exploitable, with account-wide impact. Remediate immediately: revoke or rotate the affected credentials and review access logs. |
| High | 70–89 | Provides a viable path to unauthorized access, or exposes data outside the account. Remediate as a priority. |
| Medium | 40–69 | Not directly exploitable, but it increases the blast radius of a compromise elsewhere and is not being monitored. Remediate during normal maintenance. |
| Low | 1–39 | Limited exposure. Remove as routine hygiene, and to keep higher-severity findings visible. |
| Info | 0 | No security impact identified. Listed for completeness. |
Where the numbers come from
The weights are not invented. They are calibrated against the published severities of the AWS Foundational Security Best Practices controls, so a finding we call Critical lands in the band AWS puts the same condition in. A publicly restorable snapshot reaches Critical because AWS rates EC2.1 Critical; unrestricted access to an administrative port reaches it because of EC2.19.
The wording follows the same source. Findings are described in the register a security reviewer already reads, so what you export from StaleSweep sits alongside the rest of your evidence without translation.
What we look at
Every signal below is read from the AWS APIs during a normal scan, using the same read-only role. None of them require extra permissions, agents, or anything installed in your account.
| Signal | What raises the score | AWS control |
|---|---|---|
| Shared publicly | An EBS or RDS snapshot any AWS account can restore, or an AMI marked public. | EC2.1, RDS.1 (Critical) |
| Open ingress | A security group allowing traffic from any address (0.0.0.0/0 or ::/0). Administrative and database ports count for more than an application port. | EC2.18, EC2.19 |
| Administrator access | The AWS-managed AdministratorAccess policy, a customer-managed policy that allows every action on every resource, or an inline statement that does — attached directly or inherited through a group. | IAM.1 |
| External trust | A role whose trust policy names a principal outside your account, or a wildcard. | — |
| Reachable from the internet | A public IPv4 address, or a public endpoint on RDS, EKS or OpenSearch. Still authenticated — see the note below. | EC2.9 |
| IMDSv1 permitted | Instance metadata still answers unauthenticated requests, so an SSRF in a workload on the host can reach its credentials. | EC2.8 |
| Console access without MFA | An IAM user who can sign in to the console with a password and no MFA device. | IAM.5 |
| Credentials not rotated | Access keys past their rotation window, or a secret with rotation disabled — or configured and not actually running. | IAM.3, SecretsManager.1, SecretsManager.4 |
| Not encrypted at rest | An unencrypted volume, snapshot, file system or cluster. | EC2.3, RDS.3, RDS.4, EFS.1 |
| Runtime past end-of-support | A Lambda function on a runtime AWS no longer patches. | Lambda.2 |
What a missing signal means
A signal that does not appear in a finding’s breakdown means we did not observe it — not that we checked and found it safe. Those are different claims, and only one of them is ours to make.
So the score only ever rises on something we actually saw. If an API call fails, or a resource type does not report a given attribute, the signal is left out rather than assumed clean. The practical consequence: a low score means “nothing alarming was observed”, which is a weaker and more honest statement than “this resource is fine”.
What the score is not
Limits of the security score
- It is not a vulnerability scan. We read configuration through the AWS APIs. We do not run agents, scan running workloads, inspect application code, or test whether anything is actually exploitable.
- It does not replace a CSPM. The score only ever describes resources that a detector already flagged as unused or idle. A perfectly healthy, actively used resource with a wide-open security group is not in scope and will not appear.
- A public endpoint is not public data. Where a resource has a public network endpoint — RDS, EKS, OpenSearch — the score reflects reachability, not access. Those endpoints are still authenticated and can be restricted further. That is why the endpoint signal is weighted well below genuine public sharing, where anyone can read the data outright.
- Scores are a snapshot, not a live feed. Each finding is scored at the moment of the scan and stored with that scan. Changing a security group does not retroactively change last week's score; the next scan reflects it.
- We do not tell you what to delete. The score is evidence for a decision that stays yours. A high score on a resource you keep deliberately is a candidate for an exception rule, not an argument.
Working with it
Working with risk scores
- Sort the Resources page by Risk to work highest-exposure first, or by Monthly cost to work highest-spend first. Most teams do one pass of each.
- Open a finding to see the full breakdown: the band's meaning, every contributing factor, and the underlying detail we read from AWS.
- Resources you keep on purpose — a break-glass role, a compliance snapshot — belong in an exception rule, so they stop appearing without anyone having to remember why.
- Scheduled scans keep scores current. Because staleness scales the score, a resource left alone will climb bands over time on its own.