mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-27 12:18:59 +00:00
Anso
0384c47d1e
Add structured posture reasons derived alongside the posture verb in securityPosture.ts so the masthead and Overview tab can answer why the page is red, what to do first, and what clears it. Backend: - derivePostureReasons() returns blocker, review, and info reasons from the same SecurityPostureFacts used by deriveSecurityPosture() - deriveSecurityPosture() depends on derivePostureReasons() internally - Exposure split: public exposure with KEV, fixable, or EPSS >= 0.1 is a blocker; exposure without any of those is a review item - Fully dismissed exposed images produce no posture reason - postureReasons and primaryAction returned by the overview endpoint Frontend: - ReviewQueueCard on the Overview tab with per-row CTAs for blockers - Action summary in masthead subtitle and desktop primary CTA button - Card gated on posture not being Unknown - Backward compatible with older remote nodes
111 lines
6.5 KiB
Plaintext
111 lines
6.5 KiB
Plaintext
---
|
|
title: "Security"
|
|
description: "The command center for your fleet's security posture: an overview dashboard, image and Compose findings, secrets, scan history, suppressions, and scanner setup, all in one place."
|
|
---
|
|
|
|
Security is a primary surface in Sencho. The **Security** page in the top navigation brings the
|
|
capabilities that power [vulnerability scanning](/features/vulnerability-scanning) into one command
|
|
center, so you can answer "what should I look at first?" without hunting through other pages. It is
|
|
scoped to the active node: the findings and scanner status you see reflect whichever node is selected.
|
|
|
|
The page is organized into tabs.
|
|
|
|
## Overview
|
|
|
|
The overview opens with a status masthead that reads your **action posture** at a glance, the answer
|
|
to "what can and should I do right now?":
|
|
|
|
- **Action needed**: something concrete to act on, such as a fixable Critical or High finding, a
|
|
detected secret, a dangerous Compose setting, or a known-exploited (CISA KEV) CVE.
|
|
- **Monitoring**: Critical or High findings exist, but none are currently actionable (no fix
|
|
available, or already triaged).
|
|
- **Secure**: nothing actionable right now. This is never a claim that no vulnerabilities exist.
|
|
- **Unknown**: the scanner is not installed, or no scan has completed yet.
|
|
|
|
Raw Critical and High counts stay visible next to the posture as **scanner detections**, not as the
|
|
posture itself: a vulnerable component being present is not the same as a reachable, exploitable risk.
|
|
The masthead carries a standing note to that effect, and posture weighs fix availability, exploit
|
|
intelligence, and triage decisions rather than raw severity alone.
|
|
|
|
Below the masthead, a **Review queue** card leads the overview when actions or review items exist.
|
|
When the posture is Action needed the card is titled **Why Action needed** and lists each concrete
|
|
action with a count and a tab-shortcut button: fixable findings, known-exploited CVEs, detected
|
|
secrets, unacknowledged Compose risks, and publicly exposed affected images. When only monitoring
|
|
items remain (exposed images with no fix or known exploit, findings awaiting triage, stale or failed
|
|
scans) the card is titled **Review queue** and lists them without the red masthead, so the operator
|
|
can see what to keep an eye on without a permanent alarm.
|
|
|
|
The charts then lead with prioritization rather than raw severity: a **risk trend** for context,
|
|
an **action posture** breakdown (fixable, known-exploited, needs-review, accepted, not-affected), a
|
|
**top exploit-risk** list ranking actionable findings by known-exploited status then EPSS, and a
|
|
**severity-by-exploitability** quadrant that separates high-severity-but-unlikely findings from the
|
|
ones to act on first. The exploit-risk charts populate once exploit intelligence is enabled and images
|
|
are scanned. A signal rail summarizes the supporting numbers (scanned images, fixable findings,
|
|
secrets, Compose misconfigurations, stale scans, failed scans), and a status strip shows scanner health
|
|
and the active node's deploy enforcement posture.
|
|
|
|
If a node does not report an overview (for example an older remote node), the page falls back to a
|
|
clear "overview unavailable" state and the other tabs keep working.
|
|
|
|
## Images
|
|
|
|
Image findings list every scanned image on the active node with its highest severity. Selecting an
|
|
image opens the full scan report, where you can review vulnerabilities, triage a CVE, and export an
|
|
SBOM. Each finding carries evidence tags so you can tell scary from exploitable at a glance:
|
|
known-exploited (KEV), EPSS exploitation probability, the CVSS score, and vendor "will not fix"
|
|
status, alongside whether a fix is available.
|
|
|
|
## Compose risks
|
|
|
|
Compose risks surface the security misconfigurations Trivy finds in your stack definitions rather than
|
|
image CVEs: privileged containers, Docker socket mounts, host networking, broad host bind mounts, public
|
|
database ports, and containers running as root. Each entry opens its scan report with the specific
|
|
findings and how to fix them. This is a security audit of the Compose file; for deploy-readiness checks
|
|
(port conflicts, missing bind paths, unset variables, no healthcheck), use
|
|
[Compose Doctor](/features/compose-doctor) from the stack page instead.
|
|
|
|
## Secrets
|
|
|
|
The secrets tab lists images where Trivy detected exposed credentials or keys, and opens straight to
|
|
the secret findings for a scan.
|
|
|
|
## Policies
|
|
|
|
The Policies tab manages deploy-enforcement scan policies: severity thresholds that block or warn on a
|
|
deploy, scoped by stack pattern. Enforcement is an Admiral capability; see
|
|
[scan policies](/features/vulnerability-scanning#scan-policies) for the full configuration.
|
|
|
|
## Suppressions
|
|
|
|
CVE suppressions and misconfiguration acknowledgements are managed here, the same controls available
|
|
in Settings. These are governed by the local instance, so this tab is shown when you are on the local
|
|
node; switch to the local node to manage them.
|
|
|
|
Suppressing a CVE records a **triage decision**: accepted risk, not affected, false positive, fixed,
|
|
ignored, or needs review, with an optional OpenVEX justification. Decided findings stop driving the
|
|
action posture; a "needs review" decision stays counted but keeps the finding actionable. Admiral
|
|
instances can export the fleet's triage decisions as an OpenVEX document for use with other tooling.
|
|
|
|
## History
|
|
|
|
The History tab opens the scan history sheet, listing completed scans grouped by image with search and
|
|
two-scan comparison. Closing the sheet leaves the tab in place so you can reopen it. The **Scan
|
|
history** button in the [Resources Hub](/features/resources) is a shortcut to the same place.
|
|
|
|
## Scanner setup
|
|
|
|
Scanner setup manages the Trivy binary for the active node: install the managed binary, update it when
|
|
a new release is available, and toggle automatic updates. Trivy is installed independently on each
|
|
node. See [Installing Trivy](/operations/trivy-setup) for the full setup options.
|
|
|
|
It also toggles **exploit intelligence**: a daily background fetch of the CISA KEV catalog and FIRST
|
|
EPSS scores that powers the known-exploited and EPSS evidence tags. It degrades gracefully when
|
|
offline and can be turned off for air-gapped or firewalled hosts.
|
|
|
|
## What stays where
|
|
|
|
Resources keeps its per-image severity badges and scan actions, so you can still scan and inspect an
|
|
image from your inventory. Security is the place to review the whole picture; the deeper scanning
|
|
workflow (on-demand scans, scheduled fleet scans, scan policies, SBOM and SARIF export) is documented
|
|
under [Vulnerability scanning](/features/vulnerability-scanning).
|