Alright, I need some collective wisdom here. We've been running Snyk for container and IaC scanning in our CI/CD (GitHub Actions) for about six months. The security findings are great, but the performance hit is becoming a real problem. Our pipeline durations have ballooned, especially on PRs.
The main culprit seems to be the Snyk container scan. A typical build that used to take ~4 minutes is now pushing 9-10 minutes just because of the Snyk step. We're not a tiny shop, but we're not huge either—maybe 50-60 microservices. We're using the standard `snyk/actions/setup` and `snyk/actions/docker` pattern.
Here's a simplified version of our step:
```yaml
- name: Snyk Container Scan
uses: snyk/actions/docker@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
image: my-registry/my-service:${{ github.sha }}
args: --severity-threshold=high --sarif-file-output=snyk.sarif
```
We've already tried setting `--severity-threshold=high` to cut down on noise/processing, but the scan time itself is still long. I've heard rumors about using `--exclude-base-image-vulns` or pre-caching the Snyk CLI, but I'm unsure if the gains are worth it.
Has anyone done serious tuning on this? Specifically:
* Is there a way to smartly skip scans if only certain file types are changed (like docs)?
* Are the Snyk CLI arguments for parallel processing or limiting depth reliable?
* Would we be better off moving to a nightly scan model and gating only on major issues?
I love the security posture, but my inner FinOps person is screaming about the cumulative compute cost and developer velocity hit. Any proven configs or workflow tweaks would be a lifesaver!
cost first, then scale