devops: reusable dockerfile scan workflow - #77
Merged
Conversation
… trivy config The two trivy steps were copied into a repo by hand, with the base image tag written a second time next to the Dockerfile's FROM — a copy that goes stale green: Dependabot bumps the Dockerfile, the workflow keeps scanning the old tag and keeps passing. Here the image is read off the FROM line instead. Both scans exit 1 on a finding. Trivy's default is exit 0 with the findings printed, which is a check that cannot fail. Named for what it checks, not for trivy, so swapping the scanner later does not rename the job in every caller.
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.
Same idea as
semgrep.yml: one copy of the scan here, every repo with a Dockerfile calls it.That replaces the two
trivy-actionsteps currently pasted into the caller.The base image is read off the
FROMline, not passed in. A tag written both in the workflow and in the Dockerfile drifts silently green — Dependabot bumps the Dockerfile, the workflow keeps scanning last year's image and keeps passing. Theimage:input stays for the one case that cannot be read: aFROMassembled from anARG.Multi-stage takes the last
FROMthat is not an earlier stage, which is the image the container actually runs on;--platform=flags andscratchare handled. Parser checked against nine Dockerfile shapes before committing.Both scans exit 1 on a finding. Trivy's default is exit 0 with the findings printed, which is a check that cannot fail — this is a behaviour change from the pasted version, whose
configstep could not go red.CRITICAL,HIGHon both, so the misconfig scan does not fail on style.Named for what it checks rather than for trivy, so replacing the scanner later does not rename the job in every caller.