Enable OpenSSF Scorecard Github Action and Badge

[joycebrum]

Signed-off-by: Joyce Brum joycebrum@google.com
CC @XhmikosR

Description

• Scorecards.yml file enables the Scorecard action to run on push to main and once a week (important for some checks like contribution check)
• Readme file with badge from shields.io

Any doubts or concerns please let me know.

Motivation & Context

Closes #37343

It enables the OpenSSF Scorecard Github Action and Badge to help you to ensure the project will continue to follow the open source best practices or even improve any possible practice to avoid security risks and vulnerabilities.

Type of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would change existing functionality)

Checklist

• I have read the contributing guidelines
• My code follows the code style of the project (using npm run lint)
• My change introduces changes to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

Live previews

https://github.com/joycebrum/bootstrap#status

Related issues

#37343

[XhmikosR]

@mdo: What's your take on this?

I removed the link since there isn't a human readable page to link to.

Overall, the checks are OK, I mostly disagree with the Actions pinning for the reasons I mentioned above. The other things are generally considered good practices.

That being said, 7.2 is not good enough either and it's mostly caused by Actions not being pinned AFAICT.

[XhmikosR]

BTW, maybe we could link to https://bestpractices.coreinfrastructure.org/en/projects/2930 and add the best practices badge? It seems @bardiharborow set this up, not sure how to get updated results or access ourselves.

[joycebrum]

About wheter the Pinned-Dependencies has a big weight in the current score, I've made some calculations:

“Critical” risk checks are weighted at 10
“High” risk checks are weighted at 7.5
“Medium” risk checks are weighted at 5
“Low” risk checks are weighted at 2.5
This we would have:

( 10 * (Dangerous-Workflow) + 7.5 * (Binary-Artifacts + Branch-Protection + Code-Review + Dependency-Update-Tool + Maintained + Signed-Releases + Token-Permissions + Vulnerabilities) + 5 * (Fuzzing + Pinned-Dependencies + Packaging + SAST + Security-Policy) + 2.5 * (CI-Tests + CII-Best-Practices + Contributors + License) ) / (10 + 60 + 20 + 10)

Then, considering the current score:

$$ (100 + 7.5*(10 + 8 + 9 + 10 + 10 + 0 + 0 + 10) + 60 + 75) + 5 * (0 + 7 + 10 + 10) + 2.5 * (10 + 2 + 10 + 10)) / 100 $$

$$ (100 + 7.5 * 57 + 5 * 27 + 2.5 * 32 ) /100 = 7.4 $$

Even if the Pinned Dependencies was a 10, the score would only go to 7.6.

According this, the best approach would be:

1. Signed-Releases
2. Token-Permissions (Quick-win)
3. Fuzzing
4. CII-Best-Practices

Working only to get this four to 10 would increase the score to 9.6

[bardiharborow]

@XhmikosR it says that everyone with commit access to the repository should have access already, but if not, I can manually add user IDs to the access list.

[XhmikosR]

I'm going to give this a go and we revert it if we don't like it later.