Risk Scoring
Overview
Ledger assigns a risk level to every Secret it discovers, so you can prioritize which credentials to remediate first. Scores are derived from the metadata Ledger collects and are recalculated after every Scan, so each Secret's level always reflects the current state of your environment.
Factor Scores
Ledger evaluates each Secret across several independent factors. Each factor produces its own risk level and a short description of why it applies. A factor is only evaluated when the relevant data is available; if data is unavailable for a factor, it does not contribute to the overall score.
Age
Measured from the Secret's creation date.
| Age | Level |
|---|---|
| Less than 90 days | Low |
| 90 to 180 days | Medium |
| More than 180 days | High |
| Creation date unknown | Low |
Last Used
Measured from the Secret's most recent observed use. Unused credentials are strong candidates for retirement.
| Last used | Level |
|---|---|
| Less than 90 days ago | Low |
| 90 to 180 days ago | Medium |
| More than 180 days ago | High |
| Never used | High |
| Last-use time unknown | Low |
Reuse
Based on the number of Applications that reference the Secret.
| Applications | Level |
|---|---|
| 1 | Low |
| 2 | Medium |
| More than 2 | High |
Exposure
Based on where the Secret was found. Locations that offer less protection score higher.
| Location | Level |
|---|---|
| Kubernetes Secret (env var or volume mount) | Low |
| Kubernetes ConfigMap (env var or volume mount) | Medium |
| Hardcoded in the workload (env var literal, image, or command arguments) | Critical |
Authorization Scope
Ledger analyzes permissions attached to the Secret's owning Identity and classifies the breadth of access into a single tier. This factor is only evaluated when permission metadata is available for the owning Identity.
| Tier | Level | Examples |
|---|---|---|
| Scoped read-only | Low | Read-only actions, every resource scoped to a specific ARN. |
| Broad read or scoped write | Medium | Read-only access using Resource=*, or non-sensitive writes scoped to specific resources. |
| Write or sensitive data access | High | Any write on Resource=*, any access to a sensitive service, or bulk data-read access. |
| Admin or privilege escalation possibility | Critical | Wildcard administrative access, privilege escalation, cross-account sts:AssumeRole, or inverted (NotAction / NotResource) Allow statements. |
| Unanalyzed | Medium | The Identity has policies attached, but their documents could not be inspected. Surfaced for manual review rather than assumed safe. |
Overall Risk Score
A Secret's overall risk level is derived from its individual factor scores. The overall level starts as the highest level among all factors, then escalation rules are applied so that several moderate concerns can combine into a more serious one.
The default escalation rules are:
- If two or more factors are High, the overall level is raised to Critical.
- If three or more factors are Medium, the overall level is raised to High.
Example
A Secret stored in a Kubernetes Secret (exposure: Low), created 200 days ago (age: High), last used 210 days ago (last used: High), and used by a single Application (reuse: Low):
- Highest individual factor: High.
- Two factors are High (age and last used), so the overall level is escalated to Critical.
The Secret is reported as Critical.
Customizing Scores
All default scores are configurable per organization via the Console or CLI. There are two levels of customization:
Factor scores: The risk level assigned to any individual band can be changed. For example, a Secret stored in a ConfigMap could be configured to score High rather than the default Medium.
Overall risk score: The escalation rules can be replaced entirely. The conditions that trigger escalation, the number of factors required, and the resulting level can all be adjusted to match your organization's risk tolerance.