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