chore(scan): decommission scan infrastructure [TECHOPS-408]#546
chore(scan): decommission scan infrastructure [TECHOPS-408]#546jandroav wants to merge 3 commits into
Conversation
Deleted trivy.yml and trivy-scan-published-images.yml as part of decommissioning liquibase/docker scan ownership (TECHOPS-408). Scanning for the community image moves to liquibase/liquibase. Scanning for liquibase-secure stays in liquibase-pro. Jira: TECHOPS-408 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Deleted generate-dockerhub-matrix.sh, persist-scan-results.sh, and scripts/README.md (which documented only these two scan scripts). The scripts/ directory is now empty and has been removed. Jira: TECHOPS-408 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The section previously described scan workflows and scripts that have been deleted in this PR. Replace with a single pointer paragraph that directs readers to where scanning now lives: liquibase/liquibase for the community image and liquibase-pro for the secure image. Jira: TECHOPS-408 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis PR removes the repository's owned vulnerability scanning infrastructure for published Docker images. Deleted are two GitHub Actions workflows (Trivy scans for published and built images), two supporting scripts for matrix generation and result persistence, and relevant documentation. Updated documentation clarifies that vulnerability scanning now occurs in downstream repositories. ChangesVulnerability Scanning Infrastructure Removal
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsTimed out fetching pipeline failures after 30000ms Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Claude finished @jandroav's task in 51s —— View job Code ReviewIssues FoundCritical: SECURITY.md contains outdated references
Recommendation: Either delete What looks good
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@README.md`:
- Line 281: The README mentions non-existent external resources: update the
sentence referencing the workflow file and branch so it points to existing
assets or remove the broken links; specifically fix the URL to the workflow
(`.github/workflows/trivy-scan-published-images.yml`) and the branch name
`scan-results` for the liquibase/liquibase repo (or replace with the correct
workflow path and existing branch), and adjust the `liquibase/liquibase-secure`
/ `liquibase-pro` references if needed so all links resolve (alternatively,
remove the external links and replace with a note that the scans are maintained
elsewhere until the resources are created).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 66373475-bc4d-4e6a-ae0a-f0d7f5e536c1
📒 Files selected for processing (6)
.github/workflows/trivy-scan-published-images.yml.github/workflows/trivy.ymlREADME.mdscripts/README.mdscripts/generate-dockerhub-matrix.shscripts/persist-scan-results.sh
💤 Files with no reviewable changes (5)
- .github/workflows/trivy-scan-published-images.yml
- scripts/README.md
- scripts/persist-scan-results.sh
- scripts/generate-dockerhub-matrix.sh
- .github/workflows/trivy.yml
| 3. Choose a workflow run to view the summary or download artifacts | ||
|
|
||
| For a detailed guide on reading vulnerability reports, see [SECURITY.md](SECURITY.md). | ||
| This repository no longer owns published-image vulnerability scanning. The community Liquibase image (`liquibase/liquibase`) is scanned by [liquibase/liquibase](https://github.com/liquibase/liquibase/blob/main/.github/workflows/trivy-scan-published-images.yml) and results are published to its `scan-results` branch — consumed by [security.liquibase.com](https://security.liquibase.com). Secure-distribution images (`liquibase/liquibase-secure`) are scanned in `liquibase-pro` and consumed by the internal security portal. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify that external resources referenced in the documentation exist
echo "=== Checking workflow file existence ==="
# Check if the workflow file exists in liquibase/liquibase repo
gh api repos/liquibase/liquibase/contents/.github/workflows/trivy-scan-published-images.yml \
--jq '.name' 2>&1 || echo "ERROR: Workflow file not found"
echo ""
echo "=== Checking scan-results branch existence ==="
# Check if scan-results branch exists in liquibase/liquibase repo
gh api repos/liquibase/liquibase/branches/scan-results \
--jq '.name' 2>&1 || echo "ERROR: scan-results branch not found"
echo ""
echo "=== Checking security portal accessibility ==="
# Check if the security portal is accessible
curl -s -o /dev/null -w "HTTP Status: %{http_code}\n" https://security.liquibase.com || echo "ERROR: Portal not accessible"
echo ""
echo "=== Verification complete ==="
echo "All resources should exist per the hard merge gates in PR objectives"Repository: liquibase/docker
Length of output: 693
Documentation references non-existent resources and cannot merge.
The documentation at line 281 directs readers to external resources that do not exist:
- The workflow file at
https://github.com/liquibase/liquibase/blob/main/.github/workflows/trivy-scan-published-images.ymlreturns HTTP 404 (not found) - The
scan-resultsbranch inliquibase/liquibasedoes not exist (HTTP 404)
The security portal at https://security.liquibase.com is accessible (HTTP 200).
Either the referenced resources must be created before merging, or the documentation must be corrected to point to existing resources. Per PR objectives, these are hard merge gates.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` at line 281, The README mentions non-existent external resources:
update the sentence referencing the workflow file and branch so it points to
existing assets or remove the broken links; specifically fix the URL to the
workflow (`.github/workflows/trivy-scan-published-images.yml`) and the branch
name `scan-results` for the liquibase/liquibase repo (or replace with the
correct workflow path and existing branch), and adjust the
`liquibase/liquibase-secure` / `liquibase-pro` references if needed so all links
resolve (alternatively, remove the external links and replace with a note that
the scans are maintained elsewhere until the resources are created).
Community images do not feed the VEX auto-assess pipeline. VEX assessments only apply to liquibase-secure images (gated on vex_enabled=true in build-logic/.github/workflows/reusable-vulnerability-scan.yml), and that flag is intentionally false in this workflow. Dispatching community CVEs to liquibase/liquibase-pro/investigate-cve.lock.yml would just add noise to the auto-assess queue: assessments would be opened against packages that the secure-side flow may not even contain, and the resulting VEX statements would never be applied back to community scans (which don't read vex-repo). This was an orchestrator-side error baked into the original TECHOPS-408 plan that conflated "scan dispatches CVEs" with "scan needs to inform investigations." Changes: - Set dispatch_new_cves: false on the reusable workflow call. Disables build-logic's internal AWS-vault + App-token steps for this scan. - Remove the local persist-results job's "Get GitHub App token for liquibase-pro" step and the entire "Dispatch new CVEs for investigation" step (~154 lines). - Drop the now-unused build-logic checkout (was only used by the dispatch step's diff-new-cves.sh script invocation). - Drop the now-unused id-token: write permission. Net diff: -163, +4. Implication for downstream changes: - The "CVE-dispatch orphan" risk flagged on liquibase/docker#546 (docker-decommission) is a phantom — community CVEs were never supposed to be investigated. No replacement dispatch is needed there either. - The GitHub App admin grant prerequisite for Actions: Write on liquibase-pro is no longer required for this PR. Jira: TECHOPS-408 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* chore(ci): add scan helper scripts for community image scanning Add scripts/generate-dockerhub-matrix.sh (community-only, scans only liquibase/liquibase) and scripts/persist-scan-results.sh (verbatim from liquibase-pro — self-bootstraps the scan-results orphan branch). These support the new trivy-scan-published-images.yml workflow added in the follow-up commit. Part of TECHOPS-408: split scan ownership so liquibase/liquibase owns community image scanning end-to-end. Jira: TECHOPS-408 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(ci): add community image vulnerability scan workflows [TECHOPS-408] Port two scan workflows into liquibase/liquibase so this repo owns community image vulnerability scanning end-to-end. Today both this matrix is handled by liquibase/docker (to be decommissioned) — this move keeps the public security.liquibase.com portal data on a public repo branch (preserves the public/internal boundary). Files: - .github/workflows/trivy-scan-published-images.yml — ported from liquibase-pro, AWS/vault block stripped, App token mint via actions/create-github-app-token@v3.1.1 with LIQUIBASE_GITHUB_APP_ID and LIQUIBASE_GITHUB_APP_PRIVATE_KEY (pattern from docker-release.yml). vex_enabled: false, dispatch_new_cves: true (dispatches new community CVEs to liquibase-pro/investigate-cve.lock.yml). - .github/workflows/trivy.yml — ported from liquibase/docker, scan-secure job + AWS Slack notifier removed, Dockerfile paths scoped to docker/. vex_enabled: false. Both workflows share concurrency.group: scan-results-writer with cancel-in-progress: false to serialize pushes to the scan-results branch. Schedule: - Published-image scan: Mon-Fri 10:00 UTC + workflow_dispatch - Dockerfile build-time scan: push + PR + Mon 07:00 UTC Pre-merge prerequisites (verified before merge): - LIQUIBASE_GITHUB_APP_ID + LIQUIBASE_GITHUB_APP_PRIVATE_KEY repo secrets - GitHub App grant: Actions: Write on liquibase-pro (for CVE dispatch) Post-merge action: gh workflow run trivy-scan-published-images.yml -R liquibase/liquibase to bootstrap the scan-results orphan branch immediately rather than waiting for the next cron. Note: docker-scan.yml (existing) and trivy.yml coexist intentionally; they target different scan surfaces. Dual-SARIF cleanup tracked as a follow-up once trivy.yml is stable. Jira: TECHOPS-408 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(ci): remove CVE dispatch from community scan workflow Community images do not feed the VEX auto-assess pipeline. VEX assessments only apply to liquibase-secure images (gated on vex_enabled=true in build-logic/.github/workflows/reusable-vulnerability-scan.yml), and that flag is intentionally false in this workflow. Dispatching community CVEs to liquibase/liquibase-pro/investigate-cve.lock.yml would just add noise to the auto-assess queue: assessments would be opened against packages that the secure-side flow may not even contain, and the resulting VEX statements would never be applied back to community scans (which don't read vex-repo). This was an orchestrator-side error baked into the original TECHOPS-408 plan that conflated "scan dispatches CVEs" with "scan needs to inform investigations." Changes: - Set dispatch_new_cves: false on the reusable workflow call. Disables build-logic's internal AWS-vault + App-token steps for this scan. - Remove the local persist-results job's "Get GitHub App token for liquibase-pro" step and the entire "Dispatch new CVEs for investigation" step (~154 lines). - Drop the now-unused build-logic checkout (was only used by the dispatch step's diff-new-cves.sh script invocation). - Drop the now-unused id-token: write permission. Net diff: -163, +4. Implication for downstream changes: - The "CVE-dispatch orphan" risk flagged on liquibase/docker#546 (docker-decommission) is a phantom — community CVEs were never supposed to be investigated. No replacement dispatch is needed there either. - The GitHub App admin grant prerequisite for Actions: Write on liquibase-pro is no longer required for this PR. Jira: TECHOPS-408 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * revert(ci): drop redundant trivy.yml; docker-scan.yml already covers it trivy.yml was ported from liquibase/docker as part of TECHOPS-408 on the assumption that liquibase/liquibase needed an equivalent build-time Dockerfile scan. That assumption was wrong: .github/workflows/docker-scan.yml already does exactly this work in this repo: - Same reusable-docker-scan.yml@main caller - Same scan-community + scan-alpine matrix on the same Dockerfile paths - Same Mon-Fri 07:00 UTC cron + push/PR triggers on docker/** - Same vex_enabled: false (community has no VEX coverage) - Same upload_sarif: true to the GitHub Security tab The persist-results job in my trivy.yml was pushing build-time scan output to the scan-results branch, but that branch is for the *published-image* scan results consumed by the portal — the trivy-scan-published-images.yml in this same PR already handles that. Conflating both result types on the same branch would corrupt the portal's manifest shape. Net effect for this PR: 3 new files instead of 4. The dual-SARIF cleanup follow-up flagged in the original verify report is no longer needed — there is no duplication to clean up. Jira: TECHOPS-408 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
Decommission this repo's vulnerability scanning. Community image scanning moves to
liquibase/liquibase; secure image scanning continues inliquibase/liquibase-pro. This repo becomes scan-free.Part of TECHOPS-408: split scan ownership by image family + restore the public/internal data-source boundary.
What changes
.github/workflows/trivy.yml(Dockerfile build-time scan — replaced by an equivalent inliquibase/liquibase).github/workflows/trivy-scan-published-images.yml(published-image scan — replaced byliquibase/liquibase's new one)scripts/generate-dockerhub-matrix.sh,scripts/persist-scan-results.sh,scripts/README.md(all scan-related)README.mdwith a single-paragraph pointer to the new authoritative scan sourcesTotal: 6 files, 969 deletions, 1 insertion.
size:exceptionjustified — 99% mechanical deletions, zero behavior changes left in the diff.Hard merge gate (NON-NEGOTIABLE)
Merging this PR before its dependencies will 404 the public portal (the same outage class TECHOPS-408 is trying to prevent). Block merge until:
scan-resultsbranch exists in liquibase/liquibase with manifest + image dirs)liquibase/liquibase)Phantom risk: CVE-dispatch orphan (no longer applies)
An earlier version of the plan flagged a risk that this PR would orphan community CVE dispatch into
liquibase-pro/investigate-cve.lock.yml. That risk does not apply:liquibase-secureimages. Community CVEs were never supposed to feed the auto-assess flow.liquibase/liquibase(PR #7707) explicitly setsdispatch_new_cves: false.liquibase/docker. That's the correct end state.Follow-up (PR B)
After this PR merges, a small PR B will add a
DECOMMISSION-NOTICE.mdto this repo'sscan-resultsbranch, redirecting any direct readers. Branch retention: 90 days, then full delete via separate TECHOPS subtask.Rollback
git revertthis PR brings the workflows back. They would resume writing to this repo'sscan-resultsbranch. If the new sources aren't producing data inliquibase/liquibase, the public portal would temporarily need to be flipped back via a roll-forward PR inliquibase-internal-security-hubre-addingdockerto the allowlist.🤖 Generated with Claude Code