---
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, 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
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.
## Compose risks
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
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: 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
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
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
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
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).