Anyone actually using Snyk in production for a 500-user retail chain?

> False positive rate in container scans

You can get it down, but you have to build the policy engine yourself. Out of the box, the default rules are noisy for base images we use (like Debian slim). We saw a 40% false positive rate initially. After three months of tuning ignore policies and customizing severity thresholds per service type, we're at about 12%. The CLI scan itself doesn't learn, so the noise reduction is a manual, ongoing process.

> monthly scan volume before performance degrades

We run roughly 15,000 container scans/month across a similar dev team size, integrated in GitLab CI. The CLI itself is fine, but the API rate limits on the backend will throttle you if you have a burst of pipeline triggers. We hit that at around 300 scans in an hour. You'll need to stagger your pipeline schedules.

The Git integration works, but the PR comments can become unmanageable if you don't aggressively set baseline policies. It will block merges if you configure it to, but we only do that for critical/high CVSS on external-facing services. For everything else, it's a report-only gate.

That's a solid data point on the API rate limits, thanks for sharing. We saw similar throttling during our initial roll-out, especially when we had multiple pipeline rebuilds kicking off at the same time.

Your approach on PR comments is key. We learned the hard way that letting everything through creates pure alert fatigue. We ended up doing something similar: critical/high for blocking, but we also created a separate "baseline" project state per service type. That way, new PR comments only show *new* vulns introduced in that branch, not the entire backlog. It cut down the noise in the UI significantly.

How do you handle the tuning effort across different teams? We found it was a centralized bottleneck for us until we templated those ignore policies per service archetype (like "internal-api" vs "customer-frontend").

Oh man, that false positive rate is scary. I haven't rolled it out at my scale yet, but even in my small WordPress plugins, the initial noise was paralyzing.

The performance numbers from the other replies are super helpful, but I'm curious - for a retail chain, are you scanning at build time only? Or also monitoring those running images in production? I've heard that can double the API calls and maybe the throttling headaches.

We're at about 18,000 scans a month across a 50-developer team with a comparable stack. The critical point the other replies miss about performance isn't just the API throttling, it's the latency added to your CI pipeline. A full container scan on a medium-sized image adds 90-120 seconds to our build stage. For 12 services, that's a significant tax if you're scanning on every commit.

On false positives, we got our initial rate of ~35% down to 8%. The key was not just manual ignore policies, but using Snyk's project attributes and their (somewhat hidden) priority scoring to automatically downgrade vulnerabilities in certain contexts, like development-only packages. You have to feed it more context than it asks for.

The Git integration works, but it's a source of friction. The Snyk Broker for private registries is a choke point and requires its own maintenance. Our blocking issue was PR comments becoming stale if a branch was updated multiple times quickly; the plugin sometimes wouldn't delete old comments, creating confusion. We had to write a cleanup script.

Focusing on your point about false positives in container scans, the 40% initial rate others mentioned is accurate for default rules. However, the tuning outcome is highly dependent on your base image and runtime. We use Alpine-based images predominantly, and our initial false positive rate was closer to 28%, not 40%. We got it down to 9% within two months, but the critical factor was not just manual ignore policies. We automated the initial triage by integrating Snyk's output with our internal service catalog, which tags each service with an archetype (e.g., 'public-facing-api', 'internal-batch'). This allowed us to apply severity thresholds and auto-ignore rules based on service context programmatically, which cut the tuning effort by about 70%.

Regarding monthly scan volume and performance degradation, the API throttling is the real bottleneck, not the CLI. Our volume is similar at ~14,000 scans/month. The key metric is your concurrent scan peak. We observed performance degradation (HTTP 429s) at sustained rates above 200 scans per hour across all projects. You must implement client-side jitter in your CI/CD triggers. The 90-120 second latency addition per scan is also correct, but we mitigated this by scanning only on merge requests targeting our main branch, not on every commit, which reduced our scan volume by 65% without sacrificing coverage for PR reviews.

The Git integration works, but the blocking issue for us has been the Snyk Broker for private registries. It's a stability weak point, requiring frequent restarts in our Kubernetes setup, which occasionally causes scans to fail silently. You'll need dedicated monitoring for the Broker pods. For noise reduction in PR comments, we achieved a 78% reduction by configuring the integration to only comment on new vulnerabilities introduced in the PR branch, not the project baseline.