fix(ci): scan pull-request heads with Trivy

.github/workflows/trivy.yml

@@ -5,10 +5,18 @@ on:
     branches:
       - develop
       - main
+  pull_request:
+    branches:
+      - develop
+      - main
 
 permissions:
   contents: read
 
+concurrency:
+  group: trivy-${{ github.repository }}-${{ github.event.pull_request.number || github.ref }}
+  cancel-in-progress: true
+
 env:
   GIT_CONFIG_COUNT: "1"
   GIT_CONFIG_KEY_0: init.defaultBranch
@@ -23,6 +31,8 @@ jobs:
       security-events: write
     steps:
       - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          persist-credentials: false
       - name: Run Trivy filesystem scan summary
         uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0; SHA pinning retained as supply-chain attack mitigation, do not replace with tag.
         with:

CHANGELOG.md

@@ -14,6 +14,9 @@
 
 ### Fixed
 
+- Run the pinned Trivy filesystem/SARIF scan on pull-request heads targeting `develop` or `main`, so GitHub code scanning can compare the PR configuration instead of reporting the protected-branch Trivy configuration as missing.
+- Hardened the Trivy policy regression so ordinary `pull_request` coverage for `develop` and `main` is structurally required and `pull_request_target` is rejected, while CodeQL and OSSF Scorecard remain push-only repository-local signals.
+- Reject restrictive Trivy `pull_request.types` filters unless they preserve `opened`, `synchronize`, and `reopened`, so every newly opened, updated, or reopened PR head remains eligible for current-head SARIF evidence.
 - Upgraded the local score PDF parser to `pdfjs-dist` 6.2.108, pinned Undici 7.29.0 across the workspace, and constrained PDF loading to copied in-memory bytes with a same-origin bundled worker and npm-generated lock provenance.
 
 ## [0.1.3] - 2026-04-29