Skip to content

UID2-7390: support building a specific Dockerfile in the vuln-scan notify workflow#244

Open
swibi-ttd wants to merge 1 commit into
mainfrom
swi-UID2-7390-shared-dockerfile-scan
Open

UID2-7390: support building a specific Dockerfile in the vuln-scan notify workflow#244
swibi-ttd wants to merge 1 commit into
mainfrom
swi-UID2-7390-shared-dockerfile-scan

Conversation

@swibi-ttd

Copy link
Copy Markdown
Contributor

What

Adds an optional dockerfile input to shared-vulnerability-scan-failure-notify.yaml. When set, image mode skips the JDK/Maven build and instead docker 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 default Dockerfile → 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

dockerfile defaults to ''. The Maven build steps are gated on inputs.dockerfile == '', and the scan's image_ref resolves to the Maven-built tag when dockerfile is 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 no dockerfile, 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. Requires v3 to be re-tagged to this commit after merge.

🤖 Generated with Claude Code

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant