📎 Unreleased docs. This is the next version (from main), features here may change or not be in a release yet.See the latest release →

Guides

Rank findings by priority

On this page

Prioritization needs two attributes on each component: exposure (how reachable it is) and criticality (the business impact if it fails). Together they turn a wall of findings into a ranked P1–P4 list. See prioritization for how the bands are computed.

The guided wizard

The fastest way to set them is draugr classify. It asks a few questions per component and writes the labels back into your Saga, preserving comments and formatting. By default it only asks about unclassified components:

draugr classify                             # the descriptor in this directory
draugr classify --all                       # re-classify every component
draugr classify --components web,api        # only these two, classified or not

It finds the descriptor the way draugr scan does, so the path is only needed when you have more than one or it is somewhere else. --components is what to reach for when one classification turned out wrong: naming a component re-asks about it without disturbing the others.

Component: web
  Exposure, who can reach it?
    1) public         anyone on the internet can reach it, no sign-in
    2) authenticated  on the internet, but behind a login
    3) internal       only from inside your own network or VPN
    4) restricted     inside your network and locked down further, an allowlist, a private link, its own segment
  Choose [1-4]: 1
  Criticality, what happens if it fails or is breached?
    1) critical       an outage or data loss for the business
    2) important      degraded service, but no outage
    3) supporting     limited impact, easily worked around
  Choose [1-3]: 1
  → web: exposure=public, criticality=critical

The ladders

Both are fixed ladders (an organization can redefine the meaning; the levels stay stable):

exposuremeaningcriticalitymeaning
publicanyone on the internet, no sign-incriticalan outage or data loss for the business
authenticatedon the internet, behind a loginimportantdegraded service, but no outage
internalonly from inside your network or VPNsupportinglimited impact, easily worked around
restrictedinside your network and locked down further, an allowlist, a private link, its own segment

criticality: critical is not severity: critical. This ladder describes the component, the business impact if it fails. Severity describes a flaw, and a scanner assigns it: how much harm it could cause if it were exploited. A component you mark critical will still carry low-severity findings, and both words appear on the same finding. See prioritization for the tables where the two meet.

By hand, or from discovery

Prefer to hand-edit? Set exposure and criticality directly on a component. See the Saga schema. And draugr survey on a Kubernetes namespace already proposes each component's exposure from topology (Ingress/external Service → public, NetworkPolicy → restricted, else internal); review it, then fill in criticality. A component left unclassified is treated as high-risk, so nothing slips.

Once classified, focus with --min-priority P2; the gate is already --fail-on P1 (see the CLI reference).