TryQuiet / quiet

A private, p2p alternative to Slack and Discord built on Tor & IPFS
https://www.tryquiet.org
GNU General Public License v3.0
1.9k stars 79 forks source link

Implementing OpenSSF Scorecard #1732

Open UlisesGascon opened 10 months ago

UlisesGascon commented 10 months ago

Hi team! I think it would be beneficial for the project if we follow the recommendations from the OpenSSF Scorecard.

Context

Many projects are part of this initiative, such as Node.js, ipfs, and many more. Even if the project is not actively promoting the initiative, the Scorecard will index them once they reach a certain level of popularity.

If you are unfamiliar with the tool, here is some additional information:

Overall, the recommendations suggested in the scorecard are good for increasing security in Open Source projects (branch protection, pinning dependencies, tracking vulnerabilities, security policies...).

Next Steps

I will create some PRs that will help us speed up the scoring process, and I will also include a proper workflow for submitting the project scoring.

holmesworcester commented 10 months ago

This is great. Thank you!

I'm curious what steps you think we should take after this one, to protect against vulnerable dependencies and secure against supply chain attacks.

We're very aware that there's a lot more work to be done here, so I'm curious what you recommend.

UlisesGascon commented 10 months ago

I'm curious what steps you think we should take after this one, to protect against vulnerable dependencies and secure against supply chain attacks.

We're very aware that there's a lot more work to be done here, so I'm curious what you recommend.

Thanks for the feedback, @holmesworcester!

TL:DR;

While the Scorecard offers us many things and a way to monitor the evolution, for a long-term objective, we can try to achieve the CII Best Practices.

Basically, the idea is to sign up for the project and fill out the forms for the different levels (passing, silver, and gold). While this is a quite long process in terms of researching and checking that we have the best practices in place, it is a very systematic way to increase security in the community without feeling overwhelmed.

CII Implementation details

My advice is to generate a PR with the questionnaire in markdown format and open a discussion with the maintainers and contributors to review how much we have already achieved and what we can do in the short/long term. Node.js example for first level

Here are some questions from the first level, and potential answers:

The project MUST clearly identify small tasks that can be performed by new or casual contributors. (URL required)

I think this is achieved with the good first issues that we have in the repo :)

The project MUST require two-factor authentication (2FA) for developers to change a central repository or access sensitive data (such as private vulnerability reports). This 2FA mechanism MAY use mechanisms without cryptographic mechanisms such as SMS, though that is not recommended.

This can easily be set up in Github, while it might already be in place. It is not visible to our final users, but when we make this information public, we are much more transparent and trustworthy.

Examples

As a reference, The Linux Kernel is one of the few projects that have accomplished all three levels:

Even if you are not familiar with the project in depth, you can get a clear idea of the mechanisms and culture they have in place to make it more secure for us to use the Kernel :)

Another good example is LibreOffice, which is working to achieve the silver level now, so you can easily see what has been accomplished and what is missing.

Conclusion

I love to see the CII Best Practices as a compass to guide projects step by step to better security. What do you think... should we think in including this in the roadmap, at least for the first level?

holmesworcester commented 10 months ago

What do you think... should we think in including this in the roadmap, at least for the first level?

This makes sense to me, yes!