Anyone else having issues with Snyk's Jenkins plugin after the last update?

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.

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.

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.

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.

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?

That's a good diagnostic list to start with. I'm seeing the same issue, and your note about verifying token permissions in the Snyk UI made me check something. Did you confirm the token's organization context? We found our service account token was tied to a specific org, and the failures seemed to map to builds for projects under a different org we'd recently added. Maybe the plugin's new credential fetch is stricter about that scope.

That's a plausible angle. The plugin shouldn't be silently switching org context based on the project, but a stricter scope check could explain the intermittent 403 if the credential fetch is now hitting a different API endpoint first.

Check if your token has multi-org access in Snyk. A service account token scoped to OrgA will always 403 for a project under OrgB, regardless of plugin version. The update might just be making the failed request faster.

Yeah, we got hit with that 403 thing too right after the update. Rolling back fixed it for us as well.

The part about it happening *before* the scan is what got me thinking. Could the plugin be doing some pre-flight check now that's hitting a different API endpoint? Maybe that new endpoint has stricter rate limits or something.

We're also using a service account token. Haven't checked if the failures cluster in time, that's a good idea. I'll look at our logs today.

The pre-flight check theory is interesting, but I'm more inclined to think it's just bad error handling. A 403 should be a clear permissions failure, not a symptom of rate limiting on a new endpoint. If it were a rate limit, you'd typically see a 429.

That said, you're onto something with the timing. If the failures cluster, it points to something external like a cache or a downstream service, not the token itself. The logs are your best bet to see if those pre-flight calls are even happening.

I've been following this thread closely since we use the same plugin in our manufacturing pipeline. You mentioned verifying the token still has the correct permissions in the Snyk UI, and I'm wondering if you've also checked whether the service account's organization membership has changed recently? We had a similar intermittent 403 issue last quarter, not with the plugin but with a direct API integration, and it turned out the service account had been removed from a project team in Snyk, which didn't revoke the token but did cause sporadic authorization failures on specific resources.

The 30% failure rate you're seeing is particularly concerning because it suggests a stateful condition. Have you noticed if the failures happen more on the first build after a period of inactivity, or perhaps after a credential rotation elsewhere in Jenkins? That could point to a caching issue in the plugin's new credential layer.

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.

You nailed the exact issue we're seeing too, right down to the 403 appearing before any scanning starts. I think you're spot-on that it's something about credential lookup in the new version.

Your checklist is solid, especially verifying the token permissions in the UI. I'd add one more thing to check: the credential's actual ID string in Jenkins. We found our credential ID had a space in it, and while it worked fine before, the latest plugin seems to handle the URL encoding for that ID differently when it makes its internal API call, which could explain the sporadic 403s. Renaming the credential to use hyphens seemed to reduce the failure rate for us, though we also rolled back eventually.

The intermittency is the real head-scratcher. It's like the plugin is sometimes using a cached credential path and sometimes trying to fetch it fresh, and the fresh fetch has a new bug.

"Wider problem" is putting it mildly. Your 30% failure rate is the classic symptom of a regression that didn't get enough soak time.

You're right to focus on the credential lookup, but rolling back is just hiding the underlying issue. That token's permissions and scope are probably fine. The problem is likely how the new plugin version handles the Jenkins credential provider API under concurrent load. I've seen this before with other plugins that "improved" their credential fetching. It starts making blocking calls that timeout or fail silently, then defaults to a bad state and throws a 403.

Check your Jenkins controller logs for credential-related warnings around the time of the failures. You'll probably see a pattern of timeouts or null returns from the credentials API that the plugin now interprets as an auth failure.

The fact it happens before the scan is the real clue. It's not a Snyk API problem, it's a Jenkins plugin infrastructure problem.

Yep, that 30% failure rate is the exact pattern we're seeing, and it's driving our team nuts. Your diagnostic about it happening in the `snykSecurity` step before scanning is spot-on.

You asked about token types. We're also on a Service Account token, and like you, we verified permissions are intact. The weird part for us? The failures seem tied to specific Jenkins *agents*, not projects or times. If a build lands on agent-03, it almost always fails with the 403. On any other agent, it sails through. This makes me think the plugin's new credential fetch might have a race condition or a bad caching mechanism that gets into a weird state per executor.

Maybe check if your failures correlate to a particular node? It could be another environmental clue while we're all stuck rolling back.