Repository navigation
ci: add DockSec container scan with SARIF upload - #43
Open
advaitpatel wants to merge 3 commits into
Open
advaitpatel wants to merge 3 commits into
advaitpatel wants to merge 3 commits into
Conversation
Scans the Dockerfile with DockSec and uploads the results to code scanning as SARIF, so container findings are annotated on pull requests. Runs scan-only, so no API key is required and no gate is added to the build. All actions are pinned to a commit SHA. Signed-off-by: Advait Patel <advaitpa93@gmail.com>
…IF upload The path filter matched nested Dockerfile/Containerfile variants but the scan itself only ever reads the root Dockerfile, so a change to a nested file would trigger a green run that scanned nothing relevant - worse than no scan, since it reads as coverage that isn't there. Narrowed the trigger to match what is actually scanned. checkout now sets persist-credentials: false; nothing after it needs the token in git config, and the next step runs third-party actions. The SARIF upload no longer runs unconditionally on fork pull requests. GITHUB_TOKEN is read-only there, so security-events: write cannot apply and the upload would fail every time - turning a routine fork contribution into a red required check. It now runs on push, on same-repo PRs, and on schedule, and is skipped on fork PRs. Thanks to a reviewer on an earlier PR for catching all three. Signed-off-by: Advait Patel <advaitpa93@gmail.com>
This repository has no Containerfile, so the trigger path was dead weight - worse than harmless, since a repo that DOES add one later would get a green scan run that never actually reads it (dockerfile: is a fixed string pointing at Dockerfile). Caught by CodeRabbit on the OpenCRE PR; same bug class as the earlier persist-credentials/fork-SARIF fixes, just the half that survived that pass because I hadn't checked whether the repo actually had one. Signed-off-by: Advait Patel <advaitpa93@gmail.com>
Author
|
Hi @al-onyxprotocol @adamantmm @metalisk can I please get your review here? Happy to share more about the tool if needed. Thanks! |
17 of 19 tasks
This branch has not been deployed
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
1 participant
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 this adds
A GitHub Actions workflow that scans the Dockerfile with DockSec
and uploads the results to the Security tab as SARIF, so container findings are
annotated inline on pull requests.
DockSec is an OWASP Lab Project (MIT). It wraps Hadolint and Trivy and reports
Dockerfile misconfigurations and image CVEs through a single SARIF upload.
Why
The repository already publishes SARIF from Semgrep in
.github/workflows/security.yml,so findings in the Security tab are an established pattern here. What is not covered
today is the container layer.
The pinned base image (
node:24.13.0-bookworm-slim, line 20) currently carries7 CRITICAL and 86 HIGH CVEs. None of those are visible to the Semgrep job,
because they are in the image rather than in the source.
The Dockerfile itself scans clean: DockSec scores it 100/100 with no findings.
A note on scope: this workflow scans the Dockerfile only, so the CVE counts above
are not what it will report on day one. Dockerfile scanning is the part that needs
no build and no registry access, which keeps the job fast and the diff small.
Adding
image:to the same step turns on the image scan once you decide where thebuilt image should come from, and I am glad to extend the PR that way if you prefer.
What it does not do
scan_only: true, which isfully local to the runner.
fail_on, so the job reports and neverfails the build. Adding a gate later is a one-line change.
Details
scheduled scan so newly disclosed CVEs in the base image surface without a
code change.
security-events: writeis scoped to the single job that needs it; theworkflow's default permission is
contents: read.Happy to adjust the trigger set, drop the schedule, or split it into an existing
workflow instead if you would prefer that.
Disclosure: I am the project lead for DockSec, the tool this workflow adds. Happy to close this if it is not a fit - no hard feelings either way.