Controls and Evidence
The platform is developed in public. Most controls below are enforced by configuration that anyone can inspect and leave records that anyone can read; the Where column marks the exceptions.
Each row names a control, what enforces it, and where its evidence lives. The Where column marks whether that evidence is publicly inspectable or available on request. Identifiers are stable: a control is never renumbered or reused, so a citation against DL-07 today still points at the same control tomorrow.
| Control | Requirement | Enforced by | Evidence, and where to find it | Where |
|---|---|---|---|---|
| DL-01 Published lifecycle | The development lifecycle is defined, published, and applies to every contribution. | Published policy | This section, and the organization's contribution guidelines | Public |
| DL-02 Work item and traceability | Every change originates from a recorded work item carrying its purpose and, for work that adds or changes functionality, its acceptance criteria, linked to the change that implements it. | Work item templates, whose required fields differ by work-item type; automation links the work item to the change | The work item and its link to the change | Public |
| DL-03 Pull-request-only path | A change reaches the default branch only through a pull request; direct pushes, force pushes and branch deletion are refused. | Branch rule set — automated | The rule set of the repository, and the history of its default branch | Public |
| DL-04 Independent approval | A change is accepted only after approval by someone other than its author, including an owner of the affected code; approval lapses when new commits are pushed, and unresolved review comments block acceptance. | Branch rule set — automated, and not satisfiable by the author | The review record on every merged pull request, and the rule set | Public |
| DL-05 Commit sign-off | Every commit carries a Developer Certificate of Origin sign-off, verified automatically. | Required status check — automated | The sign-off trailer on every commit, and the check result on every pull request | Public |
| DL-06 Declared required checks | The automated checks that must pass before acceptance are declared per repository as enforced configuration, and a change cannot be accepted on a stale base. | Branch rule set in strict mode — automated | The rule set, which names the checks currently required, and the check results on each pull request | Public |
| DL-07 Build and tests | Every change is built and its automated tests executed before acceptance. | Required status checks — automated | The check results and their logs on every pull request | Public |
| DL-08 Static security analysis | Static application security testing runs on every change and on a recurring schedule; findings at or above a declared severity block acceptance. | Branch rule set code-scanning gate with declared thresholds — automated | The thresholds declared in the rule set, and the gate result on each pull request | Rule set and results public; finding detail on request |
| DL-09 Code quality gate | Code quality is measured on every change against a declared gate. | Required status check and code-quality rule — automated | The rule set, and the check result on each pull request | Public |
| DL-10 Secret detection | Committed secrets are detected, and pushes carrying them are refused. | Repository security configuration — automated | The repository's security configuration | On request |
| DL-11 Integrated verification | The integrated platform is verified functionally beyond the individual change, on environments created for the change and on a schedule. | Pipeline definitions — automated | The workflow definitions and their run history, with the report retained against each run | Public |
| DL-12 Constraints and decomposition | Work item templates provide a section for security and compliance constraints, and triage rules block an epic that is not decomposed into sub-issues before it leaves analysis. | Work item templates, and triage rules for decomposition — human | The work item's constraints section, and its decomposition into sub-issues | Public |
| DL-13 Dependency monitoring | Third-party dependencies are monitored for known vulnerabilities and available updates; updates are delivered through the normal reviewed change flow. | Dependency update automation — automated, with human review of each update | The dependency update pull requests in each repository | Public |
| DL-14 Bill of materials and provenance | Every published container image digest carries a machine-readable bill of materials and a build provenance attestation, and each release publishes a bill of materials alongside its artifacts. | Shared release pipeline — automated | SPDX bill-of-materials and SLSA provenance attestations on each published container image digest, and an SPDX bill of materials published with each release | Release artifacts public; container attestations require access to the container registry the release is published to |
| DL-15 Artifact signing | Every published container image digest and tag is cryptographically signed, and each release publishes checksums and signatures alongside its artifacts. | Shared release pipeline — automated | Signatures on every published container image digest and tag, and the checksums and signatures published with each release, verifiable with Sigstore cosign | Signatures on release artifacts public; container signatures require registry access; verification key on request |
| DL-16 Artifact scanning | Published artifacts are scanned for known vulnerabilities and exposed secrets, and publication fails on findings above the declared policy. | Shared release pipeline gate against the organization's scanning policy — automated | The pipeline definition and the policy it enforces, and the scan report retained with each run | Public |
| DL-17 Pipeline integrity | The build pipeline is version-controlled configuration, its third-party actions are pinned to immutable revisions, and releases are built only from it. | Shared reusable workflow with revision-pinned third-party actions — automated | The workflow definitions, their pinned revisions, and the run that produced each release | Public |
| DL-18 Access control | Multi-factor authentication is required of everyone with access to the source repositories; default access is read-only, and write and administrative access are granted explicitly. | Organization security configuration — automated | The organization's security configuration | On request |
| DL-19 Baseline monitoring | Conformance of every repository to the required protection baseline is monitored continuously, and drift is raised publicly. | Organization-wide policy monitoring applied to every repository — automated | The policy configuration, and the issues it opens against a repository that drifts | Public |
| DL-20 Release sign-off | A release is published only after declared sign-off criteria are met, and identifies the exact source revision of every component it contains. | Release sign-off against declared criteria — human; publication automated | The release record and version tag on each participating repository, and the release work item recording the sign-off and any accepted known issues | Public |
| DL-21 Patch releases | Released versions are maintained by patch releases carrying only fixes, so a security fix can be adopted without taking new functionality. | Release policy — human | The release history and release notes of each repository | Public |
| DL-22 Vulnerability intake | A published private intake channel exists for vulnerability reports, with committed acknowledgment and assessment times. | Security policy published once for the project and served by every public repository; private reporting enabled per repository | The security policy of any repository, and the response times it commits to | Public |
| DL-23 Assessment and disclosure | Reported vulnerabilities are assessed for severity, remediated through the normal reviewed change flow, and disclosed in an advisory identifying affected versions. | Vulnerability handling process — human, using the controls above | The advisory list of each repository, where an advisory is published for a vulnerability that has been handled, and the change that remediates it | Public |
| DL-24 Assisted-development accountability | AI assistance may be used in development. An AI-assisted change is subject to every control in this catalog without exception, and a named human author and the independent reviewer who approves it are accountable for it. | The controls above apply without distinction; sign-off is enforced by DL-05 Commit sign-off and approval by an independent reviewer is enforced by DL-04 Independent approval | The same records as any other change — the work item, the pull request, the review, and the sign-off trailer | Public |
| DL-25 Record retention | The records produced by these controls are retained in the repositories and workflow runs that produce them. | Repositories and workflow runs | The records named throughout this catalog, in the repository or workflow run that produced each one | Varies by control; those marked Public above are readable without the project's involvement |
| DL-26 Acceptance verification | A change is accepted into the default branch only after it has been verified against its acceptance criteria by someone other than its author. | Verification before merge — human | The verification recorded on the pull request, and the work item's status history | Public |
A control's evidence deliberately names the configuration that enforces it, not the product that implements it — the configuration is authoritative, public, and current.
Evidence marked On request is available from the security address published in the project's security policy.