Snyk Dockerfile Scan + slack v5f

[Wolfgang-Romanowski]

Description

Adds revamp to automated Snyk security scanning for training runtime Dockerfiles.
Scans differentiate between inherited base image vulnerabilities and new vulnerabilities introduced by Dockerfile changes.

• Fails builds on critical/high severity vulnerabilities introduced by Dockerfile
• Allows builds to proceed with only inherited base image vulnerabilities

Trigger Conditions:

• Push to main branch (when training Dockerfiles change)
• Pull requests with changes to training Dockerfiles
• Nightly scheduled runs at 03:00 UTC
• Manual workflow dispatch with debug options
• Fork PRs after applying run-snyk label
• Tested on fork

will require:
SNYK_TOKEN secret
SLACK_WEBHOOK_URL secret

Tested
Tested on fork thoroughly

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign laurafitzgerald for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sutaakar]

When should this third condition be applied?
First condition applies for anything else apart from PRs from forks (I suppose), second covers pull_request_target with proper label.

[Wolfgang-Romanowski]

1: should be applied for all events except for pull request target, this includes events from forks which are safe since they run in the forks context.

2: applies for events with manual labeling

3: events from within the same repository

fork PRs run safely under condition 1 via regular pull request events, not pull request target.

sorry for not making that clearer

[sutaakar]

Thanks, makes me think, why do you have there both pull_request and pull_request_target?

[Wolfgang-Romanowski]

No worries at all!
So the reason why is because pull_request automatically scans trusted PRs within the same reo and pull_request_target ends up allowing scanning fork PRs after manual approval via label.

Without the dual approach we'd either never scan fork PRs or always give fork PRs access to secrets

[sutaakar]

Ran the code in my fork, it seems that there are missing ${PYTHON_VERSION}:${IMAGE_TAG} placeholder values in Individual Dockerfile Analysis.
See https://github.com/sutaakar/distributed-workloads/actions/runs/15442769297

Edit: I suppose it is taken from the Dockerfile itself, where we have placeholder, right?
In that case I guess there is not much to do apart from simulating container engine itself (overkill).
Although in the GitHub logs I see Scanning base image: registry.access.redhat.com/ubi9/python-311:9.5-1741671866

[Wolfgang-Romanowski]

Ran the code in my fork, it seems that there are missing ${PYTHON_VERSION}:${IMAGE_TAG} placeholder values in Individual Dockerfile Analysis. See https://github.com/sutaakar/distributed-workloads/actions/runs/15442769297

Edit: I suppose it is taken from the Dockerfile itself, where we have placeholder, right? In that case I guess there is not much to do apart from simulating container engine itself (overkill). Although in the GitHub logs I see Scanning base image: registry.access.redhat.com/ubi9/python-311:9.5-1741671866

i can try updating the extraction logic to use build time values or read from a config files where values are defined

but from what i gather the scan itself is fine and its just a confusing display