feat: restore Trivy scanning via Socket-built distribution - #100
Conversation
Trivy returns to the main, heavy, and app_tests images as a Socket-built distribution: rebuilt from unmodified upstream source (v0.73.0) by Socket's own release pipeline and pinned by digest (TRIVY_IMAGE build arg; override available for builds without registry access). - Dockerfiles: digest-pinned trivy stage restored; version label now truthful - CI: GHCR login on every build mode (private base image) + packages: read - Smoke tests: drop the removal guard; verify trivy presence, version-pin agreement, and a functional 'trivy config' scan (the connector's code path) - Dependabot: trivy untracked by design — updates flow from the Socket release process, never independent bumps - Docs: removed the temporarily-disabled messaging repo-wide; kept the 0.69.4-0.69.6 warnings for native installs; fixed the APT example to the 'generic' distribution (upstream change in trivy v0.72.0) Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
Batch with the Trivy restore since this warrants a major point release: TruffleHog 3.93.8 -> 3.96.0, OpenGrep v1.16.5 -> v1.26.0, uv 0.10.11 -> 0.12.1, gosec v2.24.7 -> v2.28.0 (app_tests), Go 1.24.1 -> 1.26.5 (app_tests), Socket CLI 2.5.0 -> 2.5.8 (heavy). Runtime bases (python:3.12, node:22) deliberately deferred to their own PR. Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
|
Added the OSS toolchain refresh to this PR (major point release anyway): TruffleHog → 3.96.0, OpenGrep → v1.26.0, uv → 0.12.1, gosec → v2.28.0, Go → 1.26.5 (app_tests), Socket CLI → 2.5.8 (heavy). Runtime bases ( |
The app_tests image predates the socket_basics layout migration: its COPY src/... and entrypoint.sh references no longer exist anywhere in the repo, so it could not build at all (its CI job only fires on app_tests changes and had not run since). Drop the stale references (tools image for now; modernizing the harness is follow-up work) and build with app_tests/ as the context so its own pyproject/uv.lock and fixtures resolve. Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
COPY --from dereferences the node image's npm/npx symlinks into flat files under /usr/local/bin, breaking npm's relative require of ../lib/cli.js. Copy node + node_modules and recreate the bin symlinks properly. Another latent issue in this previously-unbuildable image, surfaced now that it builds again. Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
The /scripts venv installed light-s3-client for the removed legacy runner against an empty stub pyproject, and app_tests/uv.lock was corrupt TOML (empty package name) that modern uv refuses to parse. Regenerate a valid lockfile for the stub manifest, drop the pointless venv bake from the image, and retire the last socket-security-tools fossil (WORKDIR). Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
Scans a fixture Dockerfile through socket-basics --dockerfiles, exercising config -> trivy config -> result parsing. Explicitly fails on the connector's 'Trivy not found' fallback so a missing binary can't pass vacuously. Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
Docker Hub secrets move from repo-level to environment secrets on 'publish' (deployment policy: main + v* tags; secrets already created). merge-manifests binds the environment directly; build-test-push calls the reusable workflow (which cannot carry environment:), so it inherits secrets and the reusable pipeline job binds the environment conditionally in push mode only — PR-branch test builds bind no environment. Repo-level secrets stay until a real publish validates the path, then get deleted. Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
|
Two additions per discussion: (1) integration Test 4 — the trivy connector now runs end-to-end against a fixture Dockerfile ( |
zizmor's secrets-inherit audit flags the inherit on build-test-push; it is required here — environment-scoped secrets only resolve on the environment- bound job inside the called same-repo workflow, never through an explicit workflow-call mapping. Inline ignore with rationale, matching the repo's existing template-injection exceptions. Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
latest/latest-heavy float to the newest release as onboarding convenience; exact version tags stay immutable registry-side (Docker Hub immutable-tag rule ^\d+\.\d+\.\d+(-heavy)?$, already applied). Dispatch re-publish is now documented as recovery-only: re-pushing a published version tag is rejected by the registry, by design. Pinning docs updated to match. Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
|
bugbot run |
metadata-action only suffixes the auto-generated latest tag when the suffix carries onlatest=true; without it both matrix variants publish a bare, racing 'latest' and 'latest-heavy' is never created. Caught by Bugbot. Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 3b72bc4. Configure here.
What
Restores Trivy-backed scanning and overhauls the publish pipeline — the scope grew deliberately as part of the major-release batch:
ghcr.io/socketdev/trivy:0.73.0@sha256:e3d9d5f1…(rebuilt from unmodified upstream source, digest-pinned,TRIVY_IMAGEoverride available).app_testswas still pullingaquasec/trivy:0.69.3from Docker Hub by mutable tag — converted.publishenvironment:merge-manifestsbinds the environment;build-test-pushusessecrets: inheritwith the reusable pipeline bindingpublishin push mode only (PR builds bind none). Repo-levelDOCKERHUB_*secrets stay until the first publish validates the path, then get deleted.latest/latest-heavyaliases reintroduced (flavor: latest=true): safe now that version tags are registry-immutable (^\d+\.\d+\.\d+(-heavy)?$rule applied on Docker Hub). Dispatch re-publish documented as recovery-only.trivy configscan in every image; new integration Test 4 runs the trivy connector end-to-end (--dockerfilesfixture) and explicitly fails on the connector's silent "Trivy not found" fallback.uv.lock) — all repaired; lockfile regenerated.packages: readin callers) for the private base image; documented zizmor exception forsecrets-inherit.0.69.4–0.69.6warnings retained for native installs; APTgenericfix; pinning guidance updated for the new alias.No Python changes — the trivy connector is config-driven and needed none.
Reviewer notes
ghcr.io/socketdev/trivy; without it:docker build --build-arg TRIVY_IMAGE=aquasec/trivy:0.73.0 .Note
High Risk
Re-enables container scanning and changes release tagging (
latest) plus credential scoping for production image publishes; incorrect pins or publish config could affect every consumer of the pre-built images.Overview
Restores Trivy in the main, heavy, and
app_testsimages by sourcing a digest-pinnedghcr.io/socketdev/trivybase (TRIVY_IMAGE) instead ofaquasec/trivy, with Dependabot no longer bumping Trivy independently. Tool pins move forward (e.g. TruffleHog, OpenGrep, uv, OpenGrep/gosec/Go in app tests) and docs/action.ymldrop the “Trivy temporarily unavailable” wording while keeping native-install warnings for compromised0.69.4–0.69.6tags.Publish and PR CI scope Docker Hub credentials to the
publishenvironment (secrets: inherit, environment only on push), always log into GHCR withpackages: readfor the private Trivy base, and re-enable floatinglatest/latest-heavyalongside immutable semver tags. Smoke/integration tests now assert Trivy is present, matches the Dockerfile pin, and runstrivy config;app_testsbuilds fromapp_tests/context with a fixed Dockerfile (npm symlinks, lockfile, removed stale runner COPYs).Reviewed by Cursor Bugbot for commit 3b72bc4. Configure here.