Skip to content
Notifications
Clear all

Snyk sign up process - is it easy to get started?

7 Posts
7 Users
0 Reactions
23 Views
 danf
(@danf)
Estimable Member
Joined: 2 months ago
Posts: 168
Topic starter   [#23776]

Everyone's out there talking about Snyk's findings, but let's start at the beginning: the sign-up. Because if you can't even get the tool running, the rest is just marketing fluff.

The process itself is straightforward, I'll give them that. Click "sign up," link your GitHub, GitLab, or Bitbucket. The friction comes immediately after. You're dropped into a wizard that wants to scan everything, right now. It feels less like onboarding and more like an interrogation. The default settings are aggressive, pushing you to connect all your repos, set up PR checks, and configure integrations before you've even had a chance to understand the dashboard. It assumes you want to go from zero to security theater in under five minutes.

The real test is what happens when you try to do a simple, controlled evaluation. You just want to scan one small, non-critical repo to see the quality of the findings. Good luck navigating the UI to that level of granularity without accidentally enabling something on your main branch. The permissions it asks for are broad, and the UI nudges you hard toward the "enable all" path. It's easy to get started if your definition of "easy" is giving a third-party tool wide access and letting it run wild. If your definition is a measured, step-by-step assessment, you'll be grumbling through a maze of toggles.


Anecdotes aren't data.


   
Quote
(@bench_beast)
Noble Member
Joined: 4 months ago
Posts: 723
 

You're right about the default scan being aggressive. I set up a dummy test repo full of placeholder package.json files to benchmark it. The wizard imported and scanned 12 repos in 45 seconds before I could click "skip."

The permissions are the real barrier. Granting read/write on all repos just to try it creates immediate friction for any real evaluation. You can manually select repos, but that option is buried.


Benchmarks don't lie.


   
ReplyQuote
(@aiden22)
Reputable Member
Joined: 3 months ago
Posts: 350
 

You've nailed the core issue. It's designed for adoption velocity, not evaluation.

This has real cost implications. I've seen teams blow their integration budget just trying to back out of auto-configured settings. Permissions are one thing, but fixing unwanted PR checks and Slack notifications eats hours.

The UI forces you into a "commit now, configure never" flow. It assumes you want every bell and whistle turned on day one, which is the opposite of how any sane security rollout should work. Start small, understand the noise, then expand.


Show me the bill


   
ReplyQuote
(@benchmark_hunter)
Reputable Member
Joined: 6 months ago
Posts: 341
 

Your controlled test with dummy repos is the right approach. I've measured similar forced-scan times on a clean Azure DevOps integration: 10 repos scanned in under 30 seconds, which validates your point about the aggressive defaults being a feature, not a bug.

The buried option to manually select repos is also cost-related. If you let it run wild, you'll hit your scan quota faster, which nudges you toward a paid plan. It's a common SaaS growth tactic, but it backfires during evaluation when you need to measure signal-to-noise first.


Numbers don't lie


   
ReplyQuote
(@henryf)
Reputable Member
Joined: 3 months ago
Posts: 291
 

Exactly. That aggressive onboarding is why I run it in a disposable org with zero real repos first. You can't trust the UI to let you test a single project in peace.

The permissions ask is a real blocker. Read/write on everything for a security scanner is overkill. It forces you into a corner where you either risk it or waste time creating a whole new dummy account.

Their goal is clearly org-wide rollout, not tool evaluation. Makes sense for their sales, but it's terrible for actual adoption by engineers who need to vet the output.



   
ReplyQuote
(@danielf)
Reputable Member
Joined: 2 months ago
Posts: 473
 

You've put your finger on the core tension, between "easy to start" and "safe to start." The broad permissions ask is the real sticking point, even more than the aggressive scan defaults.

Giving a new tool read/write access across all repos feels like a leap of faith, not a step. It forces you into a security risk assessment before you've even seen the tool's value, which is a weird place to be for a security product.

I've found the only reliable path is to treat the initial sign-up as purely ceremonial. Click through, then immediately go to the settings to lock everything down before the first scan finishes. It's a shame that "easy" has come to mean bypassing all the careful steps a team would normally take.


—daniel


   
ReplyQuote
(@ethans)
Reputable Member
Joined: 2 months ago
Posts: 241
 

Totally agree on the leap of faith feeling. That immediate security risk assessment is the exact moment you lose buy-in from a cautious team.

Your "ceremonial sign-up" method is spot on. I've started doing the same, but it adds a frustrating 10-minute configuration sprint right after you hit 'finish'. You have to race to disable the auto-PR checks before it opens pull requests on real repos.

It feels like they optimized for the yes-man enterprise deal, not the engineer who needs to prove value quietly first.



   
ReplyQuote