UID2-7390: support building a specific Dockerfile in the vuln-scan notify workflow#244
Open
swibi-ttd wants to merge 1 commit into
Open
UID2-7390: support building a specific Dockerfile in the vuln-scan notify workflow#244swibi-ttd wants to merge 1 commit into
swibi-ttd wants to merge 1 commit into
Conversation
The scheduled vulnerability-scan-failure-notify workflow's image mode only supported a Maven build (mvn package -> docker build the default Dockerfile -> scan -> Slack notify). Non-Maven repos (or repos with multiple Dockerfiles, e.g. uid2-self-serve-portal's Keycloak image) had no way to reach the scan + notify tail without re-implementing it. Add an optional `dockerfile` input. When set, the JDK/Maven steps are skipped and that Dockerfile is built directly (re-pulling its base image each run) and scanned, reusing the existing Slack-notify + fail steps. When empty (the default), image mode builds via Maven exactly as before, so existing image-mode callers (uid2-admin, uid2-core, uid2-e2e, uid2-operator, uid2-optout, uid2-snowflake, uid2-validator) are unaffected. This lets repos schedule recurring scans of an image they build with a single matrix entry, with build + scan + notify centralised here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
swibi-ttd
added a commit
to IABTechLab/uid2-self-serve-portal
that referenced
this pull request
Jun 29, 2026
The scheduled vulnerability-scan workflow only ran an fs scan (repo manifests), which can't see inside a container base image. The Keycloak IdP image is a Java/Quarkus base image, so its auth-path CVEs (e.g. CVE-2026-4282, fixed by the bump in UID2-7391) were never surfaced by a scheduled scan. Add an image-scan job that scans the Keycloak image on the same schedule by calling the shared notify workflow with the new `dockerfile` input, which builds the image fresh (re-pulling the pinned base, so newly-disclosed base CVEs are caught without a new release) and reuses the shared workflow's scan + Slack-notify + fail logic. To cover another image later, add its Dockerfile to the matrix. Scope is the Keycloak image only: the migration/app images are node:20-alpine whose npm deps are the subject of the fs scan, and their bundled devDependency CVEs are tracked separately in UID2-7393. Depends on IABTechLab/uid2-shared-actions#244 (the `dockerfile` input), which must merge and re-tag v3 first. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
swibi-ttd
added a commit
to IABTechLab/uid2-self-serve-portal
that referenced
this pull request
Jun 29, 2026
The scheduled vulnerability-scan workflow only ran an fs scan (repo manifests), which can't see inside a container base image. The Keycloak IdP image is a Java/Quarkus base image, so its auth-path CVEs (e.g. CVE-2026-4282, fixed by the bump in UID2-7391) were never surfaced by a scheduled scan. Add an image-scan job that scans the Keycloak image on the same schedule by calling the shared notify workflow with the new `dockerfile` input, which builds the image fresh (re-pulling the pinned base, so newly-disclosed base CVEs are caught without a new release) and reuses the shared workflow's scan + Slack-notify + fail logic. To cover another image later, add its Dockerfile to the matrix. Also suppress the 5 residual HIGH CVEs bundled in the upstream Keycloak 26.6.4 image (jackson-databind x2, mssql-jdbc, java-21-openjdk x2) in .trivyignore with a short expiry, so this scan settles to green and only fires on genuinely new HIGH CVEs. We are already on the latest stable Keycloak, so these are only fixable by a future upstream release. Scope is the Keycloak image only: the migration/app images are node:20-alpine whose npm deps are the subject of the fs scan, and their bundled devDependency CVEs are tracked separately in UID2-7393. Depends on IABTechLab/uid2-shared-actions#244 (the `dockerfile` input), which must merge and re-tag v3 first. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds an optional
dockerfileinput toshared-vulnerability-scan-failure-notify.yaml. When set, image mode skips the JDK/Maven build and insteaddocker builds the supplied Dockerfile directly (re-pulling its base image), then runs the existing scan + Slack-notify + fail steps. When empty (the default), image mode builds via Maven exactly as today.Why
Image mode was hardwired to a Maven build (
mvn package→ build the defaultDockerfile→ scan → notify). Non-Maven repos, or repos with multiple differently-named Dockerfiles (e.g.uid2-self-serve-portal's Keycloak image), couldn't reach the scan + notify tail without copying it. That copy is the duplication this removes: a caller can now schedule a recurring scan of an image it builds with a single matrix entry, and build + scan + notify stay defined once, here.Backward compatibility
dockerfiledefaults to''. The Maven build steps are gated oninputs.dockerfile == '', and the scan'simage_refresolves to the Maven-built tag whendockerfileis empty. The repos that call this in image mode today (uid2-admin,uid2-core,uid2-e2e,uid2-operator,uid2-optout,uid2-snowflake,uid2-validator) pass nodockerfile, so they run the identical Maven path. No changes required in those repos.First consumer
uid2-self-serve-portal(separate PR) calls this in a matrix to scan its Keycloak image on the existing schedule. Requiresv3to be re-tagged to this commit after merge.🤖 Generated with Claude Code