Rollout scorecards across more repos

[planetf1]

Following the addition of scorecards to liboqs (pending some final doc updates) we should roll-out to other relevant repositories within oqs.

For oqs - especially as it's the most active repo - we decided to not just add the scorecard generation, but also address the findings.

For rollout, there is ongoing discussion about which repos are production/supported. One option is to at least add scorecard generation to them all. Including publishing. It is just a data point. So merge the capture. Then, how we prioritize any fixes is another matter.

Proposed list (will update based on comments)

• Scorecard for liboqs (until merged)
• Scorecard for oqs-provider
• Scorecard for liboqs-rust
• Scorecard for ci-containers
• Scorecard for liboqs-cpp
• Scorecard for liboqs-go
• Scorecard for liboqs-python

I've not included docs, demos, dotnet, java, libssh, profiling for now as these are stale or less relevant. demos is worth a discussion ,but as it's an aggregate set of contributions I'd skip for now. I did include ci-containers as it's part of our build pipeline.

I'm happy to work through these if there's consensus - specifically on the scan/pr/merge. mitigations later.

An extra task

• Add more docs on scorecard to www

[ryjones]

I can add the bugs for those repos if you like. they will return blank for now.

[planetf1]

@ryjones is that change to get the placeholders in the dashboard?

[ryjones]

yes. Take a look, I also removed the archived project and split the list up a little.

[baentsch]

It is just a data point. So merge the capture.

I could not disagree more: Publishing (bad) security scan results for a security project is about the most severe PR mistake one can make for a project aiming for public uptake...

how we prioritize any fixes is another matter.

...not having a plan in place (how, by whom, by when) to mitigate them is even worse, though :-(

[planetf1]

To some extent even running the scorecard analysis (and publishing) is the first step of our plan. The absence of such a report is perhaps indicative in any case of issues?

There are multiple routes to the same result though, so if consensus is to address the issues in the same PR, I'm ok with that too.

Or we can add a web page explaining our strategy & then do the run/merge+publish/fix sequence

We can discuss in next TSC - but this doesn't stop me starting on PRs (workload does - will start asap, hopefully in coming week)- we can hold off on any merges until/if we have the tsc discussion. Or once there's a clean run.