A review gate.
Not a rubber stamp.
The toolkit separates preparation, automated signals, and human risk acceptance. It never deploys a solution or grants production approval.
Who can do what?
| Role | Responsibility |
|---|---|
| Citizen developer | Submit the request, complete the solution-repository issues, and collect evidence. Non-collaborators can submit requests but cannot trigger privileged cross-repository writes. |
| Governance maintainer | Allowlist exact target repositories, configure narrowly scoped credentials, and authorize /publish or /validate. Default accepted hub permissions: write, maintain, admin. |
| Security / platform / data owners | Review controls in their area, verify live cloud settings, and approve or reject exceptions. |
| Production reviewer | Inspect the report and evidence, confirm residual risks, and apply approved-for-production. Enforce the real release decision through independently protected deployment environments. |
Read the automated report correctly
PASS means the specific signal was observed. FAIL means a required condition was not met. UNKNOWN means permissions, plan, API visibility, or another limit prevented verification. Both FAIL and UNKNOWN block ready-for-review.
- All currently applicable control issues must exist and be closed as completed. “Not planned” and “duplicate” do not pass.
- The API checks secret scanning/push protection settings, Dependabot alerts, a recent successful default-head code scanning analysis, applicable pull-request approval protection, substantive CODEOWNERS/SECURITY.md, .env filenames, and an Azure OIDC workflow pattern.
- These checks do not verify alert dispositions, full Git history, cloud configuration, workflow enablement, actual deployment, bypass actors, or the quality of evidence.
- Scheduled validation runs daily on open requests. Keep requests open while tracking readiness. Request changes and control catalog changes require a fresh intake, which reopens required controls. A new target repository requires a new request.
Reviewer checklist
- Confirm the classification, audience, integrations, runtime AI, hosting, and owners are truthful and current.
- Inspect each control's evidence. Issue closure alone proves nothing about security posture.
- Review scanner findings, secret rotation, dependencies, identity scopes, data lifecycle, and live cloud controls.
- For High risk, confirm independent security and applicable privacy/compliance sign-off.
- Record approval or a rejection with safe links to evidence. Apply
approved-for-productiononly as the human decision record, then use the protected release process.
Handle exceptions explicitly
If a feature is unavailable, or a non-Azure deployment uses an equivalent identity pattern, document the gap, compensating controls, accepting authority, expiry, and review date. The stock automated gate does not turn an exception into a PASS. Governance may separately record a manual decision, or customize a reviewed detector/policy and its tests. Never close an issue to hide an exception.
Review lifecycle requests
Use the publication lifecycle forms and manual review runbooks for scope changes, exceptions, and retirement. Reassess changes through the original publication request to preserve idempotent markers; clear prior approval during review. Exceptions never bypass the automated gate, and decommission requests never perform destructive actions. Each manual request has its own label; do not add publication-request to it.
Check the publication description, requested date, dev/test/prod environment, and required attestations during human review. They are recorded in the source issue only, excluded from automated tiering and the plan fingerprint, and do not relax controls. The form UI requires them, but legacy/API-created or edited issues may omit them; verify manually.
Keep the automation safe
Use an exact repository allowlist and selected-repository App installation or PAT. Protect policy, workflow, and script changes with reviews. Workflows use trusted default-branch code and never execute target repository code. Treat issue text, repository files, and model output as untrusted. Do not add a privileged workflow that checks out a requester's branch.
Product references
Source: REST API endpoints for sub-issues. Native links are attempted; a task-list fallback preserves the plan if the API is unavailable. Source: Branch protection REST API and Repository rules REST API. Review product permissions and plan availability when configuring your instance.