Anyone using Semgrep with GitHub Actions? Issues to expect

Having recently completed a migration of our static analysis pipeline to exclusively use Semgrep with GitHub Actions, I've documented several operational nuances that aren't immediately apparent from the official documentation. The integration is robust, but there are specific failure modes and performance considerations that can significantly impact developer velocity and CI/CD reliability.

The primary architectural decision revolves around where to execute the scans. While the `semgrep/ci` action is convenient, we found it imperative to manage the Semgrep version and rule sets explicitly to ensure deterministic outcomes across thousands of workflow runs. A pattern we settled on looks like this:

```yaml
- name: Semgrep Scan
uses: docker://returntocorp/semgrep:latest
with:
args: semgrep ci --config=p/security-audit --config=r/dockerfile --sarif --output=semgrep-results.sarif
env:
SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}
```

Key issues we encountered and mitigated:

* **Cache Invalidation and Performance:** The default caching behavior of the action can lead to stale rule sets if your internal rules are updated frequently. We implemented a secondary cache key derived from the hash of our custom rule files.
* **Output Handling for SARIF:** Integrating with GitHub Code Scanning requires precise SARIF output path configuration. We observed that parallel job execution sometimes led to file write contention; the solution was to use a unique output file per job and a subsequent merge step.
* **Noise Reduction and Triage:** The volume of findings, especially from public rule packs (`p/`), can be overwhelming. We enforce a strict baseline workflow where new findings fail the build, but only after a curation period where findings are suppressed in a committed `semgrep.yml` baseline file. This requires disciplined SCM hygiene.
* **Resource Exhaustion on Large Monorepos:** The default memory allocation for the GitHub Actions runner can be insufficient for scanning large codebases, leading to OOM kills. We now use the `--max-memory` flag and strategically split scans by language or directory, using a matrix strategy.
* **Secret Detection False Positives:** While useful, the secret detection patterns generate a high rate of false positives in development environments. We had to create targeted path exclusions for directories containing test fixtures or synthetic data.

A secondary, but critical, consideration is the management of the `SEMGREP_APP_TOKEN`. Its presence enables PR comments and centralized finding tracking, but it also introduces a dependency on Semgrep's SaaS availability. For our tier-1 services, we run a dual-path workflow: one with the token for visibility, and a separate, required "offline" scan that uses only locally defined rules and fails the check independently of external service health.

The overall reliability of the integration is high, but it demands a similar rigor to application SLOs: you must define what "green" means (e.g., zero new high-severity findings, all existing findings baselined), instrument the scan duration and failure rates, and ensure the feedback loop to developers is fast and actionable. Without this, it risks becoming just another flaky check that is eventually ignored.