SLSA (Supply-chain Levels for Software Artifacts) and OpenSSF Scorecard are the leading open standards for software supply-chain security. They answer questions like "what is the provenance of my build artefacts?" and "does this project follow security best practices?"

CARL's Security & Access Control pillar overlaps meaningfully with both. The pillar incorporates many of the same signals Scorecard measures, and some of the same artefact requirements SLSA mandates at higher levels (signed builds, SBOMs, provenance attestation).

The short version

• SLSA → "What is the supply-chain integrity of this project's artefacts?"
• OpenSSF Scorecard → "Does this project follow security best practices at the repository level?"
• CARL → "Is this codebase ready for AI-agent-assisted development?"

CARL is broader. Supply-chain security is one of its eight pillars, not the whole thing. SLSA and Scorecard are narrower — they do their one thing deeply and well.

What SLSA covers

SLSA defines four levels (plus a proposed SLSA v1.0 structure) that ratchet the integrity guarantees of build artefacts:

• Provenance of each build (what source, what builder, what dependencies).
• Isolation of the build environment.
• Hermeticity of the build process.
• Signed, verifiable attestations from each build.

SLSA is explicitly about artefacts — the compiled binary, the container image, the published package — not about the code or the process leading up to it.

What OpenSSF Scorecard covers

Scorecard runs ~20 automated checks against an open-source repository:

• Branch protection
• CI / CD status checks
• Code review policies
• Dependency update tooling
• Signed releases
• Static analysis (SAST)
• Dangerous workflow patterns
• Security policy presence
• Token permissions

Each check produces a score; Scorecard aggregates into an overall score per repository.

What CARL covers that overlaps

CARL's Security pillar (SEC-) includes criteria that substantially overlap with Scorecard:

• SEC-010 (no committed secrets) — overlaps with Scorecard's token / binary-artefact checks.
• SEC-020 (.env* gitignored) — overlaps with Scorecard's dangerous- content patterns.
• SEC-030 (dependency audit gate) — overlaps with Scorecard's Vulnerabilities and Dependency-Update-Tool checks.
• SEC-040 (CODEOWNERS present) — overlaps with Scorecard's Code-Review check.
• SEC-050 (branch protection on main) — direct match.
• SEC-060 (DCO enforcement) — overlaps with Scorecard's Signed-Releases and Contributors checks.
• SEC-070 (Dependabot or Renovate configured) — direct match with Scorecard's Dependency-Update-Tool.
• SEC-080 (security headers set) — adjacent to SLSA's runtime integrity concerns.
• SEC-090 (SBOM generated on release) — direct match with SLSA Level 2+.

What CARL covers that these don't

• Documentation & Knowledge — README, AGENTS.md, environment docs, ADRs, runbooks. SLSA and Scorecard don't evaluate these.
• Code Quality & Validation — linters, formatters, strict typing, pre-commit hooks. Not in scope for SLSA or Scorecard.
• Testing — coverage, E2E tests, flake detection. Not in scope.
• Build & Environment — reproducibility from the developer's perspective (devcontainers, bootstrap scripts, .env.example). SLSA covers build isolation but not local-developer bootstrap.
• Observability — structured logging, tracing, error aggregation, SLOs. Not in scope.
• Task Intake & Routing — issue templates, PR templates, labels, triage. Not in scope.
• Delivery & Measurement — DORA metrics, deployment pipeline, preview environments. Not in scope.

Using them together

CARL assessments MAY incorporate SLSA attestations and Scorecard results as evidence for the relevant SEC- criteria. The output of a Scorecard run is directly usable as the evidence summary for several CARL criteria; the deterministic assessor records the Scorecard score alongside its own pass/fail result.

A team serious about supply-chain security should probably:

1. Aim for SLSA Level 2 or higher on production artefacts.
2. Run OpenSSF Scorecard in CI and track the score over time.
3. Use CARL as the broader readiness framework, with the SLSA and Scorecard outputs feeding its Security pillar.

That gets you deep supply-chain assurance alongside the broader agent-readiness picture.

Related

• The Security pillar — what CARL covers.
• Criteria catalog — full SEC- criterion definitions.
• vs. DORA — another complementary framework CARL references directly.