Skip to content
downpipes docs

What to expect: reading your security centre

The security centre scores your recoverability and access posture and maps each finding to a named control standard. It is a read screen: the score is a pure computation over your account’s own observable state, it is recomputed live every time you open the screen, and the vendor reads nothing. This page walks you through what the score means, what a single check states, and what the coverage rollup shows, so nothing on the screen is a surprise.

Every check on the screen carries only redaction-safe metadata: an id, a title, a severity, a status, the named control it maps to, what was observed, how the determination was made, and how to fix it. No check can carry a key, a value or a fingerprint. That property is why the whole screen can be computed in your own account without anything sensitive leaving it.

What you will read, in one line

You read the posture score to see where you stand, work the checks that need attention from the top of the ranked list, then read the coverage rollup to see which of your resources are actually protected. Grading a finding is a separate Owner action; reading the posture needs no special role.

  1. Read the posture score

    The screen opens on the posture score: a single 0 to 100 number with an honest tone, and a breakdown across four tiles.

    The posture score card reading 69 out of 100 (needs work), with four tiles: Score, Needs attention, Marked by you, and Passing.

    What it means. The score is a weighted pass fraction over the applicable checks: each check has a fixed severity, a critical check weighs far more than a low one, and a check you mark not applicable is excluded from the score entirely. The tone is honest about the number: at or above 90 it reads strong, at or above 70 it reads fair, and below 70 it reads needs work, as the example does at 69. The Needs attention tile counts the failing and awaiting-attestation checks that are ranked below; Marked by you counts the determinations you have recorded, each of which stays listed with your reason; Passing counts the checks the platform verified on its own.

    What to do. Read the Needs attention count first. It is the work surface, and the checks behind it are ranked most severe first so the worst open item is always at the top.

  2. Read a check in full

    Each check is a card that states its finding without you needing to read any source. The needs-attention checks are shown first and in full.

    A single check card titled At least two Owners, mapped to the availability control, marked medium and fail, with Observed, How this is decided, and Remediation sections and a disabled Override button.

    What it means. The card names the control the check maps to (here, availability), a severity that sets its weight, and a status. Observed is the plain fact the check found, “1 Owner configured” in the example. How this is decided is the one-line method, so the verdict is never a black box. Remediation is the fix. A check the platform genuinely cannot verify by itself reads “needs attestation” in amber rather than a red failure you have no way to clear, and it does not earn its weight until you grade it.

    What to do. Work the ranked list from the top; each card carries its own remediation. Recording a determination (attesting a pass, describing a compensating control, marking not applicable, or accepting the risk) is an Owner action, so the Override control is shown disabled here, where the screen was read as a viewer.

  3. Read the coverage rollup

    Below the checks, the coverage section answers a different question: which of your resources are backed up, and which are only claimed to be.

    The coverage section reading Coverage is unknown, with a note that no resource inventory is recorded so the engine cannot tell what exists, and a Set up discovery button.

    What it means. Until you record a reference inventory the section does not guess: it reads coverage is unknown, because the absence of an inventory means the engine cannot tell what exists, never that everything is covered. Read-only discovery records only a resource id and a label, never a credential or a value. Once an inventory is in place this becomes a rollup that is deliberately conservative: a resource is only ever called protected when it is backed up, its runs succeed, and a restore has actually been proven; a resource that is backed up but never restore-proven sits in not yet proven and is never shown as safe; a resource that exists with no downpipe covering it sits in not backed up.

    What to do. Select Set up discovery to record your reference inventory, then clear the not-backed-up gaps and prove recoverability for the unproven ones. The full detail is on coverage and gaps.

Where the numbers come from

The score, the checks and the coverage rollup are one computation over your account’s own observable state: presence booleans, per-downpipe recency, expiry states and a few counts, run through a fixed function that has no input or output of its own. The console renders the result, and the standing claims behind it stay precise: the encryption is post-quantum hybrid and the audit trail is tamper-evident, meaning an alteration is detectable rather than prevented. For how the score is weighted and what each of the named checks looks at, read the posture score reference.

About this example

This page is generated from a live run, so its screenshots cannot drift from what the console actually renders.

  • Read live, as a least-privilege viewer. The three screenshots were taken from the real security centre on a synthetic harness estate that is not any customer or public environment, using a disposable viewer identity that was granted for the capture and torn down afterwards. The security centre is a read screen, so a viewer is enough; no owner session and no key ceremony were involved.
  • Net-zero, and it was checked. The walkthrough only viewed the screen. A request spy on the browser session aborted and recorded every non-GET to the admin API and caught none. The posture score and every check’s status, together with the estate roster, were read before and after the capture and were byte-identical. The disposable viewer’s role grant and passkey were removed at the end, and no recovery code was spent.
  • Redaction replaces a value, it does not blank a box. These estates are synthetic, so the ids, key fingerprints, run values and counts you see are fake test data, shown in full just as your own console shows yours. Only two things are ever sensitive: a real hostname and a real credential. When one appears the capture replaces it in place before the shot, a hostname becoming example.downpipes.io and a credential becoming REDACTED, then scans the result and refuses to write any shot that still shows a real one.
  • And the redaction was checked, with a deliberate negative control. As a control, the shell engine host was captured with that replacement turned off: the scan refused it on the infra-hostname pattern and wrote nothing, which is the gate working as intended.

Last updated .