Inventory, enrollment, policy, and history are first-class state — not implied by YAML contents.
WHY KANGL
Detection is solved. Operations are not.
Enterprises do not fail at finding vulnerabilities — they fail at operating detection across hundreds of pipelines, multiple scanners, and real organizational boundaries. Kangl exists for that gap: the control plane between Azure DevOps and the security tools you already trust.
THE GAP NOBODY OWNS
Scanners own detection.
Platform teams own throughput.
Who owns the layer between?
Which pipelines run which security steps, under what policy, with what credentials, recorded where — in most organizations that work is filled by scripts, spreadsheets, and one overloaded engineer. Kangl turns that accidental infrastructure into a product: stateful, authoritative, reconciling, tenant-isolated, and deliberately scanner-neutral.
Decisions computed in the backend and projected to pipelines and PRs. Clients render; they don't re-decide.
Desired state versus observed state, continuously — with drift surfaced and repair audited.
No first-party scanner, ever. Your detection stack stays best-of-breed and replaceable.
PROBLEM 01 · COVERAGE
Nobody can say which pipelines actually scan
Scanners were rolled out by invitation: some teams added the task, some didn't, some removed it during a refactor. The coverage 'list' is a wiki page last edited two reorgs ago. New pipelines are born unscanned by default.
How to enforce scanning across hundreds of pipelines →HOW KANGL SOLVES IT
- Continuous discovery of every Azure DevOps organization, project, repository, and build pipeline — YAML and classic.
- Eligibility classification and enrollment held as first-class state in the control plane, not implied by YAML contents.
- Kangl Pipeline Security Runtime: coverage becomes the default, exclusion becomes a visible, governed decision.
- A denominator you can defend: enrolled, excluded-with-reason, or unaccounted — nothing invisible.
PROBLEM 02 · DRIFT
Security configuration silently rots
A template refactor drops the scan step. A cloned pipeline never inherited it. A 'temporary' disable outlives the incident. Nothing fails — builds just go green faster — so the first person to notice is an auditor.
The reconciliation loop for pipeline security →HOW KANGL SOLVES IT
- Desired state (enrollment, Security Runtime settings, policy mode) held centrally and versioned.
- Scheduled synchronization observes what Azure DevOps and the provider actually show.
- Divergence surfaces as drift attached to the specific pipeline — not a vague health warning.
- Force Sync repairs the estate as a deliberate, audited action. Never silently, never behind your back.
PROBLEM 03 · POLICY
Thresholds are suggestions, not decisions
Every tool has its own threshold UI; every team edits its own YAML. 'High severity blocks the build' is true in some pipelines, on some days. In an incident review nobody can state what the policy was at release time.
Why UI toggles are not governance →HOW KANGL SOLVES IT
- One backend-authoritative policy engine: thresholds and modes stored, versioned, and evaluated server-side.
- Explicit verdicts per pipeline run — FAIL BUILD or monitor — projected to build gates and PR statuses alike.
- Teams see exactly why a build failed; they cannot silently re-decide it.
- Every policy change and every verdict lands in the audit history with actor and timestamp.
PROBLEM 04 · OPERATIONS
Provider operations are manual, fragile toil
Mapping scanner organizations to projects, provisioning projects for new repos, managing Security Runtime settings, enabling five hundred pipelines, rotating credentials — all done through vendor consoles and one-off scripts owned by whoever wrote them.
Operating Snyk at enterprise scale →HOW KANGL SOLVES IT
- Providers operated as managed integrations: connect, validate, map, provision, repair — from one plane.
- Bulk operations across hundreds of pipelines as governed actions with a record, not API loops with no rollback story.
- A global kill switch for emergencies, with per-pipeline disable beneath it for isolated issues.
- Snyk production-supported today; the provider contract is what the ecosystem grows on.
PROBLEM 05 · POSTURE
“What is our posture?” takes a week and a spreadsheet
Every scanner counts severity its own way against its own inventory. Dashboards that call vendor APIs live are slow and rate-limited, so people stop opening them. Leadership gets a quarterly CSV that was stale on arrival.
Normalizing posture across scanners →HOW KANGL SOLVES IT
- Findings synchronized asynchronously into a normalized, repository-level read model keyed to your estate.
- One severity scale with explicit provider mappings; freshness tracked per source so stale data is visible, not silently wrong.
- Posture answers in milliseconds from the read model — no vendor API call per table row.
- The same model feeds the policy engine, so what you see is what gates builds.
PROBLEM 06 · CREDENTIALS
Scanner tokens leak into pipelines, queues, and logs
Provider tokens live in variable groups readable by broad scopes, get echoed by debug steps, ride along in webhook payloads, and outlive the admin who created them. Each one is a production credential wearing a convenience costume.
Keeping credentials out of pipelines →HOW KANGL SOLVES IT
- Provider credentials stored as references to managed secret storage (Azure Key Vault), never as values in app surfaces.
- Server-side resolution at the controlled boundary where the provider call happens — pipelines never see the token.
- Queue messages carry tenant and job context only. Never secrets.
- Rotation as an audited operational action, not an archaeology project.
PROBLEM 07 · EVIDENCE
Audits ask questions your stack cannot answer
Who disabled scanning on this pipeline and why? What was the enforcement policy on release day? Who rotated this credential? The answers are scattered across vendor logs, YAML history, and deleted Slack threads.
What compliance actually needs →HOW KANGL SOLVES IT
- Every consequential operation — connection changes, credential rotations, Security Runtime settings, enable/disable, bulk actions, policy changes, sync runs — written to a durable audit history.
- Actor, target, tenant, and correlation ID on every record.
- Tenant-scoped queries: evidence per customer or business unit without exposing the others.
- Compliance evidence becomes a query, not a quarter-end scramble.
PROBLEM 08 · SCALE
Many estates, one team — and no safe way to run both
Platform teams, MSPs, and holding companies operate AppSec for many organizations. Shared dashboards leak across boundaries; per-tenant silos multiply every operating cost by the tenant count.
Governing many organizations without merging them →HOW KANGL SOLVES IT
- Multi-tenant by architecture: tenant-partitioned data with row-level security enforced in the database itself.
- Per-tenant provider connections, credentials, and policies — never pooled.
- A separate owner console for fleet operations, provisioning, and plans, acting through controlled, audited paths.
- One deployment, many estates, no blurred boundaries.
SECURITY OPERATIONS, UNIFIED
Bring your security tools.
Kangl makes them one platform.
Start with seven days of full plan access — or see it live with our team first.