mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-12 19:57:37 +00:00
Anso
fcd44f5693
* fix(security): tie fixable CVE posture to image-update evidence Stop treating Trivy fixed_version alone as an Update affected images CTA. Reuse persisted ImageUpdateService status so Security only offers Review update when an applicable image update is confirmed, and otherwise surfaces waiting or uncertain remediation with truthful affordances. * fix(security): move image-update recheck helper out of OverviewTab Satisfy react-refresh/only-export-components so Frontend lint passes. * fix(security): preserve posture reason image targets in Images drill-down Carry affected image refs on overview reasons so public exposure and related CTAs open a clearable targeted Images list instead of an unfiltered hunt. * fix(security): attach Networking exposure intent to posture targets Preserve stack/service context and intentional classification on network-exposed Security reasons without suppressing risk or claiming Internet reachability. * fix(security): persist Images exposure intent and triage scope Standing image summaries carry Networking intent context with cap-safe aggregates, Anatomy Networking links, and scan-sheet triage that defaults to the current image. * fix(security): clear CI lint errors for exposure helpers * fix(security): stop intentional exposure from forcing Action needed Separate exposure fact, intent correctness, and vulnerability drivers so package fixed_version cannot recreate a permanent public_exposure blocker. * fix(security): define Monitoring residual-risk narrative * fix(security): define Secure via residual Crit/High triage Replace triage-blind raw Crit/High Secure gating with residual material risk so accepted and ignored stay Monitoring, while not_affected, false positive, and fixed can clear residual without claiming no detections. * fix(security): exclude rollback-hold images from Security scans Hold-only sencho-rb tags are recovery state; keep them out of Trivy node scans, Security inventory, and Overview posture while dual-tagged images remain under their registry tag. * fix(security): keep authoritative no-update rows after preview Opening a stack page must not delete ok+false stack_update_status evidence; Security treats a missing row as uncertain and would flip waiting-upstream to unknown.
219 lines
15 KiB
Plaintext
219 lines
15 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.
|
|
|
|
<Frame>
|
|
<img src="/images/security/overview.png" alt="Security page Overview tab with an Action needed masthead, CRITICAL/HIGH/LAST SCAN stat tiles, a Why Action needed review-queue card, a 30-day risk trend chart, an Action posture breakdown, and a Scan this node button." />
|
|
</Frame>
|
|
|
|
The page is organized into tabs: Overview, Images, Compose risks, Secrets, Policies, Suppressions,
|
|
History, and Scanner setup.
|
|
|
|
## 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 that Sencho can support right now, such as a
|
|
newer image available to review for Critical or High findings, a detected secret, a dangerous
|
|
Compose setting, a known-exploited (CISA KEV) CVE, elevated exploit risk on a network-exposed
|
|
workload, or exposure that conflicts with declared Networking intent.
|
|
- **Monitoring**: no Action needed blocker, but material residual risk, a pending review, or
|
|
relevant uncertainty remains. Residual Critical/High include undecided findings and accepted or
|
|
ignored residual risk. Package fixes may exist without an applicable container-image update,
|
|
workloads may be intentionally network-exposed without an independent Security driver, and
|
|
waiting-upstream or update-check-uncertain rows appear under **Why Monitoring** without a red
|
|
masthead.
|
|
- **Secure**: no Action needed blocker and no residual material Critical/High or pending
|
|
security-review condition under current evidence. Not affected, false positive, and fixed can
|
|
clear residual risk for those findings; accepting residual risk does not. This is never a claim
|
|
that no scanner detections exist.
|
|
- **Unknown**: the scanner is not installed, or no scan has completed yet.
|
|
|
|
Monitoring keeps residual risk visible (raw detections, accepted risk, waiting-upstream rows,
|
|
intentional exposure context). Secure is stricter: residual Critical/High and review reasons must
|
|
be cleared, not merely the absence of an immediate action.
|
|
|
|
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 package-fix evidence,
|
|
image-update availability, exploit intelligence, exposure, and triage decisions rather than raw
|
|
severity alone. A Trivy package fix does not by itself mean Sencho can update the image; when a
|
|
newer image is confirmed available the review queue offers **Review update**, and when no applicable
|
|
update is identified it surfaces **Waiting for upstream image** instead of an impossible update
|
|
instruction. Deploy policies remain orthogonal: they may still block admission on package-fix
|
|
Critical/High even when Security posture is Monitoring.
|
|
|
|
An admin on a node with a ready scanner sees a **Scan this node** button above the review queue. It
|
|
opens a popover to pick any combination of image vulnerabilities, image secrets, and Compose
|
|
misconfigurations, then runs a node-wide scan in the [deploy progress](/features/deploy-progress)
|
|
modal; a partial failure across images or stacks surfaces as a warning toast rather than reading as
|
|
clean.
|
|
|
|
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: newer images available to review, known-exploited
|
|
CVEs, elevated exploit risk on network-exposed workloads, detected secrets, unacknowledged Compose
|
|
risks, and exposure that conflicts with declared Networking intent. Intentional network exposure is
|
|
Security context, not an independent Action needed reason by itself. When only monitoring items
|
|
remain (waiting for an upstream image, update availability unknown, network-exposed images not yet
|
|
classified, findings awaiting triage, stale or failed scans) the card is titled **Why Monitoring**
|
|
and lists them with View findings shortcuts (and Check again when image update availability could
|
|
not be established and you can manage the node), so the operator can see what to keep an eye on
|
|
without a permanent alarm. Shortcuts that carry affected image identities open Images already
|
|
narrowed to those images, with a clearable banner so you can return to the full list. When the
|
|
reason includes exact driving findings, opening an image filters the scan report to that contributing
|
|
set.
|
|
|
|
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
|
|
|
|
<Frame>
|
|
<img src="/images/security/images-tab.png" alt="Security page Images tab listing scanned images with Image, Findings, Last scan, Severity, and Actions columns; findings show critical/high counts and fixable totals, and one row shows a Clean badge." />
|
|
</Frame>
|
|
|
|
Image findings list every scanned image on the active node with its highest severity. Sencho
|
|
rollback-hold tags (`sencho-rb/...:hold`) are recovery state, not Security inventory: node-wide
|
|
scans skip them, and existing hold-only scan rows stay out of this list and the Overview posture.
|
|
When you arrive
|
|
from a Security posture action that named specific images, the list opens already filtered to those
|
|
images and shows a clearable banner with the reason and count. Images configured beyond loopback (or
|
|
with host networking) carry a **Network exposed** evidence label on the row during ordinary browsing,
|
|
not only after a posture drill-down. That label means Compose declares non-loopback reachability; it
|
|
is not a claim that the service is reachable from the Internet. When Networking exposure intent is
|
|
available, the row also shows compact intent evidence (for example Intent: public, Intent mismatch,
|
|
or Intent: not classified). Open Networking from that evidence to review or correct classification
|
|
for the matching stack. Intentional exposure raises the security relevance of vulnerable findings
|
|
but does not by itself keep the masthead on Action needed. Open the image, remediate, or triage
|
|
individual findings (Accepted risk and related decisions). There is no image-level "accept residual
|
|
risk" control. Compose Doctor acknowledgements are a separate triage surface and do not clear
|
|
Security exposure context. Selecting
|
|
an image opens the full scan report, where you can review vulnerabilities, triage a finding, compare
|
|
against another scan, and export a CSV, a SARIF file, or 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.
|
|
|
|
<Frame>
|
|
<img src="/images/security/scan-report.png" alt="Vulnerability scan report sheet for nginx:latest showing 340 vulnerabilities, a Critical/High/Medium/Low summary, Compare/CSV/SARIF/SBOM export buttons, and a findings table with CVE, package, severity, installed version, and per-row EPSS and CVSS evidence tags." />
|
|
</Frame>
|
|
|
|
## Compose risks
|
|
|
|
<Frame>
|
|
<img src="/images/security/compose-risks.png" alt="Security page Compose risks tab in its empty state, with intro text describing privileged containers, Docker socket mounts, host networking, and broad capabilities, and a 'No Compose risks found' message prompting a node scan or per-stack config scan." />
|
|
</Frame>
|
|
|
|
Compose risks surface the security misconfigurations Trivy finds in your stack definitions rather than
|
|
image CVEs, such as privileged containers, Docker socket mounts, host networking, or broad
|
|
capabilities. 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
|
|
|
|
<Frame>
|
|
<img src="/images/security/secrets.png" alt="Security page Secrets tab listing an image with detected secret findings and a severity badge that opens the scan report's Secrets tab." />
|
|
</Frame>
|
|
|
|
The secrets tab lists images where Trivy detected exposed credentials or keys, and opens straight to
|
|
the secret findings for a scan.
|
|
|
|
## Policies
|
|
|
|
<Frame>
|
|
<img src="/images/security/add-policy.png" alt="New policy dialog with a Name field, an optional glob-style Stack pattern field, Block conditions toggles for Severity threshold, Known-exploited (KEV), and Package fix available (Critical/High), a Block on deploy toggle, and an Enabled toggle." />
|
|
</Frame>
|
|
|
|
The Policies tab manages deploy-enforcement scan policies: a policy names one or more block
|
|
conditions (a severity threshold, a known-exploited CVE, a fixable Critical or High finding), scoped
|
|
to a glob-style stack pattern or left blank to apply fleet-wide. Turning **Block on deploy** off keeps
|
|
a policy evaluating and alerting without rejecting the deploy. A separate **Honor suppressions in
|
|
deploy blocks** switch, off by default, decides whether a suppressed CVE still counts toward a block.
|
|
See [scan policies](/features/vulnerability-scanning#scan-policies) for the full configuration
|
|
reference.
|
|
|
|
## Suppressions
|
|
|
|
<Frame>
|
|
<img src="/images/security/suppressions.png" alt="Security page Suppressions tab with a CVE suppressions section (Export VEX and Add suppression buttons) and a Misconfig acknowledgements section (Add acknowledgement button), both showing empty states." />
|
|
</Frame>
|
|
|
|
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. Not affected, false positive, and
|
|
fixed clear residual Crit/High for Secure. Accepted and ignored residual risk stay on Monitoring and
|
|
do not turn the page green. Needs review and affected stay actionable. You can
|
|
export the fleet's triage decisions as an OpenVEX document for use with other tooling.
|
|
|
|
## History
|
|
|
|
<Frame>
|
|
<img src="/images/security/history.png" alt="Security page History tab listing completed scans with a short digest as the primary label and image reference as the subtitle, plus Last scanned, Trigger, Severity, Findings, Fixable, and Action columns, a search box, and a Compare (0/2) button." />
|
|
</Frame>
|
|
|
|
The History tab lists completed scans for the active node in an inline table. Prefer digest identity
|
|
when a digest is stored (short digest as the primary label, image reference as the subtitle); config
|
|
and other scans without a digest show the image reference. Search matches image references or
|
|
digests. Select two scans to compare. The **Scan history** button in the
|
|
[Resources Hub](/features/resources) is a shortcut to the same place. For how tags and digests relate,
|
|
see [Tags vs digests](/features/vulnerability-scanning#tags-vs-digests).
|
|
|
|
## Scanner setup
|
|
|
|
<Frame>
|
|
<img src="/images/security/scanner-setup.png" alt="Security page Scanner setup tab showing an Installed (managed) Vulnerability Scanner card at version v0.72.0 with an Uninstall link, and three toggles: Auto-update Trivy (on), Pre-deploy scan advisory (off), and Exploit intelligence KEV plus EPSS (on)." />
|
|
</Frame>
|
|
|
|
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.
|
|
|
|
A third, admin-only toggle, off by default, enables the **pre-deploy scan advisory**: an opt-in review
|
|
step that shows each image's latest scan severity before a manual deploy runs from the editor. It is
|
|
visibility only and never blocks a deploy on its own; see
|
|
[Pre-deploy scan advisory](/features/vulnerability-scanning#pre-deploy-scan-advisory) for how it
|
|
behaves and how it differs from a blocking policy on the Policies tab.
|
|
|
|
## On a phone
|
|
|
|
<Frame>
|
|
<img src="/images/security/mobile.png" alt="Mobile Security page with a masthead-led SECURITY kicker, an Action needed state word, a horizontally scrollable tab strip, a full-width Scan this node button, CRITICAL/HIGH/LAST SCAN tiles, and the Why Action needed review queue." />
|
|
</Frame>
|
|
|
|
Security uses the bespoke mobile masthead pattern: no top bar, a scrollable tab strip mirroring the
|
|
desktop tab order, and the same panels underneath. The scanner-detections note moves into the
|
|
masthead's info affordance, and the node-scan launcher becomes a full-width button at the top of the
|
|
Overview panel.
|
|
|
|
## 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).
|