"safety scan" requires an account and authentication

[andy-maier]

Checklist

• [X] I agree to the terms within the Safety Code of Conduct.

Safety version

3.2.14

Python version

3.12.7

Operating System

macOS 14.7.2

Describe the problem you'd like to have solved

It seems that the new "safety scan" command requires to create an account and particularly to log in to the account when running it.

I find this unacceptable for a tool that claims to be free for the open source community.

In addition, it is not clear what data is sent by the "safety scan" command to the safety site through the account.

Third, this approach can create issues when people move on from an open source project but own a personal safety account that is used for that project, and forgotten to be transferred.

Describe the ideal solution

"safety scan" does not require an account.

Alternatives and current workarounds

Workaround for us is to stick with the "safety check" command.

Additional context

No response

What I Did

$ safety scan --policy-file .safety-policy-develop.yml -r minimum-constraints-develop.txt

Please login or register Safety CLI (free forever) to scan and secure your projects with Safety

(R)egister for a free account in 30 seconds, or (L)ogin with an existing account to continue (R/L): 

[github-actions[bot]]

Hi @andy-maier, thank you for opening this issue!

We appreciate your effort in reporting this. Our team will review it and get back to you soon. If you have any additional details or updates, feel free to add them to this issue.

Note: If this is a serious security issue that could impact the security of Safety CLI users, please email [email protected] immediately.

Thank you for contributing to Safety CLI!

[j-adamczyk]

+1, we used safety check pre-commit hook, and switched to pip-audit due to this change. Using an account is unacceptable for us, particularly for CI workflow. Also, requiring login is very much not open source.

[nickste]

@andy-maier and @j-adamczyk we appreciate your feedback on this and understand your concerns. I'm working through some ideas on how we can best address this, and would really value being able to discuss this with you over a call. If you're willing to do so, please email me on [email protected].

[Alex-ley-scrub]

+2

+1, we used safety check pre-commit hook, and switched to pip-audit due to this change. Using an account is unacceptable for us, particularly for CI workflow. Also, requiring login is very much not open source.

Thanks for pointing me to pip-audit @j-adamczyk

[geertjanvdenbosch]

@nickste Any update on this issue?

[tony-nguyen-lb]

This is still an issue using safety scan which required login. Any help?

[mdabrowski1990]

I resign from using safety cause of that change.

As far as I understand that open-source providers want to be paid and this is the reason behind logging. I do not think that is fair for other open-source creators (like myself) to use logging nor the way to make it effective.

1. You do not need that (proper license is enough to enforce paid license on commercial users (yes, you cannot check whether everyone respects that, but in relatively fair society some people would report missuses for you) .
2. It's BS, cause why would you need an account for something like dependency checking?
3. I am just disappointed, cause you moved from static and safe solution where privacy is respected to cloud handled scanning where only god knows what and how you are checking/handling collected data.

My reaction:

[nickste]

Hi folks - my apologies for missing this thread until now. I want to start by assuring you that we intend to allow free use of Safety. To be more specific, we want to deliver the following:

1. Open-source projects should be able to use Safety for free, with our full vulnerability database (not the delayed/limited data). 1.1 Contributors shouldn’t need to each sign up for a Safety account in order for Safety to work - instead the project should use Github auth to sign up to Safety once, install Safety as an action, and then allow contributors to push commits that are scanned by Safety.
2. Any user should be able to use Safety for free, with our free data (delayed/non-proprietary vulnerabilities).

We recognize that this makes life more difficult for open-source projects today, because it often requires each contributor to sign up to Safety. We’ll fix this via # 1.1 above.

I wrote more about our longer-term vision for Safety here. We want to offer much of this protection for free to open-source projects (not just the vulnerability scanning). I know we’re taking longer than we’d like to deliver on this, but we will get there. If this is a blocker for you, you can still use safety check that doesn't require an account.

If you have concerns with the approach, please let me know - we value the feedback and are open to changing our minds where it makes sense.

[sTiKyt]

No, thanks, I think we need a fork of this without all the bullshit, because this isn't just "inconvenient", this is sick to do to a project many people already depend on

Does anyone know good FOSS alternatives to this corporate attempt at building a lead-generation/data-harvesting scheme, stealing our data and breaking our trust?

[sTiKyt]

+1, we used safety check pre-commit hook, and switched to pip-audit due to this change. Using an account is unacceptable for us, particularly for CI workflow. Also, requiring login is very much not open source.

Big thanks for pip-audit, after looking into it, seems to be exactly what I want, I'll be switching to that

[nickste]

@sTiKyt do you have any suggestions for how you'd like to see us handle this? We're trying to balance the following:

1. We want folks who use Safety for the first time to get our full vulnerability database (with all our proprietary vulns many of which don't have CVEs) to properly evaluate our offering.
2. We can't give away all of our vulnerabilities for free forever, because that removes any incentive for anyone to pay for Safety, which in turn reduces our ability to discover novel vulnerabilities.
3. But we also want Safety to be free for individual developers and open-source projects.

Our perspective was that asking for account creation, so we can differentiate usage when someone is clearly using us for an Enterprise use case, would be a good way to handle this. But we received feedback that this requirement makes it difficult for open-source projects that have many contributors, where it's frustrating to have to have each contributor sign up for an account. We agree, and that's why we're planning on building a Github integration that will handle auth at the Github repo level so that free open-source projects can be scanned without each contributor needing an account.

We're open to constructive feedback on how we can do better here? Have we missed something? Is there a different approach that would still allow us to balance 1 - 3 above?

[sTiKyt]

@sTiKyt do you have any suggestions for how you'd like to see us handle this? We're trying to balance the following:

1. We want folks who use Safety for the first time to get our full vulnerability database (with all our proprietary vulns many of which don't have CVEs) to properly evaluate our offering.
2. We can't give away all of our vulnerabilities for free forever, because that removes any incentive for anyone to pay for Safety, which in turn reduces our ability to discover novel vulnerabilities.
3. But we also want Safety to be free for individual developers and open-source projects.

Our perspective was that asking for account creation, so we can differentiate usage when someone is clearly using us for an Enterprise use case, would be a good way to handle this. But we received feedback that this requirement makes it difficult for open-source projects that have many contributors, where it's frustrating to have to have each contributor sign up for an account. We agree, and that's why we're planning on building a Github integration that will handle auth at the Github repo level so that free open-source projects can be scanned without each contributor needing an account.

We're open to constructive feedback on how we can do better here? Have we missed something? Is there a different approach that would still allow us to balance 1 - 3 above?

Imo the only acceptable approach would be to offer a parameter or mode that works entirely without accounts or telemetry. This could simply limit the tool to using only public vulnerability sources, explicitly excluding your proprietary data.

That way, people like me - who don't want fingerprinting, tracking, or vendor lock-in - can still use Safety in our pipelines for basic hygiene, while accepting the tradeoff of not getting access to your premium vulnerability data.

Otherwise, I see no reason to use Safety, either for my personal projects or professionally. Being held hostage behind accounts, telemetry, and forced integrations isn't something the OSS community appreciates. Tools should be possible to run locally, with clear limitations if needed, but without unnecessary hoops or vendor ties.

This model already exists elsewhere, many tools already follow this principle. If Safety can't, then it simply isn't viable for OSS use, regardless of intent.