Add container image vulnerability scanning to CI

[vitormattos]

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 HIGH or CRITICAL;
• 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.
• HIGH and CRITICAL vulnerabilities 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.

[tomatotomata]

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]

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]

@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.