OpenSSF Scorecard — all 18 checks with Rust-specific implementation guidance
From gh-guardnpx claudepluginhub anthropics/claude-plugins-community --plugin gh-guardThis skill is limited to using the following tools:
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Last updated: 2026-03-10 — Scorecard checks evolve; verify against the latest Scorecard docs if scores seem unexpected.
The OpenSSF Scorecard evaluates 18 security checks on a 0-10 scale. This skill covers each check with Rust-specific guidance for maximizing your score.
| Check | Key Files | Scorecard Impact | Difficulty |
|---|---|---|---|
| Security-Policy | SECURITY.md | +1 | Easy |
| License | LICENSE | +1 | Easy |
| Binary-Artifacts | — (avoid committing binaries) | +1 | Easy |
| Dangerous-Workflow | .github/workflows/*.yml | +1 | Easy |
| Token-Permissions | .github/workflows/*.yml | +1 | Medium |
| Pinned-Dependencies | .github/workflows/*.yml | +1 | Medium |
| Branch-Protection | GitHub Settings | +1 | Medium |
| CI-Tests | .github/workflows/ci.yml | +1 | Medium |
| Dependency-Update-Tool | .github/dependabot.yml OR renovate.json | +1 | Easy |
| Fuzzing | fuzz/ + CI workflow, OR OSS-Fuzz integration | +1 | Medium |
| SAST | .github/workflows/codeql.yml | +1 | Easy |
| Vulnerabilities | osv-scanner.toml, Cargo.lock | +1 | Variable |
| Code-Review | PR review settings | +1 | Behavioral |
| Contributors | — (multiple contributors) | +1 | Organic |
| Maintained | — (recent commits, issues) | +1 | Organic |
| Packaging | publish.yml | +1 | Medium |
| Signed-Releases | GitHub Releases + provenance | +1 | Hard |
| CII-Best-Practices | bestpractices.dev badge | +0.5 | Manual |
What it checks: Presence of SECURITY.md in repo root or .github/.
Rust action: Use the templates/SECURITY.md template. Include coordinated disclosure policy and supported versions table.
What it checks: Recognized license file in repo root.
Rust action: Add LICENSE (MIT or Apache-2.0 are standard for Rust). Ensure Cargo.toml has matching license = "MIT".
What it checks: No compiled binaries committed to the repo.
Rust action: Add target/ to .gitignore. Never commit .so, .dll, .dylib, .exe, or .wasm files.
What it checks: No pull_request_target with checkout of PR code, no workflow_run with untrusted input.
Rust action: Use pull_request (not pull_request_target) for PR workflows. Never pass PR body/title to shell commands.
pull_request_target risks:
actions/checkout with ref: ${{ github.event.pull_request.head.sha }}), attacker-controlled code executes with elevated privilegespull_request_target exploit that stole a PAT, leading to full repository takeover and tag hijacking of aquasecurity/trivy-actionworkflow_run risks:
workflow_run can inherit untrusted artifacts or refs${{ github.event.workflow_run.head_branch }} or similar attacker-controlled values in shell commands or run: stepsWhat it checks: Workflows declare permissions at top level and don't use default broad GITHUB_TOKEN permissions.
Rust action: Add permissions: read-all at workflow level. Override per-job only where needed (e.g., contents: write for releases, id-token: write for OIDC).
What it checks: GitHub Actions referenced by full commit SHA, not tags.
Rust action: Pin all uses: to SHA with version comment:
# v6.0.2
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
Exception: SLSA generator MUST use @tag (e.g., @v2.1.0) — it's a reusable workflow that doesn't support SHA references.
Defense in depth: SHA pinning is the primary defense against action compromise (see the Trivy tag hijacking incident in the ci-pipeline skill). As a complementary measure, consider runner-level network egress controls (e.g., StepSecurity Harden-Runner) to block unauthorized outbound connections — this would have prevented the Trivy payload from exfiltrating secrets even if an unpinned action had been consumed.
What it checks: Branch protection rules on default branch. Rust action: Configure branch protection ruleset:
What it checks: CI runs on PRs and checks test results.
Rust action: Use the templates/workflows/ci.yml template. The gate job pattern ensures a single required status check.
What it checks: Dependabot or Renovate configuration exists.
Rust action: Either .github/dependabot.yml (covering cargo and github-actions ecosystems) or renovate.json / .github/renovate.json satisfies this check — Scorecard recognizes both. If the project already uses Renovate, do not add a redundant dependabot.yml; it will create duplicate PRs.
What it checks: Project uses a fuzzing framework (OSS-Fuzz, ClusterFuzzLite, or CI-integrated fuzzing).
Rust action: Set up cargo-fuzz with targets. Use templates/workflows/fuzz.yml. Even one target that fuzzes a parser or decoder counts.
Alternative: If the project is already integrated with OSS-Fuzz, this check passes automatically — Scorecard queries the google/oss-fuzz repository directly. A local CI workflow is redundant in that case and adds no score value.
What it checks: Static analysis tool runs on PRs (CodeQL, Semgrep, etc.).
Rust action: Use templates/workflows/codeql.yml with build-mode: none for Rust.
Gotcha: Disable "default setup" in repo Settings > Code Security before using a custom CodeQL workflow. They conflict.
What it checks: No known vulnerabilities in dependencies (via GitHub dependency graph / OSV).
Rust action: Keep Cargo.lock updated. Run cargo audit regularly.
Common false positive: If your project contains SBOM test fixtures or sample data with package references (npm, PyPI, etc.), those PURLs will be scanned and flagged. Use osv-scanner.toml to suppress non-Rust ecosystems. Note: Scorecard uses GitHub's dependency graph API, not local scans, so osv-scanner.toml may not fully resolve this.
What it checks: PRs are reviewed before merge (looks at recent merge history). Rust action: While primarily behavioral, there are concrete steps:
/harden Standard checklist--admin merges (the release script now prompts before using this)What it checks: Multiple contributors from different organizations. Rust action: While primarily organic, you can encourage contributions:
CONTRIBUTING.md and "good first issue" labelsWhat it checks: Recent commits, issue responses, release activity within 90 days. Rust action: Concrete steps to keep the score healthy:
/harden Minimal) — automated PRs count as activity/harden Standard makes this easy)What it checks: Project publishes packages via CI (not local machine).
Rust action: Use templates/workflows/publish.yml with Trusted Publishing. Publishing from CI (triggered by tag push) satisfies this check.
What it checks: GitHub Releases exist with provenance or signed assets.
Rust action: Use the three-job publish pipeline: publish → SLSA provenance → release with .intoto.jsonl attached. The provenance file attached to GitHub Releases satisfies this check.
What it checks: OpenSSF Best Practices badge at bestpractices.dev. Rust action: Register at bestpractices.coreinfrastructure.org and complete the Passing questionnaire. Silver and Gold badges require additional manual work.
Quick wins (0→7): Security-Policy, License, Dependabot, CI-Tests, Token-Permissions, Pinned-Dependencies, SAST Medium effort (7→9): Fuzzing, Branch-Protection, Packaging, Signed-Releases Hard/organic (9→10): Code-Review (behavioral), CII-Best-Practices (manual), Contributors/Maintained (time)