Most AppSec 'policies' are actually distributed suggestions: a threshold in one tool's UI, a flag in a YAML template, an if-statement in a script someone wrote in 2023. Each copy can be edited by whoever can edit that surface, and no two copies agree for long.
Governance requires a different property: one place computes the decision, everything else obeys it.
What backend-authoritative means
- The policy (thresholds, modes, exceptions) is stored and versioned centrally — not in each pipeline.
- Evaluation happens server-side, from normalized findings, producing an explicit decision such as fail the build or monitor only.
- Clients — pipelines, dashboards, portals — render the decision; they cannot recompute or override it.
- Every change to policy and every decision it produces is written to a durable audit history.
What goes wrong without it
Frontend-computed policy can be bypassed by anyone who can edit the frontend's inputs. Pipeline-local policy diverges per team. Tool-local policy fragments across vendors. In an incident review, none of these can answer the question that matters: what was the policy at the time, and who changed it?
How Kangl applies it
Kangl evaluates severity thresholds and pipeline decisions in its backend, against posture normalized from the provider. The pipeline receives an authoritative verdict; the owner console and customer portal display the same verdict; the audit trail records the policy, the change, and the actor. One evaluation point, no forks of the truth.
