docs(readme): CII Best Practices badge 100% completion

[petermetz]

Checklist to resolve

• Refactor maintainer group into two separate groups one is maintainers as-is and another one for security admins (Peter volunteered for this)
• Dependabot alerts fixed (Peter volunteered for this)
• ci: add fuzzer tests for our APIs #495 Fuzzer test case for the API server and all the plugins (Dave is helping out with looking at options)
• Figure out why the LGTM.com tool is not firing for us despite being configured to do so (Ry volunteered to help)

---

Describe the bug

Depends on mergint the PR #338 which already takes care of the CII checklist item Release Notes (screenshot below)

We are not yet passing the CII Best Practices check (looks like from the TSC mailing list that we need 100%)
https://bestpractices.coreinfrastructure.org/en/projects/4089

To Reproduce

Visit the link or the project readme where the badge is at and observe <100% compliance.

Expected behavior

We should have 100% compliance on the badge.

Screenshots

Hyperledger Cactus release version or commit (git rev-parse --short HEAD):

v0.2.0

cc: @sfuji822 @takeutak @jonathan-m-hamilton @dhuseby @dcmiddle

[dcmiddle]

Thanks for the ping @petermetz
If you have any reactions to the badge process feel free to drop them here. For example, question xx was not relevant or if not for xx we wouldn't have realized this was a best practice. Overall the process was helpful or bureaucratic or something else.

[petermetz]

Thanks for the ping @petermetz
If you have any reactions to the badge process feel free to drop them here. For example, question xx was not relevant or if not for xx we wouldn't have realized this was a best practice. Overall the process was helpful or bureaucratic or something else.

@dcmiddle Overall the process was useful IMO. It wasn't very fun of course to grind through the questions, but I don't see how that could be improved.
There were questions that I marked as not relevant, but I would actually advocate to keep all of those as well (as long as there is an option to say that it's not relevant). Here's why: It forces people to think it through at least once (at least that's what it did for me).
A great example is the memory safety questions which someone working on a NodeJS project could just hand-wave at, but if they use native C/C++ addons then suddenly it is relevant and needs attention from the maintainers.

---

Future improvement idea that's not really tied to any specific question:

A sort-of meta-metric that shows a number of a peer reviews (and the reviewer's name if they choose to publish it) from others similar how people can peer review and sign off on a research paper.

Why? There's a big difference between me clicking through a questionnaire and saying 'yeah sure' to everything (the urge is always high to call one's own baby beautiful) and 5 other people also being in agreement with all my self reported answers.
The free-form explanation input fields we have for all the answers is a good start IMO, but it could be taken to the next level with the peer review mechanism described above where people could be like: "I clicked on the link you said would work for reporting vulnerabilities, but it went to HTTP 404 so thumbs down on this".

---

Another meta-metric suggestion would be to have the form show if the answers were regularly updated or not (every six months or a year maybe for a recommended period?).

Why? Maybe this month I have no code with manual memory management in the repo, but next week someone adds some inline assembly or whatever else as a performance optimization and now suddenly it's relevant and we need to take care of it according to the CII badge questions.

[dcmiddle]

Very helpful feedback. Thanks @petermetz!

[petermetz]

From https://github.blog/2022-08-15-the-next-step-for-lgtm-com-github-code-scanning/

Three years ago, the team that built LGTM.com joined GitHub. From that moment on, we have worked tirelessly to natively integrate its underlying CodeQL analysis technology into GitHub. In 2020, GitHub code scanning was launched in public beta, and later that year it became generally available for everyone. GitHub code scanning is powered by the very same analysis engine: CodeQL.

We’ve since continued to invest in CodeQL and GitHub code scanning. Today, GitHub code scanning has all of LGTM.com’s key features—and more! The time has therefore come to announce the plan for the gradual deprecation of LGTM.com.
End of August 2022: no more user sign-ups and new repositories

TLDR: lgtm.com is gone, the new version of it is CodeQL which we've had for years, so we can consider this task finished as such.