feat: Add security-scan action #20
No reviewers
Labels
No labels
priority/P0
priority/P1
priority/P2
priority/P3
size/L
size/M
size/S
size/XL
size/XS
state/done
state/in-progress
state/in-review
state/needs-refinement
state/ready
type/bug
type/chore
type/feature
type/refactor
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
amtronics/platform-actions!20
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/security-scan"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Issue
Closes #19
Problem
No pipeline scans PRs for leaked secrets or vulnerable dependencies, and images ship unscanned. Vendor scanner wrappers are themselves a supply-chain risk (trivy's action and a release were compromised twice in 2026).
Solution
One composite action: gitleaks + osv-scanner + optional trivy image scan. Report-only by default so a repo observes noise before gating; enforce mode fails on findings at or above the threshold. Binaries pinned by version and sha256 from official releases; a scanner error fails the job in every mode. README documents inputs and the canary rollout shape.
Review notes
Verify the three checksums against the upstream release checksum files. First consumer will be a canary repo PR (separate change) before any repo makes it a required check.
Risks and trade-offs
osv-scanner sends dependency names/versions to OSV.dev (documented); gitleaks and trivy run fully local. Report-only default means no protection until a repo opts into enforce — deliberate, to avoid drowning PRs day one.
WIP: feat: Add security-scan actionto feat: Add security-scan action