mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 20:00:08 +00:00
Anso
04e69021e0
Scan policies, deploy enforcement, the suppression-aware deploy-block toggle, SARIF export, and OpenVEX export now work on Community, matching the rest of the vulnerability-scanning surface that was already free. Backend: drop the tier gate from the seven security routes and from the dashboard configuration-status scan-policies row, so the Dashboard and Fleet config cards stop hiding the Vulnerability scanning row. Reading policies stays auth-only; mutations and exports stay admin-only. Frontend: always show the Policies tab and panel, the SARIF and VEX export actions, and the honor-suppressions toggle for admins. Docs: move scan policies, SARIF, and OpenVEX to every tier across the feature and API-reference pages; clarify that Fleet Sync's cross-node replication remains the paid part.
111 lines
6.4 KiB
Plaintext
111 lines
6.4 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. 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. You 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).
|