mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 11:49:16 +00:00
feat: add dedicated Security page and policy-pack foundation (#1362)
* feat: add dedicated Security page and policy-pack foundation Bring vulnerability scanning, scan history, suppressions, Compose risks, secrets, policy packs, and scanner setup into one node-scoped Security command center instead of scattering them across Resources and Settings. - New top-level Security view with Overview, Images, Compose risks, Secrets, Policies, Suppressions, History, and Scanner setup tabs (status masthead + signal rail; controlled tabs with deep-link support). - Backend: GET /security/overview rollup and GET /security/policy-packs static catalog (auth-only, Community). DatabaseService gains an uncapped scan-status count and a node-eligible block-policy count, and getImageScanSummaries now projects secret and misconfig counts. - Reuse existing surfaces: the scan-history sheet, the control-governed suppression and acknowledgement panels, and the scan-detail sheet (now with an initial-tab prop so it opens on the matching finding type). - Extract a shared SeverityBadge (from Resources) and a TrivyManager (from Settings) so both surfaces render identical controls. - Resources "Scan history" now links into the Security page History tab. - Docs for the new Security surface and tests for the new endpoints, helpers, nav wiring, and tabs. * refactor: consolidate scanner and policy management onto the Security page Remove the Settings "Vulnerability Scanning" section now that the Security page covers the same ground, with every option preserved: - Scanner install / update / uninstall / auto-update live on the Scanner setup tab (TrivyManager). - Scan policies, the honor-suppressions toggle, and the replica managed-by-control / demote controls move into a new ScanPolicyManager on the Policies tab (paid; Community sees only the policy-pack catalog). - CVE suppressions and acknowledgements remain on the Suppressions tab. Wiring removed: the registry section and the now-empty Security settings group, the SectionId, the SettingsSectionContent case and the isPaid prop it was the sole consumer of, and SecuritySection itself. The dashboard configuration-status "Vulnerability scanning" row now navigates to the Security page Policies tab. Docs that pointed at "Settings -> Security -> Vulnerability Scanning" are swept to the relevant Security page tabs. * fix: harden Security page scanner refresh, policy-load errors, and secret-only badges Address independent-review findings on the Security page: - Scanner setup now refreshes Trivy state when the active node changes, so the displayed scanner status matches the node TrivyManager's actions target (both follow x-node-id). Previously, switching nodes on the tab left stale state. - ScanPolicyManager surfaces an explicit error state on a failed policy fetch instead of falling through to a false "No scan policies configured". - The shared SeverityBadge and the Images findings column no longer label a scan "clean" when it has secrets or misconfigurations but no CVE severity (highest_severity is derived from vulnerabilities only); they show a "Findings" state and the secret/misconfig counts instead. - The Overview enforcement note points to the Policies tab, not the removed Settings section. - The History tab auto-opens the scan-history sheet only on a deep-link (mount with the History tab active), not on every manual tab selection. Adds tests for the badge secret/misconfig state and the policy-load error state.
This commit is contained in:
Anso
@@ -173,6 +173,7 @@
|
||||
"features/rbac",
|
||||
"features/sso",
|
||||
"features/api-tokens",
|
||||
"features/security",
|
||||
"features/vulnerability-scanning",
|
||||
"features/cve-suppressions",
|
||||
"features/private-registries"
|
||||
|
||||
@@ -313,7 +313,7 @@ A future Volume Migration feature will automate this with app-aware backup tooli
|
||||
The reconciler will not auto-deploy a stateful blueprint to a node it has never run on. Click **Confirm deploy** on the row, then choose **Deploy fresh** in the dialog. Sencho will create empty named volumes and start the stack.
|
||||
</Accordion>
|
||||
<Accordion title="A deploy was blocked by vulnerability policy">
|
||||
Open **Settings · Security · Vulnerability Scanning** and review the active scan policies for the target node. The Blueprint deployment row records the blocking policy and affected image count. Either fix the image, relax the policy, or deploy through an explicit admin-approved bypass on the stack surface. Blueprints do not silently bypass deploy enforcement.
|
||||
Open the **Security** page and review the active scan policies for the target node on the **Policies** tab. The Blueprint deployment row records the blocking policy and affected image count. Either fix the image, relax the policy, or deploy through an explicit admin-approved bypass on the stack surface. Blueprints do not silently bypass deploy enforcement.
|
||||
</Accordion>
|
||||
<Accordion title="Compose content was rejected on save">
|
||||
Sencho accepts valid YAML up to 96 KiB. Split very large compose files into smaller blueprints or move generated content out of the Blueprint. Do not paste secrets into the compose body; use environment files or [Fleet Secrets](/features/fleet-secrets) where appropriate.
|
||||
|
||||
@@ -19,12 +19,12 @@ A suppression is a rule that says "this CVE is acknowledged." When a scan's find
|
||||
|
||||
Badge counts in the Resources Hub continue to reflect the raw findings. Suppressions are a visual filter, not an accounting change. Remove a suppression and the underlying finding resurfaces on the next read, without rescanning.
|
||||
|
||||
## Creating a suppression from Settings
|
||||
## Creating a suppression
|
||||
|
||||
Open **Settings → Security → Vulnerability Scanning** and scroll to **CVE Suppressions**, then click **Add Suppression**.
|
||||
Open the **Security** page → **Suppressions** tab, then click **Add Suppression**.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/cve-suppressions/settings-panel.png" alt="Settings Security page with the CVE Suppressions panel listing two accepted CVEs, each showing the CVE ID, an outlined package badge, a clamped reason line, the author and expiry metadata, and a trash icon for removal" />
|
||||
<img src="/images/cve-suppressions/settings-panel.png" alt="Security page Suppressions tab with the CVE Suppressions panel listing two accepted CVEs, each showing the CVE ID, an outlined package badge, a clamped reason line, the author and expiry metadata, and a trash icon for removal" />
|
||||
</Frame>
|
||||
|
||||
The dialog has the following fields:
|
||||
@@ -43,7 +43,7 @@ The dialog has the following fields:
|
||||
|
||||
### Suppressing directly from a scan result
|
||||
|
||||
The panel's empty state hints at the faster path: from any vulnerability scan, click the small shield icon at the right edge of a finding's row. The dialog opens pre-filled with the CVE ID and the package name from that row (both read-only in this flow), leaving you to add a Reason, an optional Image pattern, and an optional Expiry. This is the recommended workflow for everyday triage, because it keeps the scope as narrow as the originating finding. To broaden the scope (for example, to suppress across every package), create the rule from **Settings → Security → Vulnerability Scanning** instead.
|
||||
The panel's empty state hints at the faster path: from any vulnerability scan, click the small shield icon at the right edge of a finding's row. The dialog opens pre-filled with the CVE ID and the package name from that row (both read-only in this flow), leaving you to add a Reason, an optional Image pattern, and an optional Expiry. This is the recommended workflow for everyday triage, because it keeps the scope as narrow as the originating finding. To broaden the scope (for example, to suppress across every package), create the rule from the **Security** page → **Suppressions** tab instead.
|
||||
|
||||
### How specificity is resolved
|
||||
|
||||
@@ -71,7 +71,7 @@ The same dim-and-icon treatment carries through to the **Compare** sheet, so a C
|
||||
Suppressions are managed on the **control** Sencho instance and replicate automatically to every remote you've registered:
|
||||
|
||||
- Creating, editing, or removing a suppression on the control pushes the full list to every remote.
|
||||
- A Sencho instance that has received at least one push from a control is a **replica**. On a replica, **Settings → Security → Vulnerability Scanning** shows the suppression list read-only, and replicated rows carry a small `replicated` badge so they are easy to tell apart from any locally-created entries.
|
||||
- A Sencho instance that has received at least one push from a control is a **replica**. On a replica, the **Security** page → **Suppressions** tab shows the suppression list read-only, and replicated rows carry a small `replicated` badge so they are easy to tell apart from any locally-created entries.
|
||||
- When you're signed into a control and have a **remote node selected** from the node switcher, the CVE Suppressions panel itself is hidden and a "Scanner is per-node" banner explains that scanning runs on the remote while rules live on the control.
|
||||
|
||||
The full replication, retry, and reanchor flow (including the API call to re-bind a replica to a new control) is documented in [Fleet Sync](/features/fleet-sync).
|
||||
@@ -80,7 +80,7 @@ The full replication, retry, and reanchor flow (including the API call to re-bin
|
||||
|
||||
By default, suppressions do not affect [block-on-deploy policies](/features/vulnerability-scanning#honoring-suppressions-in-deploy-blocks). A policy evaluates the raw scan result, so a CVE you have suppressed still blocks a deploy that violates the threshold. Suppressions silence the noise; the gate stays strict.
|
||||
|
||||
To have an accepted CVE stop counting toward the gate, an admin can enable **Honor suppressions in deploy blocks** in **Settings → Security → Vulnerability Scanning**. With it on, a block-on-deploy policy re-derives each image's severity from the findings that remain after suppressions are applied, so a deploy whose only blocking findings are all suppressed proceeds without a manual bypass. Sencho records each such suppression-driven pass in the audit log.
|
||||
To have an accepted CVE stop counting toward the gate, an admin can enable **Honor suppressions in deploy blocks** on the **Security** page → **Policies** tab. With it on, a block-on-deploy policy re-derives each image's severity from the findings that remain after suppressions are applied, so a deploy whose only blocking findings are all suppressed proceeds without a manual bypass. Sencho records each such suppression-driven pass in the audit log.
|
||||
|
||||
The toggle is off by default and is set per Sencho instance, because the gate runs on whichever instance performs the deploy.
|
||||
|
||||
@@ -101,7 +101,7 @@ Suppressed findings carry through to the [SARIF export](/features/vulnerability-
|
||||
Badge counts reflect the raw findings so they remain meaningful for alerting. Suppressions apply when results are read for display (the scan drawer, the Compare sheet, the SARIF export), not when they are stored. Open the scan drawer to confirm the row is dimmed with a shield-off icon.
|
||||
</Accordion>
|
||||
<Accordion title="A suppressed CVE still blocks my deploy">
|
||||
Block-on-deploy policies evaluate the raw scan result by default, so a suppressed CVE still counts toward the block. If you want accepted CVEs to stop counting, enable **Honor suppressions in deploy blocks** in **Settings → Security → Vulnerability Scanning** on the instance that runs the deploy. See [Suppressions and deploy blocking](#suppressions-and-deploy-blocking) for the full behavior.
|
||||
Block-on-deploy policies evaluate the raw scan result by default, so a suppressed CVE still counts toward the block. If you want accepted CVEs to stop counting, enable **Honor suppressions in deploy blocks** on the **Security** page → **Policies** tab on the instance that runs the deploy. See [Suppressions and deploy blocking](#suppressions-and-deploy-blocking) for the full behavior.
|
||||
</Accordion>
|
||||
<Accordion title="A suppression I added on the control is not visible on a replica">
|
||||
Replication runs on every write. If the push failed (network blip, replica restart), the control retries every 5 minutes for 24 hours and the replica picks up the latest state on the next successful push. See [Fleet Sync](/features/fleet-sync) for how to investigate persistent push failures.
|
||||
|
||||
@@ -11,7 +11,7 @@ Deploy enforcement is the pre-flight half of Sencho's vulnerability workflow. Wh
|
||||
|
||||
## Configuring a block policy
|
||||
|
||||
Policies are managed under **Settings → Security → Vulnerability Scanning → Scan Policies**. The **Add policy** button opens the editor; existing policies appear as a list of cards with `max: <SEVERITY>` and `block` badges, the configured stack-pattern scope, and pencil and trash buttons.
|
||||
Policies are managed on the **Security** page → **Policies** tab. The **Add policy** button opens the editor; existing policies appear as a list of cards with `max: <SEVERITY>` and `block` badges, the configured stack-pattern scope, and pencil and trash buttons.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/deploy-enforcement/policy-list.png" alt="Scan Policies card showing a configured policy with the name 'Production block on critical', a max: CRITICAL badge, a block badge, and the Scope demo-blocked-* set as the stack pattern" />
|
||||
@@ -112,7 +112,7 @@ Neither drift mechanism blocks, stops, or quarantines a running stack automatica
|
||||
<Accordion title="The gate let a deploy through even though I have a block policy">
|
||||
Check the following in order:
|
||||
|
||||
1. Open **Settings → Security → Vulnerability Scanning** on the target node and confirm Trivy is installed. Sencho fails open when Trivy is missing, dispatching a warning alert instead of blocking. [Install Trivy](/operations/trivy-setup) to enforce the policy.
|
||||
1. Open the **Security** page → **Scanner setup** tab on the target node and confirm Trivy is installed. Sencho fails open when Trivy is missing, dispatching a warning alert instead of blocking. [Install Trivy](/operations/trivy-setup) to enforce the policy.
|
||||
2. Confirm the policy is enabled and the stack pattern matches the stack name. `prod-*` matches `prod-api` but not `production-api`. An empty pattern matches every stack on the node.
|
||||
3. Check the highest severity in the latest scan for each image. If no image reached the threshold, the gate correctly allowed the deploy.
|
||||
</Accordion>
|
||||
|
||||
@@ -11,20 +11,20 @@ Fleet Sync replicates three resources today, all over the same channel and with
|
||||
- **CVE suppressions** ([CVE Suppressions](/features/cve-suppressions)).
|
||||
- **Misconfig acknowledgements**.
|
||||
|
||||
Fleet Sync lives under **Settings → Security → Vulnerability Scanning** on both the control (where you author rules) and the replica (where you see them, read-only).
|
||||
Fleet Sync lives on the **Security** page (the **Policies** and **Suppressions** tabs) on both the control (where you author rules) and the replica (where you see them, read-only).
|
||||
|
||||
<Frame>
|
||||
<img src="/images/fleet-sync/control-security.png" alt="Settings → Security → Vulnerability Scanning on the control. The Vulnerability Scanner card shows Trivy installed with Auto-update Trivy turned on. Below it, the empty 'No scan policies configured' state and the CVE Suppressions section listing two active suppressions against github.com/docker/docker, each annotated 'by admin · expires Never'." />
|
||||
<img src="/images/fleet-sync/control-security.png" alt="The Security page on the control. The Scanner setup tab shows Trivy installed with Auto-update Trivy turned on. The Policies tab shows the empty 'No scan policies configured' state, and the Suppressions tab lists two active suppressions against github.com/docker/docker, each annotated 'by admin · expires Never'." />
|
||||
</Frame>
|
||||
|
||||
## Control and replica roles
|
||||
|
||||
Every Sencho instance carries a `fleet_role` flag that is either `control` or `replica`. The flag is consulted on every write path for the replicated resources and by the **Settings → Security → Vulnerability Scanning** UI when it decides whether to render the edit controls.
|
||||
Every Sencho instance carries a `fleet_role` flag that is either `control` or `replica`. The flag is consulted on every write path for the replicated resources and by the **Security** page UI when it decides whether to render the edit controls.
|
||||
|
||||
| Role | Behaviour |
|
||||
|---|---|
|
||||
| **Control** | The default for any fresh install and for the instance whose **Settings → Nodes** lists the rest of the fleet. Accepts create, edit, and delete on scan policies, CVE suppressions, and misconfig acknowledgements. Pushes the full current state of each resource to every reachable remote on every write. |
|
||||
| **Replica** | An instance that has received at least one Fleet Sync push. Renders replicated rules as read-only with a "Managed by control node" banner above the policy editor on **Settings → Security → Vulnerability Scanning**. Returns `403 Forbidden` for any direct write attempt against the replicated tables. |
|
||||
| **Replica** | An instance that has received at least one Fleet Sync push. Renders replicated rules as read-only with a "Managed by control node" banner above the policy editor on the **Security** page → **Policies** tab. Returns `403 Forbidden` for any direct write attempt against the replicated tables. |
|
||||
|
||||
The transition from control to replica happens automatically the first time a replica accepts a push: the apply transaction sets `fleet_role = 'replica'` atomically with the row replacement, so the role flip and the new rows land together or not at all. Going the other way is explicit: an admin clicks **Demote to control** on the replica (see [Demote a replica](#demote-a-replica) below).
|
||||
|
||||
@@ -38,7 +38,7 @@ What does *not* replicate:
|
||||
- **Trivy itself.** The scanner binary is installed independently on each instance. The Security panel on a remote shows a "Scanner is per-node" callout in place of the full editor, since the scanner lifecycle is a node concern, not a fleet concern.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/fleet-sync/remote-security-via-proxy.png" alt="Settings → Security → Vulnerability Scanning on a remote, opened via the control's node switcher. The Vulnerability Scanner card shows 'Not installed' with an Install Trivy button; below it, a 'Scanner is per-node' status callout reads 'Trivy is installed independently on each Sencho instance. Scan policies and CVE suppressions are managed on the control node.'" />
|
||||
<img src="/images/fleet-sync/remote-security-via-proxy.png" alt="The Security page Scanner setup tab on a remote, opened via the control's node switcher. The Vulnerability Scanner card shows 'Not installed' with an Install Trivy button; below it, a 'Scanner is per-node' status callout reads 'Trivy is installed independently on each Sencho instance. Scan policies and CVE suppressions are managed on the control node.'" />
|
||||
</Frame>
|
||||
- **Everything outside the three resources above.** API tokens, audit logs, blueprints, secrets, alert rules, users, SSO config, and general settings stay per-instance.
|
||||
- **Pilot-agent nodes.** Sync over the [pilot tunnel](/features/pilot-agent) is not part of v1; the control logs a one-time warning per pilot node and skips it during fanout. The pilot node's local rules are unaffected.
|
||||
@@ -95,7 +95,7 @@ Stale pushes (`409 STALE_SYNC_PUSH`) are not counted as failures, since a newer
|
||||
|
||||
## Demote a replica
|
||||
|
||||
An admin on a replica can take the instance back to a standalone control from **Settings → Security → Vulnerability Scanning**. The button is "Demote to control" and sits inside the "Managed by control node" callout. The exact modal copy:
|
||||
An admin on a replica can take the instance back to a standalone control from the **Security** page → **Policies** tab. The button is "Demote to control" and sits inside the "Managed by control node" callout. The exact modal copy:
|
||||
|
||||
> **Demote replica to control**
|
||||
>
|
||||
@@ -159,7 +159,7 @@ Fleet Sync v1 ships the three replicated resources and the control mechanics des
|
||||
Misconfig acknowledgements ride the same channel as scan policies and CVE suppressions; if one resource replicates and another does not, it is almost always a per-resource watermark race. Re-save the acknowledgement on the control to produce a fresh `pushedAt`, then the next push catches the remote up. If the symptom persists, check the control's server logs for the `[FleetSync]` push outcome on that remote.
|
||||
</Accordion>
|
||||
<Accordion title="I want this replica to be a standalone control again">
|
||||
Open **Settings → Security → Vulnerability Scanning** on the replica and click **Demote to control** in the "Managed by control node" callout. The action requires confirmation and drops every replicated row from this instance. Local rules authored directly on this instance are kept. The control loses this remote as a replica; remove it from the control's **Settings → Nodes** as well if you no longer want the control to push to it.
|
||||
Open the **Security** page → **Policies** tab on the replica and click **Demote to control** in the "Managed by control node" callout. The action requires confirmation and drops every replicated row from this instance. Local rules authored directly on this instance are kept. The control loses this remote as a replica; remove it from the control's **Settings → Nodes** as well if you no longer want the control to push to it.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
|
||||
@@ -159,7 +159,7 @@ Generate scoped API tokens for CI/CD pipelines, scripts, and automation workflow
|
||||
|
||||
### Vulnerability scanning
|
||||
|
||||
Scan container images for known CVEs with [Trivy](https://trivy.dev). Install Trivy with one click from Settings → Security → Vulnerability Scanning on first use; the [setup guide](/operations/trivy-setup) covers bind-mounted and air-gapped alternatives. Manual scanning, secret and misconfiguration detection, scan comparison, scheduled scans, CVE suppressions, single-scan SBOM export, and auto-update of the managed Trivy binary are available on every tier; scan policies that gate deploys and SARIF export are Admiral. [Learn more →](/features/vulnerability-scanning)
|
||||
Scan container images for known CVEs with [Trivy](https://trivy.dev). Install Trivy with one click from the Security page Scanner setup tab on first use; the [setup guide](/operations/trivy-setup) covers bind-mounted and air-gapped alternatives. Manual scanning, secret and misconfiguration detection, scan comparison, scheduled scans, CVE suppressions, single-scan SBOM export, and auto-update of the managed Trivy binary are available on every tier; scan policies that gate deploys and SARIF export are Admiral. [Learn more →](/features/vulnerability-scanning)
|
||||
|
||||
### CVE suppressions
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ A confirmation dialog appears before any destructive operation, with a summary o
|
||||
|
||||
Below the hero, four tabs partition your inventory: **images**, **volumes**, **networks**, and **Unmanaged**. The Unmanaged tab shows a count badge whenever orphan containers are detected.
|
||||
|
||||
A **Scan history** button sits on the right of the tab strip when image vulnerability scanning is configured for the node. It opens the full scan record so you can review past results without launching a new scan. See [Vulnerability scanning](/features/vulnerability-scanning) for the full workflow.
|
||||
A **Scan history** button sits on the right of the tab strip when image vulnerability scanning is configured for the node. It takes you to the [Security page](/features/security) History tab so you can review past results without launching a new scan. See [Vulnerability scanning](/features/vulnerability-scanning) for the full workflow.
|
||||
|
||||
<Note>
|
||||
Sencho protects its own image, network, and named volumes from accidental deletion. The matching rows carry a **Sencho** pill alongside the managed status and the delete control is disabled.
|
||||
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
title: "Security"
|
||||
description: "The command center for your fleet's security posture: an overview dashboard, image and Compose findings, secrets, scan history, suppressions, policy packs, 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 worst active severity at a glance,
|
||||
**Secure**, **At risk**, or **Critical**, alongside the critical and high counts and the time of the
|
||||
last successful scan. Below it, a signal rail summarizes the supporting numbers: scanned images,
|
||||
fixable findings, secrets, Compose misconfigurations, stale scans, and failed scans. A status strip
|
||||
shows scanner health (installed source and version, auto-update) 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, suppress a CVE, and export an
|
||||
SBOM.
|
||||
|
||||
## Compose risks
|
||||
|
||||
Compose risks surface misconfigurations in your stack definitions rather than image CVEs: privileged
|
||||
containers, Docker socket mounts, host networking, broad host bind mounts, missing healthchecks, public
|
||||
database ports, containers running as root, unpinned image tags, and missing restart policies. Each
|
||||
entry opens its scan report with the specific findings and how to fix them. The [Policy packs](#policy-packs)
|
||||
tab explains each category in depth.
|
||||
|
||||
## Secrets
|
||||
|
||||
The secrets tab lists images where Trivy detected exposed credentials or keys, and opens straight to
|
||||
the secret findings for a scan.
|
||||
|
||||
## Policy packs
|
||||
|
||||
Policy packs are curated bundles of security expectations for a deployment posture. Sencho ships five
|
||||
defaults:
|
||||
|
||||
- **Homelab baseline**: gentle defaults for a single-operator homelab.
|
||||
- **Production hardening**: sensible hardening for services that face real traffic.
|
||||
- **Strict production**: a zero-tolerance posture for critical workloads.
|
||||
- **Public edge service**: focused on services exposed to the public internet.
|
||||
- **Internal service**: least-privilege defaults for east-west internal services.
|
||||
|
||||
Each pack lists its rules with the severity, what the rule checks, why it matters, and how to fix it.
|
||||
Every rule is marked **warning** or **enforceable**. In Community, packs are advisory: they explain
|
||||
what good looks like. Block-on-deploy enforcement is an Admiral capability, configured under
|
||||
[scan policies](/features/vulnerability-scanning#scan-policies).
|
||||
|
||||
## 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.
|
||||
|
||||
## 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.
|
||||
|
||||
## 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).
|
||||
@@ -3,7 +3,7 @@ title: "Vulnerability Scanning"
|
||||
description: "Scan container images and stack compose files for CVEs, secrets, and misconfigurations. Surface severity badges in the Resources Hub, compare scans over time, and gate deploys on policy violations."
|
||||
---
|
||||
|
||||
Sencho integrates with [Trivy](https://trivy.dev) to scan container images and Compose files for vulnerabilities (CVEs), hardcoded secrets, and misconfigurations. Findings surface as severity badges in the Resources Hub and as drillable reports in the scan drawer. Manual scanning, secret and misconfig detection, scan history, comparison, scheduled fleet scans, CVE suppressions, single-scan SBOM export, and managed Trivy auto-update are available on every tier. Admiral adds policy enforcement and SARIF export.
|
||||
Sencho integrates with [Trivy](https://trivy.dev) to scan container images and Compose files for vulnerabilities (CVEs), hardcoded secrets, and misconfigurations. Findings surface as severity badges in the Resources Hub and as drillable reports in the scan drawer. The dedicated [Security page](/features/security) is the command center for risk review: overview, image findings, Compose risks, secrets, scan history, suppressions, policy packs, and scanner setup all live there. Manual scanning, secret and misconfig detection, scan history, comparison, scheduled fleet scans, CVE suppressions, single-scan SBOM export, and managed Trivy auto-update are available on every tier. Admiral adds policy enforcement and SARIF export.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/vulnerability-scanning/resources-badges.png" alt="Resources Hub Images table with severity badges (CRITICAL, HIGH, MEDIUM) on managed image rows alongside the Scan history button" />
|
||||
@@ -14,7 +14,7 @@ Sencho integrates with [Trivy](https://trivy.dev) to scan container images and C
|
||||
The Trivy CLI must be available on the machine running Sencho. Trivy is not bundled with the Sencho Docker image; see [Installing Trivy](/operations/trivy-setup) for mount and installation options. Sencho checks for Trivy on startup and hides scanning UI when the binary is not available.
|
||||
|
||||
<Note>
|
||||
Trivy is installed independently on each Sencho instance. When you select a remote node, **Settings → Security → Vulnerability Scanning** shows only the scanner status for that node; install, update, or uninstall Trivy from there to manage the remote's binary. Scan policies, CVE suppressions, and misconfig acknowledgements are managed on the control instance and replicate fleet-wide.
|
||||
Trivy is installed independently on each Sencho instance. When you select a remote node, the **Security** page → **Scanner setup** tab shows only the scanner status for that node; install, update, or uninstall Trivy from there to manage the remote's binary. Scan policies, CVE suppressions, and misconfig acknowledgements are managed on the control instance and replicate fleet-wide.
|
||||
</Note>
|
||||
|
||||
## Tier availability
|
||||
@@ -144,12 +144,12 @@ Policies define severity thresholds that govern whether a stack can deploy. A po
|
||||
See [Deploy Enforcement](/features/deploy-enforcement) for the full pre-flight flow, admin bypass path, and audit-log behavior.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/vulnerability-scanning/security-settings.png" alt="Settings Security page showing the masthead with Node, Policies, and Trivy status, the Vulnerability Scanner card with Auto-update Trivy toggle, an Add Policy button, and the No scan policies configured empty state" />
|
||||
<img src="/images/vulnerability-scanning/security-settings.png" alt="The Security page Policies tab showing the policy-pack catalog, the Deploy enforcement policies section with an Add policy button, and the No scan policies configured empty state" />
|
||||
</Frame>
|
||||
|
||||
### Creating a policy
|
||||
|
||||
Go to **Settings → Security → Vulnerability Scanning** and click **Add Policy**.
|
||||
Go to the **Security** page → **Policies** tab and click **Add policy**.
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
@@ -195,7 +195,7 @@ Only one policy is evaluated per deploy. Use a single tight pattern rather than
|
||||
|
||||
By default a block-on-deploy policy evaluates the **raw** scan result, so a CVE you have accepted in [CVE Suppressions](/features/cve-suppressions) still counts toward the block. That keeps the gate strict: suppressions silence alerts and dim findings in reports, but on their own they do not open the deploy path.
|
||||
|
||||
To have an accepted CVE stop counting toward the gate, turn on **Honor suppressions in deploy blocks** in **Settings → Security → Vulnerability Scanning**. With it on, the gate re-derives each image's severity from the findings that remain after suppressions are applied, so an image whose only blocking findings are all suppressed deploys without a manual bypass. When a deploy proceeds for this reason, Sencho records it in the audit log so the suppression-driven pass stays traceable.
|
||||
To have an accepted CVE stop counting toward the gate, turn on **Honor suppressions in deploy blocks** on the **Security** page → **Policies** tab. With it on, the gate re-derives each image's severity from the findings that remain after suppressions are applied, so an image whose only blocking findings are all suppressed deploys without a manual bypass. When a deploy proceeds for this reason, Sencho records it in the audit log so the suppression-driven pass stays traceable.
|
||||
|
||||
The toggle governs the Sencho instance that runs the deploy and is off by default. Enable it on each instance whose deploys should honor suppressions.
|
||||
|
||||
@@ -272,7 +272,7 @@ Acknowledged rows render dimmed with a strikethrough title; hovering surfaces th
|
||||
|
||||
### Managing acknowledgements
|
||||
|
||||
**Settings → Security → Vulnerability Scanning** has a Misconfig Acknowledgements panel listing every acknowledgement on this control: rule id, optional stack pattern (glob), creator, expiry date, and a delete button. The same `replicated` badge that appears on CVE suppressions appears here for rows pushed from the control to a replica.
|
||||
The **Security** page → **Suppressions** tab has a Misconfig Acknowledgements panel listing every acknowledgement on this control: rule id, optional stack pattern (glob), creator, expiry date, and a delete button. The same `replicated` badge that appears on CVE suppressions appears here for rows pushed from the control to a replica.
|
||||
|
||||
Replicas show the panel read-only; write operations return 403 with a "managed by control" message so configuration drift cannot accumulate on the leaf nodes.
|
||||
|
||||
@@ -336,7 +336,7 @@ Typical upload flow for GitHub code scanning:
|
||||
|
||||
Every scan Sencho runs is stored with its full vulnerability detail. Scan records are pruned automatically after 90 days to keep the database compact. The history powers two things: digest caching (skip re-scanning a digest already scanned within 24 hours) and trend insight (compare a new scan to its predecessor to see what changed).
|
||||
|
||||
Click **Scan history** from the top of the Resources Hub to open the scan history sheet over the current page. The sheet lists completed scans grouped by image, lets you search by image reference, and lets you tick two scans to compare. Close the sheet with Escape, by clicking the overlay, or by clicking the close button in the header.
|
||||
Open the **Security** page and select the **History** tab, then choose **Open scan history**, to browse completed scans. The sheet lists completed scans grouped by image, lets you search by image reference, and lets you tick two scans to compare. Close the sheet with Escape, by clicking the overlay, or by clicking the close button in the header; the History tab stays open behind it. The **Scan history** button at the top of the Resources Hub is a shortcut to the same place.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/vulnerability-scanning/scan-history-sheet.png" alt="Scan history sheet over the Resources Hub showing 361 scans across 29 images, the Compare primary action enabled with two scans ticked, a search box, pagination, and scans grouped by image reference" />
|
||||
@@ -378,7 +378,7 @@ Up to 1000 findings per scan are loaded for comparison. When a scan exceeds this
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Scan button is not visible">
|
||||
Sencho hides scanning UI when the Trivy binary is not detected. Check **Settings → Security → Vulnerability Scanning** for the scanner status, then follow [Installing Trivy](/operations/trivy-setup) if it is missing.
|
||||
Sencho hides scanning UI when the Trivy binary is not detected. Check the **Security** page → **Scanner setup** tab for the scanner status, then follow [Installing Trivy](/operations/trivy-setup) if it is missing.
|
||||
</Accordion>
|
||||
<Accordion title="Scans time out">
|
||||
The default scan timeout is 5 minutes. Very large images (2 GB or more) over a slow connection may exceed this; pre-pulling the image to the host speeds up the scan significantly because Trivy then works against the local image store.
|
||||
@@ -402,10 +402,10 @@ Up to 1000 findings per scan are loaded for comparison. When a scan exceeds this
|
||||
When a post-deploy scan fails for a specific image (for example because Trivy could not resolve a private registry pull), Sencho dispatches a warning-level alert through your configured notification channels. The deploy itself is never blocked by a scan failure.
|
||||
</Accordion>
|
||||
<Accordion title="A deploy was blocked by a policy I did not expect">
|
||||
The block dialog names the policy that fired and lists every image that violated the threshold. Open **Settings → Security → Vulnerability Scanning** and review the matching policy: check the stack pattern glob and the max severity. If the policy should not apply, tighten the pattern (for example `staging-*` instead of `*`) or turn **Block on deploy** off to keep the evaluation in alert-only mode. Admins can bypass a single deploy with the **Deploy anyway** button; every bypass is recorded in the [Audit Log](/features/audit-log) with the actor, policy, and violation list.
|
||||
The block dialog names the policy that fired and lists every image that violated the threshold. Open the **Security** page → **Policies** tab and review the matching policy: check the stack pattern glob and the max severity. If the policy should not apply, tighten the pattern (for example `staging-*` instead of `*`) or turn **Block on deploy** off to keep the evaluation in alert-only mode. Admins can bypass a single deploy with the **Deploy anyway** button; every bypass is recorded in the [Audit Log](/features/audit-log) with the actor, policy, and violation list.
|
||||
</Accordion>
|
||||
<Accordion title="Trivy is not installed and a deploy with a block policy went through">
|
||||
Sencho fails open when Trivy is not installed on the target node, so operators are never locked out by tooling state. A warning alert is dispatched through your configured notification channels with the message `Pre-deploy scan for "<stack>" skipped: Trivy not installed on this node`. Install Trivy from **Settings → Security → Vulnerability Scanning** to enforce the policy; see [Installing Trivy](/operations/trivy-setup) for options.
|
||||
Sencho fails open when Trivy is not installed on the target node, so operators are never locked out by tooling state. A warning alert is dispatched through your configured notification channels with the message `Pre-deploy scan for "<stack>" skipped: Trivy not installed on this node`. Install Trivy from the **Security** page → **Scanner setup** tab to enforce the policy; see [Installing Trivy](/operations/trivy-setup) for options.
|
||||
</Accordion>
|
||||
<Accordion title="Compare button is disabled in the scan history sheet">
|
||||
The Compare primary action enables only after exactly two scans are ticked. Selecting zero, one, or three scans leaves it disabled. If you have only one scan for an image, trigger a second scan from the Resources Hub (or wait for a scheduled scan), then return to Scan history and tick both.
|
||||
@@ -420,10 +420,10 @@ Up to 1000 findings per scan are loaded for comparison. When a scan exceeds this
|
||||
The Scan history sheet uses server-driven pagination. If you know the scan exists but cannot see it, use the search box to filter by image reference, or page forward with the arrows in the card header. Scans older than 90 days are pruned automatically to keep the database compact.
|
||||
</Accordion>
|
||||
<Accordion title="Scan policies are missing on one of my nodes">
|
||||
Scan policies are managed from the control Sencho instance and replicate to every remote. On a replica, **Settings → Security → Vulnerability Scanning** shows a banner explaining that rules are managed upstream. See [Fleet Sync](/features/fleet-sync) for how replication works and how to investigate push failures.
|
||||
Scan policies are managed from the control Sencho instance and replicate to every remote. On a replica, the **Security** page → **Policies** tab shows a banner explaining that rules are managed upstream. See [Fleet Sync](/features/fleet-sync) for how replication works and how to investigate push failures.
|
||||
</Accordion>
|
||||
<Accordion title="I suppressed a CVE but the scan badge count is unchanged">
|
||||
Badge counts always reflect raw findings so alerting stays accurate. Policy evaluation also uses raw findings by default; if you want suppressed CVEs to stop counting toward block-on-deploy policies, enable **Honor suppressions in deploy blocks** in **Settings → Security → Vulnerability Scanning**. Open the scan drawer to confirm the row is dimmed with a shield-off icon. See [CVE Suppressions](/features/cve-suppressions) for how the filter is applied across the drawer, compare sheet, and other read surfaces.
|
||||
Badge counts always reflect raw findings so alerting stays accurate. Policy evaluation also uses raw findings by default; if you want suppressed CVEs to stop counting toward block-on-deploy policies, enable **Honor suppressions in deploy blocks** on the **Security** page → **Policies** tab. Open the scan drawer to confirm the row is dimmed with a shield-off icon. See [CVE Suppressions](/features/cve-suppressions) for how the filter is applied across the drawer, compare sheet, and other read surfaces.
|
||||
</Accordion>
|
||||
<Accordion title="The Secrets tab is empty on an image I expect to contain credentials">
|
||||
Secret detection matches against Trivy's built-in rule set, which focuses on well-known provider patterns. Plain text passwords, custom token formats, or values that do not match any published rule will not appear. Make sure you picked **Full scan (vulnerabilities + secrets)** from the shield-icon menu; a plain vulnerability scan does not walk the filesystem.
|
||||
|
||||
@@ -5,7 +5,7 @@ description: Install and mount the Trivy CLI so Sencho can scan container images
|
||||
|
||||
Sencho's [Vulnerability Scanning](/features/vulnerability-scanning) feature uses the [Trivy](https://trivy.dev) CLI. Trivy is not bundled with the Sencho Docker image. You have three ways to provide it, in order of convenience:
|
||||
|
||||
1. **One-click install from Settings → Security → Vulnerability Scanning** (recommended).
|
||||
1. **One-click install from the [Security page](/features/security) → Scanner setup tab** (recommended). Install, update, uninstall, and auto-update all live there.
|
||||
2. Bind mount a host Trivy binary into the container.
|
||||
3. Build a custom Sencho image with Trivy baked in.
|
||||
|
||||
@@ -23,12 +23,12 @@ Trivy's vulnerability database updates multiple times per day and is around 100
|
||||
|
||||
Sencho can install and manage Trivy for you without any extra bind mounts or environment variables.
|
||||
|
||||
1. Go to **Settings → Security → Vulnerability Scanning**.
|
||||
1. Open the **Security** page and select the **Scanner setup** tab.
|
||||
2. Under **Vulnerability Scanner**, click **Install Trivy**.
|
||||
3. Wait for the status to flip to **Installed (managed)**. The version appears next to the badge.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/vulnerability-scanning/trivy-settings-card.png" alt="Vulnerability Scanner card in Settings, Security section, with Install Trivy button" />
|
||||
<img src="/images/vulnerability-scanning/trivy-settings-card.png" alt="Vulnerability Scanner card on the Security page Scanner setup tab, with Install Trivy button" />
|
||||
</Frame>
|
||||
|
||||
Behind the scenes:
|
||||
@@ -40,7 +40,7 @@ Behind the scenes:
|
||||
|
||||
### Updating the managed install
|
||||
|
||||
When a newer Trivy release is available, Settings → Security → Vulnerability Scanning shows an **Update available** badge next to the version. Click **Update** to pull the latest release.
|
||||
When a newer Trivy release is available, the Security page Scanner setup tab shows an **Update available** badge next to the version. Click **Update** to pull the latest release.
|
||||
|
||||
To update automatically instead, toggle **Auto-update Trivy** on. Sencho checks for new releases once a day and installs them in the background. You'll get an in-app notification each time a new version is installed, or when an update is available and auto-update is off.
|
||||
|
||||
@@ -181,7 +181,7 @@ Plan to refresh the bundle on a schedule (weekly is typical) so CVE data stays c
|
||||
|
||||
## Verifying Sencho detects Trivy
|
||||
|
||||
1. Open **Settings → Security → Vulnerability Scanning**. The **Vulnerability Scanner** card shows the current status and version.
|
||||
1. Open the **Security** page → **Scanner setup** tab. The **Vulnerability Scanner** card shows the current status and version.
|
||||
2. Open the **Resources** tab. If Trivy is detected, a shield icon appears in the Actions column of the **Images** panel next to the delete icon on every row.
|
||||
|
||||
If the scanner shows as not installed after using Option 2 or 3, see the troubleshooting section below.
|
||||
|
||||
@@ -20,11 +20,12 @@ Open the Settings Hub by clicking the **Profile** icon in the top bar and select
|
||||
| **Notifications** | Channels, Notification Routing |
|
||||
| **Automation** | Webhooks |
|
||||
| **Organization** | Labels |
|
||||
| **Security** | Vulnerability Scanning |
|
||||
| **Operations** | Data Retention, Developer Diagnostics, Recovery |
|
||||
| **Help** | Support, About |
|
||||
|
||||
Sections that require a higher license tier stay hidden until the operator has the matching license. Admin-only sections (Users, SSO, API Tokens, Fleet Mesh, Registries, Cloud Backup, Notification Routing, Vulnerability Scanning) stay hidden for non-admin operators.
|
||||
Vulnerability scanning is no longer a Settings section: scanner setup, scan policies, suppressions, and acknowledgements now live on the dedicated [Security page](/features/security).
|
||||
|
||||
Sections that require a higher license tier stay hidden until the operator has the matching license. Admin-only sections (Users, SSO, API Tokens, Fleet Mesh, Registries, Cloud Backup, Notification Routing) stay hidden for non-admin operators.
|
||||
|
||||
### Page chrome
|
||||
|
||||
@@ -35,11 +36,11 @@ Every section renders inside the same masthead-and-sidebar layout. The masthead
|
||||
| **SCOPE** `operator` / `global` | Setting applies to your account or this browser (Personal sections) or to the whole instance (every other non-node group) |
|
||||
| **NODE** `<node name>` | Setting is per-node and is currently being edited against this node |
|
||||
| **EDITED** `<count>` pending / `saved` | The current section has unsaved changes |
|
||||
| Section-specific stats | Each section can publish its own pills: `2FA on`/`off` and `BACKUP <n> left` (Account); `PLAN`, `TRIAL <n>d left`, `RENEWS`, `STATUS` (License); `OPERATORS` (Users); `CHANNELS` (Channels); `ROUTES` (Notification Routing); `WEBHOOKS` and `ENABLED` (Webhooks); `LABELS` (Labels); `TRIVY managed`/`host`/`missing` and `POLICIES` (Vulnerability Scanning); `PROVIDER`, `USED`, `SNAPSHOTS` (Cloud Backup); `DEV MODE` (Developer Diagnostics) |
|
||||
| Section-specific stats | Each section can publish its own pills: `2FA on`/`off` and `BACKUP <n> left` (Account); `PLAN`, `TRIAL <n>d left`, `RENEWS`, `STATUS` (License); `OPERATORS` (Users); `CHANNELS` (Channels); `ROUTES` (Notification Routing); `WEBHOOKS` and `ENABLED` (Webhooks); `LABELS` (Labels); `PROVIDER`, `USED`, `SNAPSHOTS` (Cloud Backup); `DEV MODE` (Developer Diagnostics) |
|
||||
|
||||
### Quick search
|
||||
|
||||
Click **Filter** at the top of the sidebar, or press `Ctrl+K` / `⌘K` while the hub is open, to open the command palette. Type any section name, keyword, or synonym (for example, `saml` finds SSO and `trivy` finds Security) and press Enter to jump to it.
|
||||
Click **Filter** at the top of the sidebar, or press `Ctrl+K` / `⌘K` while the hub is open, to open the command palette. Type any section name, keyword, or synonym (for example, `saml` finds SSO) and press Enter to jump to it.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/settings/settings-search.png" alt="Settings command palette filtered to a webhook query" />
|
||||
@@ -432,44 +433,6 @@ See [Stack Labels](/features/stack-labels) for the full walkthrough.
|
||||
|
||||
---
|
||||
|
||||
## Vulnerability Scanning
|
||||
|
||||
<Note>
|
||||
Vulnerability Scanning is admin-only. The Trivy installer, the **Auto-update Trivy** toggle (which also requires a managed Trivy binary), and CVE/misconfig suppressions are available on all tiers; scan policies require an Admiral license.
|
||||
</Note>
|
||||
|
||||
**Scope:** Per-node
|
||||
|
||||
Manage the Trivy scanner, scan policies, suppressions, and acknowledgements that power [vulnerability scanning](/features/vulnerability-scanning) across the fleet. The masthead publishes a **TRIVY** pill (`managed` / `host` / `missing`) and a **POLICIES** pill with the active rule count.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/settings/settings-security.png" alt="Security section showing the Trivy installer card and the empty scan-policy state" />
|
||||
</Frame>
|
||||
|
||||
### Trivy scanner
|
||||
|
||||
| Element | Description |
|
||||
|---------|-------------|
|
||||
| **Status** | `Installed (managed)` when Sencho manages the binary, `Installed (host)` when an existing host binary is being reused, or empty when nothing is detected. |
|
||||
| **Version** | The current Trivy version, when installed. |
|
||||
| **Install / Update / Uninstall** | Lifecycle actions for the managed binary. Uninstall asks for confirmation. |
|
||||
| **Auto-update Trivy** toggle | When on, Sencho checks daily and installs newer Trivy releases automatically. Requires a managed Trivy binary. |
|
||||
|
||||
### Scan policies
|
||||
|
||||
A scan policy enforces a severity threshold on a set of stacks. Each policy carries a severity level (`CRITICAL`, `HIGH`, `MEDIUM`, `LOW`), a stack pattern (regex), a **Block on deploy** toggle, and an **Enabled** toggle. Use **Add policy** to create one.
|
||||
|
||||
### CVE Suppressions and Misconfig Acknowledgements
|
||||
|
||||
- **CVE Suppressions** are fleet-wide accepted CVEs. They apply at read time across every instance and never modify stored scan data. See [CVE Suppressions](/features/cve-suppressions).
|
||||
- **Misconfig Acknowledgements** are fleet-wide accepted misconfigurations, with the same read-time semantics.
|
||||
|
||||
### Fleet role
|
||||
|
||||
Sencho instances on the Admiral tier can act as a security control plane for the fleet or as a replica. When this instance is a replica, the section shows a **Managed by control node** banner and a **Demote to control** button that converts the replica back into a standalone control.
|
||||
|
||||
---
|
||||
|
||||
## Data Retention
|
||||
|
||||
**Scope:** Per-node
|
||||
|
||||
Reference in New Issue
Block a user