← Back to all briefings
Developer 5 min read Published Updated Credibility 90/100

Developer Enablement Briefing — July 10, 2024

OpenSSF Scorecard 5.0 introduces structured probes, maintainer annotations, and new supply-chain checks, requiring engineering, security, and compliance teams to update automation, APIs, and risk reporting workflows.

Zeph Tech Research Lead

Research lead, Zeph Tech

Timeline plotting source publication cadence sized by credibility.
2 publication timestamps supporting this briefing. Source data (JSON)

Executive briefing: The Open Source Security Foundation (OpenSSF) released Scorecard 5.0 on 10 July 2024, delivering the most significant upgrade since the project’s inception. Scorecard evaluates open-source repositories against a set of supply-chain security checks; the new version breaks the monolithic scoring model into structured probes, introduces maintainer annotations, refactors the API, and expands checks across SBOM publication, packaging, and dependency management ecosystems. Engineering leaders should plan upgrades to automation pipelines, policy-as-code rules, and governance dashboards to capitalise on the richer telemetry while staying compatible with the new Go module layout.

Structured Results allow organisations to select individual probes within each check, enabling custom policies (e.g., requiring signed releases and fuzzing while downweighting other heuristics). Maintainer annotations provide project maintainers with a mechanism to clarify when Scorecard cannot observe a control, reducing false positives. Breaking API changes migrate packages from github.com/ossf/scorecard/v4/pkg to github.com/ossf/scorecard/v5/pkg/scorecard, simplify Run signatures, and adjust formatting options. New or improved checks cover SBOM publication, Gradle wrapper verification, Scala Steward detection, NuGet restore support, and packaging workflows such as sbt ci-release. Dependency diff functionality has been removed, and OneFuzz detection retired due to deprecation. Organisations embedding Scorecard into CI/CD, dependency intake, or third-party risk workflows must update integrations promptly.

Key enhancements

  • Structured probes: Each of the 19 checks is decomposed into granular probes; the CLI supports the --probes flag with --format probe to output targeted results, enabling custom control mapping.
  • Maintainer annotations: Maintainers can provide context (e.g., “not-detected”) when practices exist but cannot be inferred automatically; consumers can use --show-annotations to display them.
  • API simplification: The RunScorecard function becomes Run with streamlined parameters, default clients, and options structs for advanced use cases.
  • SBOM and packaging coverage: Experimental SBOM publication detection, Gradle wrapper validation, NuGet restore support, Scala Steward and sbt ci-release recognition expand the visibility of supply-chain practices.
  • Probe additions: New probe surfaces release provenance verification, enhancing policy checks for signed or provenance-backed releases.

Impact assessment for enterprises

  1. CI/CD pipelines: Workflows invoking Scorecard must pin to v5 modules, adjust CLI flags for probes, and account for removed dependency diff features.
  2. Security policy automation: Policy engines (e.g., Open Policy Agent, GitHub branch protection gates) can now use probe-level data to enforce nuanced requirements such as SBOM publication or packaging best practices.
  3. Third-party risk reviews: Procurement and risk teams can request structured Scorecard reports from suppliers, enabling more precise attestation of open-source dependencies.
  4. Developer enablement: Documentation and training must explain new probes, annotation workflows, and how teams can respond to Scorecard findings.
  5. Tool integrations: Products embedding Scorecard (security scanners, dependency tools) must update API calls and data schemas to accommodate v5.

Control mapping

  • NIST Secure Software Development Framework (SSDF): Map structured probes to practices such as PO.3.2 (maintain provenance), PW.4.1 (address vulnerabilities), and RV.1.2 (collect evidentiary data).
  • SLSA and supply-chain regulations: Use SBOM and provenance probes to evidence compliance with SLSA Level 2+, U.S. OMB M-22-18, and forthcoming EU Cyber Resilience Act requirements.
  • ISO/IEC 27034 and 27001: Integrate Scorecard telemetry with secure development life cycle controls and vulnerability management metrics.
  • Internal open-source program offices (OSPO): Embed Scorecard 5.0 into intake reviews, backlog prioritisation, and community engagement dashboards.

Implementation roadmap

PhaseTimelineActivities
AssessmentWeeks 1–2Inventory Scorecard usage across CI/CD, release pipelines, supply-chain monitoring, and risk reports; identify owners and dependencies.
DesignWeeks 3–5Define probe policies, update architecture diagrams, determine annotation governance, and plan API migration.
ExecutionWeeks 6–10Upgrade modules, adjust workflows, configure --probes output, and integrate SBOM/provenance checks.
ValidationWeeks 11–12Run regression tests, compare Scorecard 4.x vs 5 results, review annotations, and update dashboards.
OperationalisationOngoingMonitor metrics, refine probe selections, and share insights with engineering and leadership.

Governance and ownership

  • Security engineering: Owns toolchain upgrades, policy definitions, and integration with vulnerability management systems.
  • DevOps and platform teams: Maintain CI/CD configurations, ensure Scorecard runs efficiently, and manage compute costs.
  • OSPO / open-source governance: Coordinates with upstream maintainers, manages annotation submissions, and curates approved dependencies.
  • Risk and compliance: Consumes probe data for third-party assessments and regulatory reporting.
  • Product teams: Incorporate Scorecard results into release readiness and customer trust communications.

Metrics and reporting

  • Percentage of critical dependencies evaluated with Scorecard 5.0, broken down by risk tier.
  • Probe coverage across key domains (build integrity, code review, dependency management, SBOM, provenance).
  • Number of maintainer annotations processed, resolved, or escalated.
  • Time to remediate failing probes or checks after detection.
  • Integration completeness: proportion of pipelines migrated to v5 APIs and CLI options.

Enablement and documentation

  • Update internal runbooks detailing CLI usage (--probes, --format probe, --show-annotations), API changes, and data schemas.
  • Develop playbooks for interpreting structured results and mapping them to remediation tasks.
  • Provide guidance for upstream maintainers on submitting annotations and clarifying security practices.
  • Communicate dependency diff deprecation and alternatives, such as GitHub’s dependency review action.

90-day action plan

  1. Days 1–30: Freeze Scorecard 4.x usage, assess integrations, and pilot Scorecard 5.0 on representative repositories; document API migration steps.
  2. Days 31–60: Roll out structured probes in CI/CD, configure policy enforcement, capture annotations, and refresh reporting dashboards.
  3. Days 61–90: Complete migration for all pipelines, integrate probe data with GRC systems, and share programme outcomes with executives and open-source partners.

Integration examples

  • GitHub Actions: Update workflows using ossf/scorecard-action to reference v5, configure results_file outputs, and feed probe data into SARIF uploads for Code Scanning insights.
  • GitLab CI/CD: Package Scorecard 5.0 as a container job, export probe JSON to GitLab security dashboards, and trigger merge request approvals based on failing probes.
  • Artifact repositories: Integrate Scorecard checks into package promotion pipelines (e.g., Artifactory, Nexus) to block releases lacking provenance or SBOM signals.
  • Policy-as-code: Use OPA/Rego or HashiCorp Sentinel policies to parse probe JSON and enforce internal gates, mapping outcomes to severity tiers.

Risk scenarios addressed

  • Unsigned releases: Probe-level data surfaces missing provenance or signing, enabling targeted remediation before deploying dependencies.
  • Dependency management gaps: Enhanced packaging and dependency update detection highlight ecosystems (NuGet, Scala) previously under-covered.
  • False positives: Maintainer annotations reduce the risk of rejecting dependencies that comply through alternative mechanisms.
  • Automation drift: API refactors encourage more maintainable integrations with fewer bespoke parameters.

Stakeholder communications

  • Publish Scorecard 5.0 adoption roadmaps for executive sponsors, emphasising alignment with national secure software requirements and customer commitments.
  • Brief customers and partners on how structured probes improve transparency and auditing of dependencies.
  • Coordinate with legal and compliance teams to ensure updated policies reflect Scorecard-derived evidence, especially for software attestation obligations.

Zeph Tech helps engineering and security organisations operationalise OpenSSF Scorecard 5.0—upgrading toolchains, tuning probe policies, and translating supply-chain insights into actionable governance and assurance.

Timeline plotting source publication cadence sized by credibility.
2 publication timestamps supporting this briefing. Source data (JSON)
Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Related briefings

Curated signals from the same pillar or overlapping topics.

Continue in the Developer pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • OpenSSF
  • Scorecard
  • Software supply chain
  • DevSecOps
Back to curated briefings