Skip to content

feat: add JSON Schema, SLSA mapping, and positioning clarification #49

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
shenxianpeng merged 1 commit into from
May 24, 2026
Merged

feat: add JSON Schema, SLSA mapping, and positioning clarification #49

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions MAPPING-SLSA.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# DevOps Maturity ↔ SLSA Mapping

This document maps DevOps Maturity criteria to relevant [SLSA (Supply-chain Levels for Software Artifacts)](https://slsa.dev/) concepts, helping teams understand where the two frameworks overlap.

## Relationship

DevOps Maturity is a **broader DevOps baseline assessment**, not a supply-chain security standard. It covers build, test, security, supply chain, analysis, and reporting — a wider surface than SLSA's focused scope on artifact integrity and provenance.

**DevOps Maturity does not replace SLSA.** SLSA provides a rigorous, verifiable supply-chain integrity framework. DevOps Maturity can help teams assess their readiness across the full DevOps spectrum, and the supply-chain-related criteria map naturally to SLSA requirements.

## Criteria Mapping

| DevOps Maturity | Description | SLSA Direction |
|---|---|---|
| **D401** Documented Build Process | Build steps are version-controlled and documented | Build process transparency — a prerequisite for Build Track reproducibility |
| **D402** CI/CD as Code | Pipelines and infrastructure defined as code | Build process definition — SLSA requires the build process to be defined and verifiable |
| **D403** Artifact Signing | Build artifacts are cryptographically signed | Artifact integrity / provenance distribution — aligns with SLSA's requirement for signed attestations |
| **D404** Dependency Pinning | All dependencies pinned to exact versions | Reproducibility support — reduces supply-chain attack surface |
| **D405** SBOM Generation | Automatically generate Software Bill of Materials | Supply-chain transparency — complements SLSA provenance with dependency inventory |
| **D603** Compliance Mapping & Auditability | Map controls to standards, provide audit-ready reports | Verified properties / audit evidence — supports the consumption and verification side |
Comment on lines +11 to +20
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot May 24, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

What are the specific requirements in SLSA for build process documentation, signed attestations, and provenance?

💡 Result:

In SLSA (Supply-chain Levels for Software Artifacts), requirements for (1) build process documentation, (2) signed attestations, and (3) provenance are captured primarily in the “Build” and “Producing artifacts” requirements plus the attestation/provenance specifications. 1) Build process documentation (what must be documented) - The build process MUST generate provenance that “unambiguously identifies the output package … and describes how that package was produced” [1]. This description is represented in the provenance attestation via required build inputs such as build definition (buildType, parameters, dependencies) and run details (builder, invocation metadata, byproducts) [2]. - For SLSA Build level L1, the Provenance predicate requires at least a buildDefinition and runDetails [3][2]. 2) Signed attestations (how signing is required/structured) - SLSA defines software attestations as authenticated, machine-readable metadata containing at least a message (statement) and a signature that denotes the attester [4]. - Provenance (as a predicate type) is carried inside an attestation statement (in-toto Statement) and is expected to be signed so verifiers can validate integrity and authenticity (i.e., that the digital signature is valid and the provenance was not tampered with after the build) [1]. 3) Provenance requirements (what provenance must contain and how it must be protected) - Provenance MUST be generated by the build system to: (a) unambiguously identify the output package by cryptographic digest, and (b) describe how it was produced [1]. - Consumers MUST be able to validate authenticity by verifying the digital signature of the provenance attestation (integrity) and being able to define trust (identify build system and other entities necessary to trust the artifact) [1]. - Authenticity / tamper-resistance in generation: - Secret signing material (e.g., signing key) MUST be stored in a secure management system appropriate for such material and accessible only to the build service account [1]. - The build service MUST generate/verify every field in the provenance in a trusted control plane; user-controlled build steps MUST NOT be able to inject or alter provenance fields (except as noted in the spec) [1]. - Provenance MUST be generated by the build system within the trust boundary identified in the provenance; it MUST not be generated by a tenant outside that trust boundary [5]. - Provenance predicate structure (what’s included): - Provenance is an attestation that a particular build platform produced a set of software artifacts through execution of the buildDefinition [2]. - The provenance example shows required elements including subject artifacts, predicateType, buildDefinition (buildType, externalParameters, internalParameters, resolvedDependencies) and runDetails (builder with id and optional dependencies/version; metadata with invocationId/startedOn/finishedOn; and byproducts) [2]. Bottom line - Documentation requirement in SLSA Build is effectively met by provenance containing an unambiguous “how produced” description tied to the output package [1] (with buildDefinition + runDetails required at least at L1) [3][2]. - Signed attestations are required so that consumers can verify the attestation signature and ensure provenance integrity/authenticity [1][4]. - Provenance must be generated inside the build platform’s trusted control plane, protect signing keys, and prevent user build steps from injecting/modifying provenance fields [1][5].

Citations:

🌐 Web query:

SLSA build requirements reproducibility hermetic dependency pinning version controlled build definition

💡 Result:

SLSA doesn’t define “reproducible/hermetic” as a single universal checklist in SLSA v1.0; instead it defines Build levels (L1–L3 in v1.0) around provenance integrity and build isolation, while “Hermetic” and “Reproducible” were explicitly present in the earlier SLSA v0.1 draft but are deferred for v1.0 (future work). [1][2] 1) Reproducibility (bit-for-bit) - In SLSA v0.1, reproducibility is listed as a build requirement option (“Build - Reproducible”). It is explicitly marked as not fully required for some levels (shown as “○” rather than a “✓”). [3] - A later SLSA v0.1 “Build L4” discussion includes “Reproducible builds, which enable other build platforms to corroborate the provenance.” [4] - SLSA v1.0 explicitly defers “hermetic builds (SLSA L4)” and “common requirements” to a future version, so SLSA v1.0 Build levels L1–L3 are not the direct “bit-for-bit reproducibility” story. [2] 2) Hermeticity (network isolation / no extraneous dependencies) - SLSA v0.1’s requirements table includes “Build - Hermetic” as a requirement (“✓”). [3] - In the SLSA v1.0 build requirements text, the note distinguishes “Hermetic” (no network access) as distinct from the v1.0 build isolation concept, and states hermetic requirements “require substantial changes … and is considered in the future directions.” [5][6] 3) Dependency pinning and “version-controlled build definition” A) Version-controlled build definitions - SLSA v0.1 requires the build definition/config executed by the build service be “verifiably derived from text file definitions stored in a version control system.” [3] B) Declared dependencies with immutable references - SLSA v0.1 requires that “all transitive build steps, sources, and dependencies were fully declared up front with immutable references.” [3] - It also requires: “MUST declare all dependencies, including sources and other build steps, using immutable references in a format that the build service understands.” [3] C) Completeness of dependencies in provenance - The SLSA v1.0 provenance predicate/documentation describes that resolved dependencies should be an “unordered collection of artifacts needed at build time” and that completeness is “best effort, at least through SLSA Build L3,” including recursively listing artifacts when build steps fetch and execute scripts/archives. [7] 4) What SLSA v1.0 Build levels require instead (isolation + provenance integrity) - SLSA v1.0 production requirements split responsibility: the producer must choose a build platform capable of achieving the desired build level, while the build platform must strengthen controls to achieve that level and provide provenance generation and isolation between builds. [6] - The v1.0 producing-artifacts requirements state the build process must generate provenance that “unambiguously identifies the output package by cryptographic digest and describes how that package was produced.” [6] - Isolation requirements include preventing builds from influencing one another and ensuring “It MUST NOT be possible for one build to persist or influence the build environment of a subsequent build,” and preventing builds from accessing sensitive build-service secrets (e.g., signing keys). [6] 5) Practical synthesis: mapping your terms to SLSA language - “Version-controlled build definition” maps directly to SLSA v0.1’s “verifiably derived from text file definitions stored in a version control system.” [3] - “Dependency pinning” maps directly (in SLSA v0.1) to “immutable references” for declared transitive dependencies/sources/build steps. [3] - “Hermetic dependency pinning” (no extraneous dependencies, no network) is explicitly part of the v0.1 hermetic requirement, but in v1.0 the spec distinguishes it and defers it as future direction (i.e., not part of Build L1–L3 isolation/provenance requirements). [5][3] - “Reproducibility” (bit-for-bit) is explicitly tracked as a v0.1 capability/requirement but not guaranteed by the v1.0 Build levels. [3][2] If you tell me which artifact ecosystem you care about (e.g., container images, npm packages, Java, Go) and which SLSA level you’re targeting, I can translate the above into concrete checklist items (lockfile/immutable refs strategy, provenance completeness expectations, and what “hermetic” means operationally vs. just isolation).

Citations:

🌐 Web query:

Does SLSA require generating SBOMs Software Bill of Materials in any build level

💡 Result:

No. SLSA does not require generating SBOMs (Software Bill of Materials) at any build level. SLSA’s Build track requirements are centered on producing tamper-evident, verifiable build provenance (attestations about how the artifact was built, build platform properties like isolation, and—at higher levels—more complete dependency information for the provenance predicate). In the SLSA FAQ, the SLSA Provenance/Build track explicitly explains that SBOMs and SLSA provenance are different and that existing SBOM formats were “not a good fit for the requirements of the Build track,” while noting SBOMs are good practice but not mandated by SLSA Build. [1] Additionally, the SLSA spec for producing artifacts defines build-level requirements around provenance generation/distribution and related provenance fields; it does not state SBOM generation as a requirement for any build level. [2]

Citations:

🌐 Web query:

SLSA audit evidence compliance mapping requirements auditability

💡 Result:

SLSA “auditability” and “audit evidence compliance mapping” are achieved by producing SLSA attestations (especially provenance and verification summary attestations) that external parties (auditors, package ecosystems, consumers, or monitors) can verify automatically. 1) What SLSA requires for auditable evidence (evidence = attestations + verification records) - For SLSA Source, the SCS (Source Control System) MUST create Source Provenance attestations contemporaneously with each branch update, so they provide a credible, auditable record of changes, including timing, who made the changes, and which technical controls were enforced. [1] - SLSA requires that the SCS document the format and intent of all Source Provenance attestations it produces. This is necessary so others can reason about the claimed properties in the related summary attestation. [1] - SLSA distinguishes between: a) Source Provenance attestations (tamper-proof metadata used to determine what SLSA Source Level / properties a revision meets) [1] b) Source VSAs (Source Verification Summary Attestations) used to communicate high-level security properties of a source revision to downstream users. [1] - In SLSA, attestations are the mechanism that make explicit security claims about artifacts; they are primarily meant to feed automated policy engines and verification workflows. [2] 2) How “compliance mapping” to audit requirements becomes audit-ready - SLSA itself provides a control/evidence model that can be mapped into compliance processes by treating “evidence items” as verifiable attestations that correspond to SLSA claims. - In SLSA Source L3+ (and similar levels in other tracks), SLSA expects organizations to be able to verify that processes were followed for the consumed revision by examining the related summary or provenance attestations; e.g., consumers can look for organization-specific properties recorded in verifiedLevels in the summary attestation. [3] - SLSA verification is explicitly part of the model: attestations don’t “do anything” unless someone inspects them via verification, and SLSA provides the mechanics for verifying properties of source revisions using the attestations associated with those revisions. [4] 3) What makes the evidence “auditable” in practice (properties needed for auditors) - Tamper-evident, contemporaneous provenance: SCS-generated Source Provenance attestations must be created contemporaneously and provide an auditable record. [1] - Verifiable semantics: SLSA provenance/attestation formats must be documented so claims can be interpreted reliably by verifiers and downstream users. [1] - Efficiency for audits via summary attestations: when you need auditability at scale, VSAs provide a compact, high-level result that downstream parties can use instead of re-deriving everything from raw history each time. [1] 4) Evidence-to-claim mapping: where verification should happen SLSA describes multiple valid verification placements—e.g., verification at source fetch time, at package upload time, at consumer download/use time, or via continuous monitoring—so the organization can choose audit workflows that match its architecture while keeping the evidence verifiable. [4] 5) Common “auditability gaps” organizations must avoid - Relying only on attestations without verification: SLSA emphasizes that attestations require inspection (verification) to be meaningful. [4] - Not documenting how attestations map to SLSA properties: SLSA Source requires the SCS to document provenance format/intent so that summary attestations’ claims can be reasoned about. [1] If you tell me which SLSA track/level you’re mapping (e.g., SLSA Source L3 vs Build L3) and what compliance framework you’re targeting (SOC 2, ISO 27001, SSDF, etc.), I can produce a concrete “audit evidence checklist” that points to the exact SLSA attestation artifacts you should store and what properties an auditor/verifier should be able to confirm.

Citations:

Fix the D401–D405 mappings to match SLSA Build/provenance requirements.

  • D403 (Artifact Signing): Accurate—SLSA relies on signed attestations/provenance so verifiers can validate integrity/authenticity.
  • D401 (Documented Build Process) / D402 (CI/CD as Code): Overstated—SLSA Build requires provenance that describes how the artifact was produced (via buildDefinition/runDetails), not an explicit requirement that build steps are “version-controlled” or that CI/CD is “defined as code.”
  • D404 (Dependency Pinning): Incorrect as written—SLSA does not require “all dependencies pinned to exact versions” for Build L1–L3; dependency info in provenance is best-effort and more complete at higher levels.
  • D405 (SBOM Generation): Incorrect—SLSA does not require SBOM generation in the Build track (SBOMs can complement provenance but are not mandated).
  • D603 (Compliance Mapping & Auditability): Directionally fine but overstated—SLSA provides verifiable, auditable attestations/evidence for automated verification; it doesn’t require control-to-standard mapping content or producing “audit-ready reports” directly.
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@MAPPING-SLSA.md` around lines 11 - 20, Update the criteria mappings to align
with SLSA Build/provenance semantics: adjust D401 and D402 to describe that SLSA
Build requires provenance describing how artifacts were produced
(buildDefinition/runDetails) rather than asserting version-controlled build
steps or CI/CD-as-code; change D404 to remove the absolute requirement of "all
dependencies pinned to exact versions" and instead note that dependency
information in provenance is best-effort and more stringent at higher SLSA
levels; change D405 to remove the claim that SBOM generation is required by SLSA
Build and state SBOMs are complementary but not mandated; and tone down D603 to
reflect that SLSA provides verifiable attestations and evidence for automated
verification but does not itself mandate producing control-to-standard mappings
or audit-ready reports.

Copy link
Copy Markdown
Member Author

@shenxianpeng shenxianpeng May 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@coderabbitai so please make suggestions if you think you are right

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot May 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shenxianpeng, here are the suggested corrections based on the SLSA specification research. The key issues are:

  1. D401/D402 – SLSA Build L1+ requires provenance (buildDefinition + runDetails) describing how the artifact was produced; it does not explicitly mandate that build steps be "version-controlled" or pipelines be "defined as code."
  2. D404 – SLSA does not mandate pinning all dependencies to exact versions; dependency completeness in provenance is best-effort through Build L3 (SLSA spec).
  3. D405 – SLSA explicitly states SBOMs are not a Build track requirement (SLSA FAQ).
  4. D603 – SLSA provides verifiable attestations for automated verification, but does not itself mandate producing control-to-standard mappings or audit-ready reports.

Here is the corrected table:

## Criteria Mapping

| DevOps Maturity | Description | SLSA Direction |
|---|---|---|
| **D401** Documented Build Process | Build steps are version-controlled and documented | Provenance completeness — SLSA Build requires provenance (buildDefinition + runDetails) that describes how the artifact was produced; documented build steps support this but are not directly mandated |
| **D402** CI/CD as Code | Pipelines and infrastructure defined as code | Verifiable build definition — supports SLSA's provenance requirement that build inputs be identifiable and reproducible, though SLSA does not explicitly mandate CI/CD-as-code |
| **D403** Artifact Signing | Build artifacts are cryptographically signed | Artifact integrity / provenance distribution — aligns directly with SLSA's requirement for signed attestations so consumers can verify authenticity |
| **D404** Dependency Pinning | All dependencies pinned to exact versions | Provenance dependency information — SLSA records resolved dependencies in provenance on a best-effort basis; completeness expectations increase at higher Build levels but exact pinning is not explicitly mandated |
| **D405** SBOM Generation | Automatically generate Software Bill of Materials | Complementary to SLSA provenance — SLSA Build track does **not** require SBOM generation; SBOMs complement provenance by providing dependency inventory but are not mandated |
| **D603** Compliance Mapping & Auditability | Map controls to standards, provide audit-ready reports | Verifiable attestations — SLSA provides tamper-evident, machine-verifiable attestations as audit evidence; SLSA does not itself mandate control-to-standard mapping or human-readable audit reports |

The D403 row remains essentially unchanged as it was accurate. The others are toned down to reflect what SLSA actually requires vs. what merely aligns with or supports SLSA goals.


## Where They Diverge

SLSA provides detailed requirements that go beyond DevOps Maturity:

- **Build Track** (Levels 1–3): Defines specific requirements for hermetic builds, isolated environments, parameterless builds, and ephemeral builders.
- **Source Track**: Covers source integrity protections (two-person review, branch protection, verified history).
- **Attestation Format**: SLSA defines standardized in-toto attestation formats (provenance, VSA).
- **Verification**: SLSA specifies policy-based verification of attestations.

DevOps Maturity covers areas SLSA does not:

- **Quality** (D2xx): Unit testing, functional testing, code coverage, accessibility.
- **Analysis** (D5xx): Static analysis, dynamic analysis, linting.
- **Reporting** (D6xx): Notifications, attached reports.
- **Security Scanning** (D3xx): Vulnerability and license scanning.

## Practical Path

A team can use DevOps Maturity as a **first-step health check** to identify gaps across the entire DevOps lifecycle. Once the supply-chain security criteria (D4xx) are addressed, SLSA provides the next level of rigor — with verifiable attestations, signed provenance, and policy-based enforcement.

For teams already pursuing SLSA compliance, DevOps Maturity can serve as a **companion assessment** covering the broader practices that SLSA does not address.
31 changes: 30 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,31 @@
[![DevOps Maturity](https://img.shields.io/badge/DevOps%20Maturity-Specification-yellow)](https://devops-maturity.github.io/)
[![Website](https://img.shields.io/website?url=https%3A%2F%2Fdevops-maturity.github.io&up_color=yellow)](https://devops-maturity.github.io/)

The DevOps Maturity specification is standardized to assess the maturity of DevOps practices. It is a set of questions and answers to help you measure and improve your DevOps maturity.
The DevOps Maturity specification is standardized to assess the maturity of DevOps practices. It is a set of criteria to help you measure and improve your DevOps maturity.

> DevOps Maturity is a **broad DevOps baseline assessment**. It does not replace specialized supply-chain security standards like [SLSA](https://slsa.dev/). See the [SLSA mapping](MAPPING-SLSA.md) for where the two frameworks overlap.

## Schema

The assessment file format is defined by a [JSON Schema](schema/devops-maturity.schema.json). Criteria accept both simple boolean values and structured objects with evidence, verification metadata, and rationale:

```yaml
# Simple boolean — quick self-assessment
D101: true
D202: false

# Structured — auditable evidence
D403:
status: true
evidence:
- type: workflow
path: .github/workflows/release.yml
- type: artifact-signature
tool: cosign
verified_by: devops-maturity-action
verified_at: "2026-05-24T00:00:00Z"
rationale: "Release workflow signs artifacts with Cosign keyless signing"
```

## 🎉 Show Your Support

Expand All @@ -17,6 +41,11 @@ Let others know your project follows the DevOps Maturity specification. Add this
[![DevOps Maturity](https://img.shields.io/badge/DevOps%20Maturity-Specification-yellow)](https://devops-maturity.github.io/)
```

## Additional Documents

- **[MAPPING-SLSA.md](MAPPING-SLSA.md)** — Maps DevOps Maturity criteria to SLSA requirements
- **[schema/devops-maturity.schema.json](schema/devops-maturity.schema.json)** — JSON Schema for the assessment YAML format

## 🤝 Contributing

We welcome contributions from the community!
Expand Down
6 changes: 6 additions & 0 deletions content/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,8 @@ layout: single

The DevOps Maturity Specification is a set of guidelines and criteria designed to help organizations assess and improve their DevOps practices. It provides a structured approach to evaluate key areas such as Basics, Quality, Security, Supply Chain Security, Analysis, and Reporting. The specification is intended to align with best practices and provide a framework for continuous improvement within the DevOps community.

> **Note:** DevOps Maturity is a broad DevOps baseline assessment, not a replacement for specialized standards like [SLSA](https://slsa.dev/) (supply-chain integrity) or [OpenSSF Scorecard](https://securityscorecards.dev/) (open-source security health). For supply-chain-specific criteria, see the [SLSA mapping](https://github.com/devops-maturity/spec/blob/main/MAPPING-SLSA.md).

### Key Points

- **Purpose**: Help organizations and teams assess DevOps practices, align on best practices, and drive continuous improvement.
Expand Down Expand Up @@ -123,6 +125,10 @@ Your score will generate one of the following badges:

[OpenSSF Best Practices](https://www.bestpractices.dev/) targets open source projects across the entire software development lifecycle, while DevOps Maturity focuses specifically on DevOps practices applicable to both open source and internal enterprise projects. DevOps Maturity provides both a web UI and a CLI for automatic maturity scoring. In contrast, OpenSSF Best Practices only offers a web-based SaaS and does not support internal deployment.

### How does DevOps Maturity relate to SLSA?

DevOps Maturity does not replace SLSA — it complements it. SLSA is a specialized supply-chain integrity framework with rigorous attestation formats and verification rules. DevOps Maturity covers a wider surface: build, test, quality, security scanning, supply chain, analysis, and reporting. The supply-chain criteria (D4xx) map naturally to SLSA requirements, and teams can use DevOps Maturity as a first-step health check before pursuing deeper SLSA compliance. See the [SLSA mapping](https://github.com/devops-maturity/spec/blob/main/MAPPING-SLSA.md) for details.

### What is the difference between DevOps Maturity Model and DevOps Maturity Specification?

The DevOps Maturity Model is a conceptual framework that outlines the stages of DevOps adoption and maturity, while the DevOps Maturity Specification provides a detailed, actionable set of criteria and guidelines for assessing and improving DevOps practices.
Expand Down
84 changes: 84 additions & 0 deletions schema/devops-maturity.schema.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://devops-maturity.github.io/schema/devops-maturity.schema.json",
"title": "DevOps Maturity Assessment",
"description": "Schema for the devops-maturity.yml assessment file. Supports both simple boolean values and structured evidence objects for each criteria.",
"type": "object",
"required": ["project_name"],
"properties": {
"project_name": {
"type": "string",
"description": "Name of the project being assessed."
},
"project_url": {
"type": "string",
"format": "uri",
"description": "URL of the project repository or homepage."
}
},
"patternProperties": {
"^D[1-6][0-9]{2}$": {
"description": "A criteria entry. Accepts a boolean (true/false) or a structured object with status and optional evidence.",
"oneOf": [
{
"type": "boolean",
"description": "Simple pass/fail for the criteria."
},
{
"type": "object",
"required": ["status"],
"properties": {
"status": {
"type": "boolean",
"description": "Whether the criteria is met."
},
"evidence": {
"type": "array",
"description": "Optional list of evidence items demonstrating how the criteria is met.",
"items": {
"type": "object",
"required": ["type"],
"properties": {
"type": {
"type": "string",
"description": "Evidence type, e.g. workflow, artifact-signature, config, tool, report.",
"examples": ["workflow", "artifact-signature", "config", "tool", "report"]
},
"path": {
"type": "string",
"description": "Path to the relevant file (e.g. CI workflow, config file)."
},
"tool": {
"type": "string",
"description": "Name of the tool used (e.g. cosign, trivy, codeql)."
},
"url": {
"type": "string",
"format": "uri",
"description": "URL pointing to the evidence (e.g. attestation, report)."
}
},
"additionalProperties": true
}
},
"verified_by": {
"type": "string",
"description": "Tool or method that verified this criteria (e.g. devops-maturity-action, manual-review)."
},
"verified_at": {
"type": "string",
"format": "date-time",
"description": "ISO 8601 timestamp of verification."
},
"rationale": {
"type": "string",
"description": "Human-readable explanation of why this criteria is met."
}
},
"additionalProperties": false
}
]
}
},
"additionalProperties": true
}