Add OSSF Scorecard workflow

[niStee]

• Add OSSF Scorecard workflow running on PRs to main, weekly (Mon 03:30 UTC), and branch protection rule.
• Minimal permissions: contents: read, security-events: write, id-token: write.
• Steps: checkout, run ossf/[email protected], upload SARIF to Code Scanning, and attach results as an artifact.
• Actions are tag-pinned; Renovate will handle digest pinning if configured (Add conservative Renovate configuration with gated majors #5116).

---

Testing/impact: Workflow-only change; no runtime code touched.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[arielj]

what is this OSSF scorecard? how would it help the project?

I'd rather see the results of this OSSF scorecard over time first to understand what it's reporting before adding it as a workflow

I see it's meant to run these checks https://github.com/ossf/scorecard?tab=readme-ov-file#scorecard-checks, are we currently doing things wrong about specific checks there? do we even need an automation if we address the things it would report?

[niStee]

@arielj I completely understand your reluctance to add to the noise of CI.

Let me explain how it can help.

It creates the report you requested. Without this workflow, we can't 'see the results over time'. It acts as a recording device, building up that history in the 'Security' tab.

It identifies mistakes that we miss (even mine!). For example, the checks running on this PR already flagged the fact that I had forgotten to pin the actions to a hash (I used @v4 instead of SHA) in the workflow file itself. I didn't notice that until the tool flagged it. If an action creator gets hacked, our build pipeline gets hacked too. This tool automatically detects that, so we don't have to be perfect.

It's strictly 'code scanning'. It doesn't block merges or break builds unless we instruct it to. It simply alerts us to security regressions in the same way that a linter alerts us to syntax errors.

Shall we merge this for a trial run? It won't stop any work from being done, we can just observe the results for a few weeks to see if it's useful.