Zirconium Build Pipeline

The canonical framework for measuring software delivery: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service. Published by Google Cloud's DevOps Research and Assessment team and validated across thousands of organizations since 2014.

• DORA Metrics Guide
• Annual State of DevOps Reports
• DORA Quick Check — assess your team
• DORA Capabilities Catalog — what drives each metric

Automated security health checks for open source projects, scoring 0–10 across checks including signed releases, SBOM presence, branch protection, pinned dependencies, and CI test coverage. Produced by the Open Source Security Foundation (OpenSSF), a Linux Foundation project.

• OpenSSF Scorecard — project home
• All checks explained

A graduated framework (L0–L3) for verifiable software build integrity. Each level adds stronger guarantees: L1 means provenance exists, L2 means it is signed by a hosted build platform, L3 means the build environment itself is hardened and isolated. Developed by Google and adopted as an OpenSSF standard.

• slsa.dev — project home
• Build Track levels explained (v1.2)

Keyless, identity-based artifact signing backed by a public transparency log (Rekor). Cosign signs and verifies container images and release artifacts using short-lived OIDC certificates — no long-lived private keys to manage or rotate. A CNCF project used by Kubernetes, Tekton, and the Bluefin image pipeline.

• sigstore.dev — project home
• Cosign signing overview
• Verifying signatures

A machine-readable inventory of every component and dependency in a software artifact. SBOMs make vulnerability response faster — when a new CVE is published, you can immediately know which of your images are affected. The OpenSSF SBOM Everywhere SIG maintains tooling guidance and naming conventions.

• OpenSSF SBOM Everywhere SIG
• SBOM tooling catalog
• SBOM naming conventions

The CNCF Technical Advisory Group for Security publishes authoritative whitepapers on cloud-native supply chain security. The Software Supply Chain Best Practices paper (v2, 2025) and the Secure Software Factory reference architecture define the practices that the Scorecard and SLSA checks encode.

• TAG Security home
• Software Supply Chain Best Practices (v2, 2025)
• Secure Software Factory Reference Architecture

The authoritative CNCF definition of what internal developer platforms are, what they should measure (user satisfaction, self-service rate, onboarding time), and how platform teams should operate. Published by the TAG App Delivery Platforms Working Group. Recommends DORA metrics as the delivery measurement standard for platform teams.

• CNCF Platforms White Paper
• Platforms Working Group

A 4-level model (Provisional → Operational → Scalable → Optimizing) across five aspects: Investment, Adoption, Interfaces, Operations, and Measurement. Helps platform teams understand where they are and what practices characterize the next level. Published by the CNCF TAG App Delivery Platforms Working Group.

• Platform Engineering Maturity Model

A 5-level model (Build → Operate → Scale → Improve → Adapt) across Business Outcomes, People, Process, Policy, and Technology. Maintained by the CNCF Cartografos Working Group. Version 4 (2025) adds AI and FinOps dimensions. Useful for understanding where cloud-native adoption fits in the broader organizational journey.

• Cloud Native Maturity Model
• Cartografos Working Group (GitHub)

The peer-reviewed research behind DORA metrics. Nicole Forsgren, Jez Humble, and Gene Kim identified 24 technical, process, and cultural capabilities that predict software delivery performance and organizational outcomes. Required reading for understanding why deployment frequency and lead time matter.

• DORA research archive (all annual reports)

Google's Site Reliability Engineering book defines four signals sufficient to monitor any user-facing service: Latency, Traffic, Errors, and Saturation. These are the production observability complement to DORA — they define what a "failure" actually is (without them, Change Failure Rate cannot be accurately measured) and predict when MTTR will spike before incidents occur.

• Google SRE Book — Chapter 6: Monitoring Distributed Systems

DORA measures what the pipeline does; SPACE measures how developers experience it. Developed by Nicole Forsgren (GitHub), Margaret-Anne Storey, and colleagues at Microsoft Research. Five dimensions: Satisfaction, Performance, Activity, Communication/Collaboration, and Efficiency. Never measure activity in isolation.

• ACM Queue — The SPACE of Developer Productivity (2021)