Let other teams contribute through a documented route: a pull request to the platform repository, reviewed by the owners, covered by tests, and released under a version. Clear interfaces and a contribution guide keep the platform team from becoming a bottleneck while still protecting shared security checks.
Why open it up
DORA says a central platform team cannot and should not build everything. A successful platform must be designed for extensibility, allowing other teams to contribute their own tools and services in a standardized way. It recommends clear APIs and a well defined contribution model, so domain expertise from other teams can be used and the platform team does not become a bottleneck.
The CNCF platforms white paper makes a similar point from the other direction: platform capabilities can be backed by other internal teams or managed providers, with the platform acting as the thinnest reasonable layer on top.
What teams might contribute
- A variant of the template for a new language.
- A check for a framework used by one team.
- A fix to a message that confused them.
- A policy tuned for a data heavy workload.
A contribution model
| Step | What happens |
|---|---|
| Propose | Open an issue describing the problem and the team affected |
| Build | Make the change in a branch of the platform repository |
| Test | Run policy tests and a sample pipeline run |
| Review | Platform owners review, and security reviews anything touching checks |
| Release | Publish under a new version, with a changelog |
| Adopt | Other teams move to the new version when ready |
Protecting the shared checks
Opening the road does not mean letting anyone weaken it. Protect the parts that matter:
- Review rules. Require approval from named owners for changes to security steps and policies. A code owners file is a common way to enforce this.
- Tests. Require policy tests to pass, as described in our post on unit testing policy rules.
- Separate extension points. Let teams add checks, but do not let them silently remove the baseline ones.
- Version everything. A bad change should be revertible by moving back a version.
- Record who changed what. The repository history is your audit trail.
A guide for contributors
Write a one page contributing guide. Cover how to set up a local test, what the review criteria are, how long a review takes, and who to ask. A contribution that waits for weeks teaches people not to contribute.
Avoid the other failure
If every request goes through the platform team, DORA calls the pattern ticket ops, and says it keeps the team trapped in toil. A contribution route is the cure. It also builds goodwill: teams that have shaped the road are more likely to use it.
Where Safeguard fits
Safeguard's policies, gates and guardrails can enforce baseline rules even where teams add their own checks, so shared controls stay in place while teams extend the road. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should anyone be able to merge into the platform repository?
No. Anyone can propose, but named owners should approve, especially for changes that touch security steps.
How do I stop a contribution from weakening a baseline check?
Separate baseline checks from extensions, protect the baseline with required reviewers, and run tests on every change.
Sources
Last reviewed: 19 October 2026.
