Skip to content

OpenSSF Best Practices & Scorecard Self-Assessment

The primary foundation path is LF AI & Data Sandbox, whose published lifecycle explicitly requires a Passing OpenSSF Best Practices badge. The Scorecard remains a separate supply-chain signal. The underlying posture is already strong (signed digest-pinned image and chart, SLSA + SBOM attestations, Flux keyless verification, DCO, private vulnerability reporting, SHA-pinned workflow actions), so this is measurement and packaging, not new controls — and it never weakens the CD digest-pin flow or any existing control to chase a score.

This document is the preparable part of issue #460. The repository is public, but the remaining publication steps are still a human action under the maintainer account: register the bestpractices.dev project entry, enable Scorecard publication and SARIF upload, verify the public results, and add the rendered badges to the README. Until that explicit step, the workflow retains publish_results: false and keeps SARIF as a bounded artifact; public visibility alone is not evidence that those external records exist.

Best Practices passing-level criteria → evidence

Every row below maps a passing-level criterion to concrete in-repo evidence. No criterion is claimed that the repository does not implement; where a criterion is only partially met the row says so.

Basics

  1. Project description and homepage — README.md states what the project does and how to evaluate it.
  2. Contribution process — CONTRIBUTING.md documents the issue→PR workflow, labels, and DCO sign-off (no CLA); CHARTER.md, GOVERNANCE.md, and MAINTAINERS.md record TSC authority, decisions, and voting membership.
  3. FLOSS license — Apache-2.0 (LICENSE, rationale in docs/licensing.md); an OSI-approved license, stored in the standard location.
  4. Documentation (basics + interface) — README.md plus the topic specs under docs/ and the agent-facing AGENTS.md describe the architecture and interfaces.
  5. English / other — the project communicates in English; the issue and PR templates live under .github/.

Change control

  1. Public version-controlled source — the public GitHub repository exposes its version-controlled source and history.
  2. Unique, semantic versioning — releases are v-prefixed semver via the release skill; the main branch is protected by the protect-main ruleset (no force-push, deletion, or non-linear history).
  3. Release notes / changelog — releases publish a git-cliff changelog (Conventional Commits drive it); see the release skill and tagged GitHub releases.

Reporting

  1. Bug-reporting process — .github/ISSUE_TEMPLATE/ provides structured issue forms; the backlog convention is in the github-flow skill.
  2. Vulnerability-reporting process — SECURITY.md defines private vulnerability reporting; security bugs are never filed as public issues.
  3. Vulnerability-report response — the security release process covers private report → signed patch → GHSA/CVE publication → adopter notification.

Quality

  1. Working build system — mise is the single source of truth for install/build/format/check/test; lefthook and CI reuse the same tasks.
  2. Automated test suite + CI — mise run test runs the Go suites (race + coverage), the Python/knowledge suites, and the deterministic manifest/policy gates; .github/workflows/ci.yml runs the identical gates on every PR, and .github/workflows/fuzz.yml runs an extended nightly fuzz.
  3. Tests for new functionality — the testing standard requires deterministic tests for changes; new agents are gated by mise run test:agents-golden and the offline mise run agent:test <name> loop.
  4. Warning flags treated as errors — the lint gates run warning-free (golangci-lint, ruff, shellcheck --severity=style, dprint, trivy config), and a change that introduces a warning fails mise run check.

Security

  1. Secure development knowledge — the security spec §7 and the threat model map controls (prompt injection is the stated #1 threat); prompt-injection controls states each control's honest limits.
  2. Good cryptographic practices — ES256/JCS (RFC 8785) Signed AgentCards and usage receipts, P-256 keys, TLS for all web traffic, SOPS-age for secrets; no weak/rolled-own primitives, and verify-only public material is exchanged across organizations.
  3. Secured delivery against MITM — the bridge image and Helm chart are cosign-signed and consumed by immutable digest; Flux source-controller keyless-verifies the chart before helm-controller sees it (supply-chain verification); all workflow actions are SHA-pinned.
  4. Publicly known vulnerabilities addressed — trivy, govulncheck, and CodeQL gate every change; advisories are remediated promptly (e.g. the mid-cycle golang.org/x/text GO-2026-5970 bump).
  5. No leaked credentials — a gitleaks pre-commit and CI gate plus SOPS-age encryption keep plaintext secrets out of Git; only *.sops.yaml ciphertext is committed.

Analysis

  1. Static analysis — golangci-lint (Go), ruff (Python), shellcheck (shell), trivy config (IaC), and CodeQL via GitHub code scanning default setup (actions/go/python, on every PR and weekly) run on every change.
  2. Dynamic analysis — Go native fuzzing over the owned untrusted-input parsers (mise run test:fuzz, nightly extended budget) and the isolated Matrix↔A2A integration fixture.

Scorecard: accepted deviations

.github/workflows/scorecard.yml runs the OpenSSF Scorecard weekly and on demand. The following checks are not yet published at their maximum posture because of deliberate design or the pending publication step; each is an accepted deviation with a written rationale, not a silent control weakening.

  1. Branch-Protection — main uses the protect-main ruleset (blocks force-push, deletion, non-linear history), but intentionally omits repo-level required-PR/required-status-checks: CD's digest-pin step fast-forwards a commit to main as github-actions[bot], which a repo-level PR/check rule would block, and a repo ruleset cannot grant the built-in Actions app a bypass (that needs an org-scoped ruleset). This trade-off is documented in AGENTS.md; enforced review for outside contributors is the documented org-ruleset next step.
  2. SARIF upload / publish_results — the repository is public, but publication remains deliberately disabled until the maintainer completes and verifies the external-account steps in #460; until then SARIF remains a bounded workflow artifact.
  3. Pinned-Dependencies, Token-Permissions, Dangerous-Workflow — expected to pass: every workflow action is SHA-pinned with a version hint (mise run check:github-actions enforces it), every workflow declares an explicit least-privilege permissions map, and no workflow checks out and executes untrusted code.
  4. Fuzzing, SAST, CI-Tests, Vulnerabilities, Security-Policy — expected to pass on the evidence above (Go fuzz, CodeQL/golangci-lint/trivy, the CI gate, govulncheck, and SECURITY.md).

Before adding the badges, re-run Scorecard, record the actual public per-check scores here, and resolve or re-justify every non-passing check.