* feat: pre-deploy scan visibility and pinned scanner version
Pin managed Trivy installs and add an opt-in pre-deploy scan advisory so a
manual deploy can surface each image's latest scan before it runs.
- Managed Trivy now installs a pinned, known-good version by default for
reproducible installs. Auto-update still tracks the latest release, and an
explicit update always pulls the latest.
- Add an opt-in pre-deploy scan advisory: when enabled, deploying a stack from
the editor first shows each image's latest cached scan severity for review.
It is visibility only and never blocks; deploy enforcement is unchanged.
- Backend: pre_deploy_scan_advisory setting, PUT
/security/pre-deploy-scan-advisory, a cache-only GET
/security/stacks/:name/pre-deploy-summary, and a node-scoped
getLatestVulnScanByDigestForNode lookup.
- Frontend: advisory toggle on the Security page scanner setup, and a
PreDeployScanDialog wired into the editor deploy flow that fails open when the
summary is unavailable.
- Docs: scanner configuration, version pinning, and the advisory.
* fix: harden pre-deploy advisory guard, toggle visibility, and installer busy state
Addresses review findings on the pre-deploy advisory.
- Block a second editor deploy during the async advisory window with a
synchronous pending ref, cleared on cancel and in the deploy's finally, so a
double-click can no longer start two deploys.
- Keep the pre-deploy advisory toggle visible to admins whenever the setting is
on, so it can still be turned off after the scanner becomes unavailable.
- Resolve the managed Trivy version inside the install lock so the busy state and
serialization cover the latest-version fetch and the managed-install check.
* feat(security): one-click managed Trivy install
Add a Vulnerability Scanner card to Settings, Security with install,
update, uninstall, and auto-update controls (Admiral-only). The installer
downloads a verified Trivy release into the existing data volume at
/app/data/bin/trivy and defaults the cache to /app/data/trivy-cache, so
no host mounts or extra env vars are required. Detection probes the
managed path, a TRIVY_BIN override, and the host PATH, distinguishing
managed vs host installs. A daily scheduled check surfaces available
Trivy updates, installs them automatically when opted in, and dedupes
notifications per version.
* fix(frontend): silence react-hooks/set-state-in-effect in useTrivyStatus
The initial status fetch and managed-source update check both call
setState from the effect body. Match the existing pattern used in
useDashboardData / SSOSection and disable the rule at the call site.
Anso