Every Azure DevOps modernization plan says 'we are moving everything to YAML.' Every real estate still contains classic build definitions — often the oldest, least-owned, most production-critical ones. A security program that quietly assumes YAML-only coverage writes off exactly the pipelines that need scrutiny most.
Where the two models differ for security
- Definition storage: YAML lives in the repository with code review; classic lives in the service, edited through the UI.
- Change visibility: YAML changes show up in pull requests; classic changes show up in nothing unless you watch audit events.
- Templating: YAML can enforce via required templates; classic has task groups with weaker governance.
- Runtime coverage: Kangl Pipeline Security Runtime can operate across both models through supported Azure DevOps execution mechanisms.
The blind-spot pattern
Teams enforce scanning through YAML templates, declare victory, and never enumerate classic definitions. Coverage dashboards show green because the denominator only counted YAML. The classic pipelines — deploying with elevated service connections, maintained by nobody — keep building unscanned.
Covering the whole estate
The fix starts with an honest inventory: every build pipeline, YAML and classic, classified for eligibility. Kangl discovers both kinds, tracks their enrollment and Security Runtime state uniformly, and applies the same policy and drift repair across them. Classic release pipelines are explicitly unsupported and reported as such — a stated boundary, not a silent gap.
