I’m planning to review the OpenSSF Best Practices document to see if there are any areas we can improve on as a project when it comes to security and development practices. If I do find something that I think needs improvement, I’ll send out an RFC / Pull Request for that specific item so we can discuss.
If this interests you at all and you want to help, please let me know.
This seems worth pursuing. I skimmed the document; much of it is general good software engineering practice, and some elements we could certainly do better on.
I’m happy to be part of the conversation but I don’t have a huge amount of time to devote to this.
Update: We now meet all the criteria for the passing level of the OpenSSF Best Practices!
We were already doing most of these things, but the two main changes we made to achieve this were adding release notes for our point releases, and adding a post-commit CI job that runs the static analyzer.
We also did some analysis on github to ensure we were meeting the requirements for bug acknowledgement and identified people in the community who are ‘security experts’.
The next level is ‘Silver’, and I’m going to start reviewing the criteria to see where we currently stand.
Thanks to everyone that helped participate in this!
Awesome Tom, thank you for driving this! Congratulations everyone for helping improve LLVM’s processes.
LLVM actually seems to be doing better than represented on the OpenSSF web page: The Analysis section says several times “We don’t currently use a static analysis tool” for criteria marked as “N/A,” while the first criterion says “We are running the clang static analyzer against our main branch one per day.”
The Dynamic Code Analysis subsection has most of its items marked as Unmet, with a repeated comment about fuzzing, even though three links in one Show Details subsubsection are to LLVM URLs for sanitizers.