Skip to content

Container vulnerability scanning

Nightly and release workflows scan both runtime platforms of the candidate image before publishing any identity or moving tag. The scan blocks publication when a HIGH or CRITICAL operating-system or application-library vulnerability has a known fix. Unfixed findings remain visible in Trivy's vulnerability data but do not block publication.

The runtime image is built directly from a digest-pinned Alpine base. Its PHP, nginx, and supporting packages are installed together instead of upgrading a complete runtime stack inherited from another image.

The workflows select each platform explicitly and scan the candidate by OCI index digest. This ensures the scan covers the same linux/amd64 and linux/arm64 image content that is promoted after the checks pass.

Image attestations

Candidate builds also generate an SPDX software bill of materials (SBOM) and maximum-mode SLSA provenance for each runtime platform. The SBOM inventories the operating-system and application packages in the image. Provenance records how the image was built and which inputs were used.

Both attestations are attached to the candidate image index. Publication stops unless the repository verifier finds an SBOM and maximum provenance for both linux/amd64 and linux/arm64.

Exceptions

Do not suppress a finding in a workflow flag. If a finding does not apply to Movary or is mitigated, propose a repository change containing the ignore entry and all of the following information:

  • advisory or CVE identifier;
  • affected component;
  • why the finding is not applicable, or how it is mitigated;
  • owner responsible for reviewing the exception;
  • link to the maintainer approval; and
  • expiry date.

An exception must be reviewed before it is used by a publication workflow and must be removed when it expires. Add VEX information only when a concrete finding has been shown not to affect the image. The repository intentionally contains no default or blanket exceptions.