Repository navigation
Add container image vulnerability scanning to CI #51
Description
Goal
Add automated vulnerability scanning for the runtime container image built by this repository.
The scan should help detect important known vulnerabilities before an image change is merged or published.
Tool
Use Trivy to scan the container image.
The same vulnerability policy must be used locally and in CI.
GitHub Actions should run the scan, but the scan rules must not exist only inside the workflow.
Keep any project-specific Trivy configuration in the repository.
What to scan
Scan the final runtime image built by this repository.
Do not scan only source files, dependency files, or Dockerfiles.
The goal is to inspect the software and operating-system packages that are present in the final runtime image.
Do not refactor the image build as part of this issue.
Severity policy
The CI job must fail when Trivy finds a vulnerability that:
- has severity
HIGHorCRITICAL; - has a fix available.
Lower severities may still appear in the report, but they do not need to fail the job.
The scan must also fail if the detected base operating system is end-of-life.
Do not ignore vulnerabilities only to make CI pass.
If an exception is needed, it must have a clear reason and should be handled separately.
CI output
The GitHub Actions job must provide useful output when the scan fails.
Use readable Trivy output in the job logs.
Also produce SARIF output for GitHub code scanning when possible.
The SARIF report may be generated in a separate Trivy execution, but it must use:
- the same runtime image;
- the same severity policy;
- the same rule for vulnerabilities with fixes available.
SARIF must not introduce a different security policy from the CI gate.
The workflow should only run the scan. Configuration that must stay the same between local and CI execution should live in the repository.
Local execution
Provide one documented command to run the same vulnerability scan locally.
The local command must use the same:
- runtime image;
- severity policy;
- rule for vulnerabilities with fixes available;
- operating-system EOL check.
A contributor should be able to reproduce a CI vulnerability failure locally without running GitHub Actions.
Acceptance criteria
- Trivy scans the final runtime container image.
- The scan can be run locally with a documented command.
- CI uses the same vulnerability policy as local execution.
HIGHandCRITICALvulnerabilities with a fix available fail the CI job.- An end-of-life base operating system fails the CI job.
- Findings are easy to inspect in GitHub Actions logs.
- SARIF output uses the same image and vulnerability policy as the CI gate.
- Shared Trivy configuration is stored in the repository.
- Vulnerabilities are not silently ignored.
- The existing image build architecture is not refactored as part of this issue.
Security note
Container vulnerability scanning is only one part of the security baseline.
It does not replace runtime tests, dependency verification, review of privileges, or container hardening.
Good first issue
Keep this issue focused on adding Trivy scanning for the existing runtime image.
If the scan requires changes to how the runtime image is built, ask for guidance instead of expanding the scope.
Activity
tomatotomata commentedon Sep 13, 2026
Hi @vitormattos, I was looking at #51 and was thinking of adding one image-scan job around the runtime image this repository already builds, with readable CI output plus SARIF and a documented local equivalent. I would keep the Docker build itself unchanged and make the failure threshold explicit. Would Trivy with a high/critical threshold fit the intended boundary, or do you prefer another scanner or policy?
vitormattos commentedon Sep 13, 2026
Trivy fits the intended scope.
I also agree with keeping the image build unchanged and using the same scan policy locally and in CI. I updated the issue to make the expected scope and policy clearer.
For the initial policy, let's fail on HIGH and CRITICAL vulnerabilities that already have a fix available. SARIF is also welcome as long as it uses the same scan policy and does not duplicate the scan logic.
Please note that this issue is currently blocked by the dependency linked in GitHub, so it is better to wait for that work to be completed before starting the implementation.
vitormattos commentedon Sep 13, 2026
@tomatotomata small correction to my previous comment: this issue is not blocked by another issue. I updated the issue description to remove that incorrect dependency and clarify the Trivy scope and policy.
You do not need to wait for another issue before starting this one.
tomatotomata commentedon Sep 16, 2026
Thanks for clearing that up. I had held off because of the earlier dependency note. I noticed the workflow builds separate
appandwebruntime images, so I’m planning to apply the same Trivy policy to both without touching the Docker build itself. If you meant the app image only, let me know and I can narrow that before I send it over.vitormattos commentedon Sep 16, 2026
Yes, please scan both
appandweb.The idea is that every final image we build and publish from this repository should be scanned. We do not need to scan upstream images separately, but anything we generate and distribute should pass through the same Trivy policy.
So applying the same policy to both runtime images is the expected scope.
vitormattos commentedon Oct 7, 2026
This is implemented on
mainby #55, with the separate gzip remediation from #56.Current repository state matches the acceptance criteria:
appandwebimages are scanned;make scan-imagesprovides the local equivalent;The latest
mainimage workflow is also passing, so this issue can be closed as completed.