Skip to content

chore(scan): decommission scan infrastructure [TECHOPS-408]#546

Open
jandroav wants to merge 3 commits into
mainfrom
techops-408-docker-decommission
Open

chore(scan): decommission scan infrastructure [TECHOPS-408]#546
jandroav wants to merge 3 commits into
mainfrom
techops-408-docker-decommission

Conversation

@jandroav
Copy link
Copy Markdown
Contributor

@jandroav jandroav commented May 12, 2026

Summary

Decommission this repo's vulnerability scanning. Community image scanning moves to liquibase/liquibase; secure image scanning continues in liquibase/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

  • Delete .github/workflows/trivy.yml (Dockerfile build-time scan — replaced by an equivalent in liquibase/liquibase)
  • Delete .github/workflows/trivy-scan-published-images.yml (published-image scan — replaced by liquibase/liquibase's new one)
  • Delete scripts/generate-dockerhub-matrix.sh, scripts/persist-scan-results.sh, scripts/README.md (all scan-related)
  • Replace the "Vulnerability Scanning" section in README.md with a single-paragraph pointer to the new authoritative scan sources

Total: 6 files, 969 deletions, 1 insertion. size:exception justified — 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:

  • liquibase/liquibase PR #7707 is merged AND first scan run successful (scan-results branch exists in liquibase/liquibase with manifest + image dirs)
  • Public portal at https://security.liquibase.com is rendering community image data from the new source (liquibase/liquibase)
  • No active scheduled runs of the deleted workflows in this repo

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:

  • VEX assessments only cover liquibase-secure images. Community CVEs were never supposed to feed the auto-assess flow.
  • The replacement workflow in liquibase/liquibase (PR #7707) explicitly sets dispatch_new_cves: false.
  • This PR removes the workflow that used to do the dispatch from 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.md to this repo's scan-results branch, redirecting any direct readers. Branch retention: 90 days, then full delete via separate TECHOPS subtask.

Rollback

git revert this PR brings the workflows back. They would resume writing to this repo's scan-results branch. If the new sources aren't producing data in liquibase/liquibase, the public portal would temporarily need to be flipped back via a roll-forward PR in liquibase-internal-security-hub re-adding docker to the allowlist.

🤖 Generated with Claude Code

jandroav and others added 3 commits May 12, 2026 13:04
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>
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 12, 2026

📝 Walkthrough

Walkthrough

This 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.

Changes

Vulnerability Scanning Infrastructure Removal

Layer / File(s) Summary
Scan workflows
.github/workflows/trivy.yml, .github/workflows/trivy-scan-published-images.yml
Trivy vulnerability scanning pipelines for built and published Docker images, including job definitions for three image variants, result aggregation, and optional CVE dispatch logic are deleted.
Matrix generation and result persistence scripts
scripts/generate-dockerhub-matrix.sh, scripts/persist-scan-results.sh
Supporting scripts that fetch Docker Hub tags, build scan matrices, and persist Trivy/Scout results to a scan-results branch are deleted; scripts/README.md documentation of these scripts is removed.
Documentation updates
README.md
Vulnerability Scanning section updated to state that this repository no longer owns published-image scanning; clarifies where community and secure image scans now run and where results are consumed.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

Possibly related PRs

  • liquibase/docker#514: Directly reverses the addition of persist-scan-results.sh and the Trivy published-images workflow job.
  • liquibase/docker#513: Adds the vulnerability-scanning workflows and scripts that this PR removes.
  • liquibase/docker#525: Extends the same Trivy workflows and persist-scan-results script being deleted here.

Suggested labels

skipReleaseNotes, TypeCI

Suggested reviewers

  • jnewton03
  • sayaliM0412
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: decommissioning the repository's scan infrastructure.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description check ✅ Passed The PR description clearly explains the purpose (decommission vulnerability scanning), what changes (files deleted and documentation updated), dependencies required before merge, and rollback strategy.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch techops-408-docker-decommission

Warning

Review ran into problems

🔥 Problems

Timed 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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@claude
Copy link
Copy Markdown
Contributor

claude Bot commented May 12, 2026

Claude finished @jandroav's task in 51s —— View job


Code Review

Issues Found

Critical: SECURITY.md contains outdated references
The PR deletes the "Published Images Vulnerability Scanning" workflow and supporting scripts, but SECURITY.md still extensively documents this workflow. After this PR merges, the following will be broken/outdated:

  • Line 3: "guide explains how to read and interpret the vulnerability scan reports generated by the Published Images Vulnerability Scanning workflow" (workflow deleted)
  • Lines 101-107: Instructions to view results in GitHub Actions under "Published Images Vulnerability Scanning" (workflow deleted)
  • Line 170: Reference to scripts/README.md (deleted in this PR)

Recommendation: Either delete SECURITY.md entirely (since scanning now happens elsewhere) or update it to redirect users to the new scan sources in liquibase/liquibase and liquibase-pro repos.

What looks good

  • README.md "Vulnerability Scanning" section correctly redirects to new sources with accurate links
  • All file deletions are appropriate and intentional per PR scope
  • Clear separation of Community vs Secure image scanning responsibility

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 9d5c6f3 and 4d6b48d.

📒 Files selected for processing (6)
  • .github/workflows/trivy-scan-published-images.yml
  • .github/workflows/trivy.yml
  • README.md
  • scripts/README.md
  • scripts/generate-dockerhub-matrix.sh
  • scripts/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

Comment thread README.md
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.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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.yml returns HTTP 404 (not found)
  • The scan-results branch in liquibase/liquibase does 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).

jandroav added a commit to liquibase/liquibase that referenced this pull request May 12, 2026
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>
jandroav added a commit to liquibase/liquibase that referenced this pull request May 12, 2026
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant