chore: standardize security workflows to use org-level reusable workflows

[cfdude]

Summary

• Replaces inline security scan definitions with thin callers that delegate to org-level reusable workflows in cfdude/.github
• Standardizes security.yml to use security-trivy.yml@main and security-semgrep.yml@main from the org workflow library

Changes

• .github/workflows/security.yml — replaced with standard thin-caller pattern

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

[claude]

PR Review: Standardize security workflows to org-level reusable workflows

Overall this is a clean, well-structured change that follows the thin-caller pattern correctly. A few items worth addressing before considering this fully hardened.

---

Strengths

• DRY principle applied well — delegating to org-level reusable workflows is the right pattern for standardizing CI/CD across repos
• Per-job permissions — moving permissions from the top-level to per-job scope is a security improvement (principle of least privilege)
• Scheduled scan added — the weekly cron 0 6 * * 1 is good practice for catching newly disclosed CVEs between pushes
• Commit message format follows the chore(<scope>): <subject> convention from CONTRIBUTING.md

---

Issues to Address

Security — Supply Chain Risk (Medium)

Both called workflows are pinned to @main. This means any change pushed to cfdude/.github immediately affects this repo without a PR or review here. If the org workflow repo were ever compromised or accidentally broken, it would silently affect all callers.

Recommendation: Pin to a specific commit SHA or version tag instead of @main.

Potential Coverage Gap — Secret Scanning (Medium)

The original workflow included gitleaks for secret detection. The replacement uses Trivy and Semgrep. Trivy's primary focus is container images and filesystem CVEs, not secret scanning. Semgrep can detect some credential patterns with the right ruleset.

Question: Does security-trivy.yml run in filesystem mode with secret detection enabled? If gitleaks functionality is not replicated in the org workflows, there is a regression in secret scanning coverage.

dev Branch Removed from Triggers (Low)

The original workflow ran on branches: [main, dev]; the new one only targets main. If dev is still an active branch where feature work accumulates before merging, security scans will no longer run there. Worth confirming dev is no longer used, or that this is an intentional tradeoff.

secrets Inheritance Not Specified (Low)

Semgrep managed scanning typically requires a SEMGREP_APP_TOKEN. If security-semgrep.yml expects secrets, the caller needs secrets: inherit added to the job. Without it, secrets from this repo won't be passed to the called workflow — this may be a silent failure depending on how the org workflow handles a missing token.

---

Summary

Item	Assessment
Approach	Correct — thin-caller pattern is idiomatic
Permissions	Improved (per-job scoping)
Supply chain risk	@main ref should be pinned to SHA
Secret scanning	Verify Trivy/Semgrep cover gitleaks gap
Branch coverage	Confirm dev removal is intentional
Secrets passing	Check if secrets: inherit is needed

The structural direction is right. The main ask would be to either pin the workflow refs to specific SHAs, or document that the org workflows have a release/tagging strategy that makes @main safe.