What this prompt does
This prompt builds a comprehensive GitHub Actions security-scanning pipeline for a [language]/[framework] project. It layers secret scanning with [secret_scanner] to catch leaked keys and tokens, dependency vulnerability scanning with [dep_scanner], static analysis with [sast_tool], optional container image scanning, and license compliance checks. It uploads results as SARIF to the GitHub Security tab, posts PR comment summaries, and fails the build for issues at or above your [severity_threshold].
The structure works because a single leaked key in git history is an expensive lesson, so the pipeline defends in depth rather than relying on one check. By combining secret scanning, dependency audits, and SAST with SARIF upload, findings land in the GitHub Security tab where they are visible and trackable. The blocking rule on [severity_threshold] and a [max_time] caching budget make the pipeline strict without becoming so slow that the team routes around it. It also adds license compliance checking and optional container image scanning, so the security view extends from your own code to your dependencies and the images you ship. Posting a findings summary as a PR comment means a developer sees the relevant risk right where they introduced it, instead of having to go hunting through a separate dashboard after the fact.
When to use it
- You want leaked secrets caught on every push before they reach production.
- You need dependency vulnerabilities surfaced automatically via
[dep_scanner]. - You want SAST findings from
[sast_tool]integrated into your CI. - You need results in the GitHub Security tab through SARIF upload, not buried in logs.
- You want to block merges for
[severity_threshold]+ issues rather than relying on manual vigilance. - You are scanning containers or checking license compliance as part of the build.
Example output
Expect a complete workflow YAML with jobs for secret scanning via [secret_scanner], dependency scanning via [dep_scanner], SAST via [sast_tool], optional container image scanning, and license checks. It uploads SARIF to the Security tab, posts a findings summary as a PR comment, fails on [severity_threshold]+ severity, and uses caching to keep total scan time near your [max_time] budget.
Pro tips
- Set
[severity_threshold]deliberately; blocking on every low finding floods the team and trains them to ignore the gate, while only blocking criticals may let real risk through. - Tune caching toward your
[max_time]target, because a security pipeline that adds many minutes to every push gets disabled under pressure. - Match
[secret_scanner],[dep_scanner], and[sast_tool]to your stack so findings are relevant and false positives stay manageable. - Lean on the SARIF upload, since centralizing findings in the GitHub Security tab is what makes them trackable over time.
- Expect to triage false positives early; budget time to tune
[sast_tool]rules before enforcing hard blocks. - Iterate by reviewing the first runs' findings and adjusting the threshold and ignore rules before turning blocking fully on.
