scorecard.yml

# SPDX-FileCopyrightText: Sudo Apt Holdings LLC
# SPDX-License-Identifier: Apache-2.0
#
# OpenSSF Scorecard. It measures this repository against the OpenSSF's own checks - branch
# protection, pinned dependencies, signed releases, dangerous workflow patterns, token
# permissions, maintenance and the rest - and publishes the result so that anyone evaluating the
# project can read it without being asked to trust a claim made here.
#
# It runs weekly rather than on every push because the checks are about the repository's
# configuration and history, which change slowly, and because the analysis reads the GitHub API
# rather than the tree. The results are uploaded to the code-scanning dashboard, so a regression
# in the repository's posture is visible in the same place as a code finding.
#
# History worth keeping, because the failure mode is not obvious and will recur. From the day it
# was added until 2026-09-23 this workflow never ran: four `startup_failure` results with no job,
# no log and the message "This run likely failed because of a workflow file issue". The file was
# not the issue. `actionlint` passed it, all three pinned commits resolved, and three stripped-down
# copies on a throwaway branch failed identically, including one that was nothing but a checkout
# and the action. The cause was the repository's Actions policy: `allowed_actions` was `selected`
# with GitHub-owned actions and two `setup-*` patterns permitted, and `ossf/scorecard-action` is
# neither GitHub-owned nor was it listed, so the run was refused before a job existed. Every other
# action in this tree lives under `actions/` or `github/`, which is why nothing else ever hit it.
# **Adding an action from a new owner to any workflow here requires adding it to that allow-list,
# or the workflow silently never starts.**
name: scorecard

on:
  # Added 2026-09-23 after this workflow had failed to start four times in a row without anyone
  # being able to retry it: a run that ends in `startup_failure` cannot be re-run, and the only
  # other triggers here are a push to the default branch and a weekly schedule, so every attempt
  # to diagnose it cost a commit on `main`. A workflow that cannot be triggered on demand is a
  # workflow that cannot be tested, which is how it stayed broken from the day it was added.
  workflow_dispatch:
  branch_protection_rule:
  schedule:
    # Mondays, 07:00 UTC. A fixed day makes a drop in the score attributable to the week it
    # appeared in rather than to an unknown point since the last look.
    - cron: '0 7 * * 1'
  push:
    branches: [main]

permissions: read-all

jobs:
  analysis:
    name: Scorecard analysis
    runs-on: ubuntu-latest
    permissions:
      # Upload the result to the code-scanning dashboard.
      security-events: write
      # Read the repository's own metadata (branch protection, releases, workflow runs).
      id-token: write
      contents: read
      actions: read

    steps:
      - name: Checkout
        uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
        with:
          persist-credentials: false

      - name: Run analysis
        uses: ossf/scorecard-action@2d1146689b8cda280b9bc96326124645441f03bc # v2.4.4
        with:
          results_file: results.sarif
          results_format: sarif
          # Publishing makes the score readable at deps.dev and through the Scorecard API, which
          # is the point: an evaluator should be able to check the posture without asking us.
          publish_results: true

      - name: Upload the result as an artifact
        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
        with:
          name: scorecard-results
          path: results.sarif
          retention-days: 30

      - name: Upload the result to code scanning
        uses: github/codeql-action/upload-sarif@416ff0dea110f80f0f56f0046500dbf7420e4bb0 # codeql-bundle-v2.27.1
        with:
          sarif_file: results.sarif