Controls
osfi-gate has no opinion about your controls. It evaluates a policy your second line owns and
versions in Git, and records what that policy decided. What follows is the shipped reference
policy — 23 controls across four guidelines. Change the policy and this changes with it, which
is the point.
The families
| Prefix | Anchored to | What it covers |
|---|---|---|
CM |
B-13 §2.5, §3.2 | Change management: independent approvals, segregation of duties, branch protection, signed commits, traceability |
SD |
B-13 §2.4 | Static analysis findings at a blocking severity |
VM |
B-13 §2.6, §3.1 | Vulnerabilities older than the SLA for their severity |
AM |
B-13 §2.2 | The CycloneDX SBOM: present, parseable, non-empty |
SC |
B-13 §3.2 | Secret material, and cryptography that is no longer approved |
CB |
B-13 §2.1, §3.2 | Infrastructure-as-code baseline: encryption, public access, logging |
TP |
B-10 | Third party: licence constraints, dependency pinning and provenance |
OR |
E-21, B-13 §2.9 | Operational resilience: DR tiering and multi-AZ for critical resources |
MR |
E-23 | Model risk: inventory, residency, version pinning, materiality, required controls, independent validation |
WV |
B-13 §1 | Waiver governance: term limits, and risk approval on changes to waivers/ |
EV |
B-13 §1 | Evidence completeness: every required scanner actually ran |
The control-by-control table — what each one is, and the exact condition that fails it — is
in the documentation, generated from the same mapping.yaml the gate
reads.
Deny is not warn
A control that warns is not a control that blocks, and a coverage table that renders both as a tick is the kind of thing this project exists to stop. Two places in the reference policy where the distinction is load-bearing:
- MR-02 (AI usage registered). Only AI usage the change introduces blocks. Pre-existing unregistered usage warns, so enrolling a repository with an existing estate does not stop every build on day one — and it stays visible instead of being waived away.
- CB-01 (IaC baseline). A baseline Checkov ID blocks. Other Checkov checks are medium, and medium does not block.
The thresholds that decide it
These are policy values, not product behaviour. They are what the reference policy ships with:
| Setting | Value |
|---|---|
| Independent approvals required | 2 |
| Severities that block | critical, high |
| Vulnerability SLA, in days | critical 7 · high 30 · medium 90 · low 180 |
| Maximum waiver term | 180 days |
| Who may approve a waiver | risk-officer, risk-lead |
| Denied licences | GPL, AGPL, LGPL, SSPL, EUPL, OSL, CC-BY-NC families |
What a control records
Every decision carries the scanner output it was made from, the digest and the git commit of the policy that made it, and the inputs needed to reach it again. That is what makes a decision replayable rather than merely logged — see the audit trail.
A control that could not be evaluated is reported as unknown, never as passing. A review that quietly turned "I could not see" into "nothing found" would produce a clean report with a signature under it, which is worse than not running one.