Help us improve
Share bugs, ideas, or general feedback.
From gh-guard
Provides Rust-specific guidance for all 18 OpenSSF Scorecard security checks with implementation steps, file templates, and CI workflows to maximize scores.
npx claudepluginhub sbom-tool/gh-guardHow this skill is triggered — by the user, by Claude, or both
Slash command
/gh-guard:scorecard-checksThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Last updated:** 2026-03-10 — Scorecard checks evolve; verify against the [latest Scorecard docs](https://github.com/ossf/scorecard/blob/main/docs/checks.md) if scores seem unexpected.
Triages SARIF security findings from CodeQL, Scorecard, cargo-deny, cargo-audit, and Dependabot. Guides GitHub workflows, priority matrix, dismissal policies, and Rust fixes.
Evaluates packages, manages dependencies, and addresses supply chain security for npm/pip/cargo/bundler/Go. Use for auditing packages, reviewing lockfiles, checking vulnerabilities, comparing alternatives, assessing trustworthiness.
Blocks unsafe code before commit with secret scanning, OWASP Top 10 detection, dependency audits (npm/pip/cargo), and permission checks. Hard security gate on critical findings.
Share bugs, ideas, or general feedback.
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)