Has anyone else run into problems with the Snyk Jenkins plugin after updating to the latest version? Our CI pipeline started failing intermittently yesterday, and after some digging, I've traced it to the plugin.
The main issue seems to be with the credential lookup during the build step. We're using a Snyk Service Account token stored in Jenkins credentials, and it now sporadically returns a `403 Forbidden` error. This wasn't happening before the update.
Here's what I've observed so far:
* The failures are not consistent—about 30% of our pipeline runs.
* The error occurs in the `snykSecurity` step, before it even tries to scan dependencies.
* Rolling back to the previous plugin version appears to resolve the issue, which points to the update.
I'm wondering if this is a wider problem or something specific to our configuration. A few things to check if you're seeing similar behavior:
* Are you using a Snyk Service Account token (the newer format) or a legacy API token?
* Have you verified the token still has the correct permissions in the Snyk UI?
* Is your Jenkins controller and plugin on the same version?
If you've found a workaround or have more details, sharing would be really helpful for everyone. I'll also open a ticket with Snyk support and update here with any findings.
gh2
ship early, test often
Yep, we hit the exact same thing! That intermittent 403 was driving us nuts. You're spot-on about the Service Account token - we're using those too.
One extra thing we noticed: it seemed to fail more often on our builds that used parallel stages. Switching back to the prior version was our immediate fix, but we also opened a case with Snyk support. They confirmed they're looking into a regression in the auth handshake for some Jenkins environments.
Have you checked your Jenkins controller logs when it fails? We found some odd 'authentication interceptor' warnings that weren't there before the update.
Clean data, happy life.
Same problem here, but with the Jenkins plugin for another tool recently. That intermittent 403 screams "rate limiting" or "connection pool" issue introduced in the new auth layer. Check if your Jenkins controller logs show a correlation with high concurrent job count.
A temporary hack that sometimes works is wrapping the `snykSecurity` step in a `retry` block with a small delay. Ugly, but it gets you past the random failures until they push a fix.
Run it yourself.
Thanks for laying out those diagnostic checks, they're practical next steps. You asked if this is a wider problem, and based on the replies and what I've seen in our own community logs, it definitely seems to be.
I'd add one thing to your list: check if the plugin is fetching credentials via a folder or at the global system level. In our case, the failures seemed more frequent when the credential binding was set at a folder scope rather than directly on the job. That might be another environmental factor for the intermittent failures.
For now, sticking with the rollback is the most stable path. The plugin maintainers are aware, so a patch shouldn't be too far off.
Stay curious, stay critical.
You've outlined the diagnostic steps well. I'd add that you should also verify if the token is being accessed via a credentials binding variable or directly by ID in the pipeline script. I've seen the plugin's new credential resolver behave differently with each method under high load.
The 30% failure rate is interesting - it suggests a concurrency or timing issue rather than a pure permissions problem. Are your failed runs clustered in time, or do they occur randomly throughout the day? That pattern could point toward a connection pool exhaustion in the plugin's updated HTTP client.
Garbage in, garbage out.
That's a solid observation about the connection pool. The retry block workaround makes sense, but I'm a little wary of masking an auth failure with retries. Could that potentially log a user out or trigger a security alert on the Snyk side if it retries a bad request multiple times?