Detect security control bypass and configuration drift
Implementation Effort: Medium – Building bypass and drift detection from posture, audit, and CodeQL signals and routing findings to owners is a multi-step effort across security and platform teams. User Impact: Low – Monitoring for control bypass and configuration drift is a security and platform monitoring activity; end users are not affected. Lifecycle Stage: Govern
Overview
Continuously detect when developers or teams bypass required DevSecOps controls, and when previously compliant repositories and pipelines drift out of their secure baseline, so the program can catch gaps where they actually happen instead of assuming the pipeline is always taken.
A well-designed set of controls — code scanning, secret scanning, branch protection, required reviews, signed commits, hardened deployment paths — only reduces risk for the repositories and pipelines that actually have them turned on and keep them on. In practice, controls get disabled or worked around: a repository is created without GitHub Advanced Security enabled, branch protection or a ruleset is loosened to unblock a release, a required check is marked as not required, push protection is bypassed with an exception, or a change reaches production directly instead of through the governed pipeline. Reviewers consistently ask "how do we catch the developers who skip some or all of this?" The answer is to treat bypass and drift as first-class signals and monitor for them deliberately.
Build detection from the inventory and posture sources the program already has. Microsoft Defender for Cloud DevOps security surfaces posture findings such as repositories without code scanning, weak branch protection, and exposed secrets across connected GitHub and Azure DevOps environments; use these against the asset registry to find assets that are in scope but not compliant. In GitHub, use the security overview, rulesets and their insights, and the audit log to detect disabled security features, ruleset changes, push-protection bypasses, and dismissed alerts. In Azure DevOps, use Advanced Security status and auditing to find projects and repositories where scanning is off or policies were relaxed. Forward these audit and posture signals into the centralized dashboards and SIEM so a bypass generates a tracked, owned alert rather than a silent gap.
Pair posture monitoring with code-level detection of insecure anti-patterns. Custom CodeQL query packs can flag organization-defined anti-patterns — for example, code that rolls its own authentication or token handling instead of using the approved Microsoft Authentication Library (MSAL), uses banned cryptographic primitives, or calls deprecated internal APIs — so teams that route around approved frameworks are caught in the same code scanning experience developers already use. This aligns with Microsoft Security Development Lifecycle practice 2, "Require use of proven security features, languages, and frameworks."
Detection without follow-through changes nothing. Route every bypass and drift finding to the owning team identified in the asset registry, set expectations for remediation or a time-boxed, approved exception, and feed unresolved items into the remediation campaigns and KPIs the program already tracks. Without this monitoring layer, an organization cannot know whether its controls are actually in force, and threat actors gain a foothold precisely in the repositories and pipelines that quietly fell out of compliance.
Continuously detecting bypass and drift applies the Assume breach principle — never assuming a control stays enabled — and supports Verify explicitly by re-checking every repository and pipeline against its secure baseline rather than trusting a one-time configuration.