Skip to content

Add container image vulnerability scanning to CI #51

Closed

Description

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

Activity

  1. tomatotomata commented on Sep 13, 2026

    @tomatotomata
    Contributor

    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?

  2. vitormattos commented on Sep 13, 2026

    @vitormattos
    MemberAuthor

    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.

  3. vitormattos commented on Sep 13, 2026

    @vitormattos
    MemberAuthor

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

  4. tomatotomata commented on Sep 16, 2026

    @tomatotomata
    Contributor

    Thanks for clearing that up. I had held off because of the earlier dependency note. I noticed the workflow builds separate app and web runtime 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.

  5. vitormattos commented on Sep 16, 2026

    @vitormattos
    MemberAuthor

    Yes, please scan both app and web.

    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.

  6. vitormattos commented on Oct 7, 2026

    @vitormattos
    MemberAuthor

    This is implemented on main by #55, with the separate gzip remediation from #56.

    Current repository state matches the acceptance criteria:

    • final app and web images are scanned;
    • amd64 and arm64 both pass the same Trivy policy before publication;
    • HIGH/CRITICAL findings with fixes available fail the gate;
    • EOL operating systems fail the gate;
    • SARIF is produced;
    • make scan-images provides the local equivalent;
    • the image build architecture was not refactored as part of the scanning issue.

    The latest main image workflow is also passing, so this issue can be closed as completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions