Add Trivy vulnerability scanning for the Docker image

[vharseko]

Port of OpenIdentityPlatform/OpenDJ#854 — Docker image vulnerability scanning with Trivy, carrying the fixes from that PR's review (limit-severities-for-sarif, cache: false, no TRIVY_INSECURE, scanners: vuln, guarded uploads, unfixed CVEs reported for the published image).

build.yml — build-docker scans the freshly built image (resolved from the local Docker daemon, so the runner's linux/amd64 manifest only) right after the multi-server docker test. Findings do not fail the build: the SARIF report goes to code scanning via codeql-action/upload-sarif, so PRs get a "Code scanning results / trivy-build" check like CodeQL and the full list lives in the Security tab. Only fixable CRITICAL/HIGH CVEs are reported (ignore-unfixed: true plus limit-severities-for-sarif: true — without the latter the severity filter is silently dropped for SARIF output), and only the vulnerability scanner runs. The action's built-in ~1GB DB cache is disabled: the repo's actions cache is at 9.98 GiB of the 10 GB quota, with six ~690 MiB m2-repository entries the build-maven matrix depends on, and cache-trivy-* entries would LRU-evict them. The job gets security-events: write; SARIF upload also works for fork PRs on public repositories.

docker-scan.yml (new) — weekly cron (30 5 * * 1, CodeQL runs at 27 3) + workflow_dispatch scan of the published openidentityplatform/openam:latest: new CVEs surface in the already-released image (mostly via the tomcat:11-jre25 base) without any change in this repository. Unlike the build-time scan, unfixed CVEs are reported too. Category trivy-image-latest, distinct from trivy-build. The scheduled run is skipped in forks; manual runs are always allowed.

Differences from the OpenDJ version, by OpenAM's facts: one image (single Dockerfile, no alpine variant) so no matrix and one category each; image-ref reuses the existing OPENAM_IMAGE env; the ghcr.io copy of the same image is not scanned separately.

aquasecurity/trivy-action is pinned to ed142fd = v0.36.0 (resolved through the annotated tag; latest release), and the Dependabot github-actions config from #1134 will keep it current. Future accepted findings can be suppressed via a .trivyignore file in the repository root or dismissed in the Security tab.

Note: #1134 adds permissions: contents: read to the same build-docker job; whichever lands second gets a one-line conflict there (keep both contents: read and security-events: write).

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[maximthomas]

praise: The scan reports to code scanning without gating the build, and its filters hold.

• limit-severities-for-sarif: true works: the 16 Trivy alerts on refs/pull/1141/merge are 2 critical and 14 high, with none below.
• The upload is guarded with always() && hashFiles('trivy-results.sarif') != '', and aquasecurity/trivy-action is pinned to ed142fd with the version in a comment.
• The new build-docker permissions (contents: read, security-events: write) cover the whole job. It uses no token or secret other than the checkout and the SARIF upload, and push: true at :125 targets the local registry service.