Solution Atlas
EverydayUser storyConsultative playbook

Our regulator is going to ask about supply-chain security and we have no answer

After the recent wave of supply-chain attacks, the CISO needs an audit-defensible answer for what is in production. GitHub Advanced Security would surface vulnerabilities, secret leaks, and dependency risks — but the team is split across GitHub and Azure DevOps and adoption is uneven.

Trigger
Regulator interest in supply-chain risk; recent industry incidents.
Good outcome
GHAS live across repos, CodeQL findings triaged, secret scanning enforced, supply-chain attestations produced for production releases.
Diagnostic discovery

Signals this story fits

Observable cues that confirm the conversation belongs here.

  • ·Recent industry supply-chain incidents driving board attention
  • ·Cyber-insurance renewal flagging supply-chain controls
  • ·Auditor or customer asking for SBOM / attestation
  • ·Mixed estate of GitHub and Azure DevOps repositories
  • ·No central vulnerability triage cadence

Questions to ask

Open-ended, SPIN-style — each one has a reason it matters.

  1. 1.What does your code repository estate look like — GitHub Enterprise, Azure DevOps, Bitbucket, self-hosted?

    WhySizes the surface. Mixed estates are common and shape the adoption story.

    Listen for: “mix” · “historical reasons” · “team-by-team”

  2. 2.What is your current vulnerability scanning posture — secret scanning, dependency, SAST?

    WhyTests baseline maturity. Often partial or repo-by-repo.

  3. 3.How long does it take to triage a vulnerability finding today?

    WhyOften "weeks if at all" — the operational cost of the gap.

  4. 4.What does your build pipeline produce — signed artefacts, SBOMs, attestations?

    WhyDistinguishes "we have CI/CD" from "we have supply-chain integrity."

  5. 5.Who owns supply-chain security today — AppSec team, DevOps, distributed?

    WhyOwnership is the maturity threshold. "Nobody yet" is the common honest answer.

  6. 6.Have you been asked for an SBOM or signed attestation by a customer or regulator?

    WhyForcing-function signal. Shifts the conversation from "should we" to "we already need to."

Baseline → target architecture

TOGAF-style gap framing — what we typically see today, and what the proposed end state looks like. The gap between them is the engagement.

Baseline architecture

Code split across GitHub and Azure DevOps with inconsistent governance. Vulnerability scanning patchy and repo-by-repo. Secret scanning informal where it exists. No SBOM production or signed attestations. AppSec team scattered or absent; triage cadence reactive.

Typical concerns

  • ·Vulnerabilities discovered after exploitation, not before release
  • ·Secret leakage incidents not surfaced until external pressure
  • ·Auditor or customer requests for SBOM unanswerable
  • ·Dependency risk invisible to engineering teams
  • ·AppSec capacity insufficient for distributed scanning model

Capability gaps

  • ·GitHub Advanced Security enabled tenant-wide
  • ·CodeQL SAST, secret scanning, dependency review
  • ·Defender for DevOps unifying findings into the cloud posture
  • ·SBOM and attestation production in CI
  • ·AppSec triage cadence operating across teams
Target architecture

GitHub Advanced Security enabled across production-critical repos. CodeQL performs SAST in CI. Secret scanning runs continuously, with push protection enforced. Dependency review gates PR merges on high-severity vulnerabilities. Defender for DevOps connects GHAS findings into Defender for Cloud so security posture is unified across code and runtime. SBOM produced for every production release via GitHub Actions. AppSec team runs a weekly triage cadence with engineering.

Key capabilities

  • GHAS tenant-wide on production-critical repos
  • Continuous secret scanning with push protection
  • CodeQL SAST in CI
  • Defender for DevOps unifies code + runtime posture
  • SBOM and signed attestations for production releases

Enabling SKUs

Resolved in the ‘Recommended cards’ section below.

Architecture decisions

Each decision is offered as explicit options with trade-offs — Hohpe's “selling options” principle. A safe default is noted where one exists.

  1. Decision 1.GHAS scope — all repos vs production-critical only

    All repos

    When it fitsEngineering org committed to security baseline; per-committer cost acceptable.

    Trade-offsGHAS per-committer pricing scales with the estate.

    Production-critical only

    When it fitsCost-sensitive; phased rollout; clear definition of "production".

    Trade-offsNon-production repos remain a risk surface.

    Default recommendationProduction-critical for the first 6 months; expand as findings show ROI.

  2. Decision 2.Source-control strategy — keep mixed GitHub/ADO vs consolidate to GitHub

    Keep mixed

    When it fitsADO has years of investment; mature pipelines; cost of migration high.

    Trade-offsTwo security baselines to maintain.

    Consolidate to GitHub

    When it fitsGHAS adoption is strategic; appetite for migration; Copilot integration desired.

    Trade-offsMigration cost; engineering retraining.

    Default recommendationConsolidate to GitHub at a natural inflection (large project, team reorganisation). Don't force a migration just for GHAS.

  3. Decision 3.CodeQL — rely on GitHub-provided queries vs build internal queries

    Provided queries only

    When it fitsStandard application stack; no domain-specific vulnerability patterns.

    Trade-offsSome org-specific patterns missed.

    Internal queries layered on provided

    When it fitsMature AppSec team; domain-specific vulnerability patterns (e.g. financial-services-specific).

    Trade-offsQuery authoring effort; ongoing maintenance.

    Default recommendationProvided queries for the first 12 months; build internal queries only where domain knowledge demands it.

Low-risk trial — proof of value

6-week GHAS rollout on 10 production-critical repos + Defender for DevOps

6 weeks

GitHub Advanced Security enabled on 10 production-critical repos. CodeQL configured for the relevant languages. Secret scanning with push protection live. Dependency review gating PRs on high-severity findings. Defender for DevOps connector configured so GHAS findings flow into Defender for Cloud. AppSec triage cadence established with engineering owners.

Success criteria

  • 10 repos onboarded to GHAS with policy compliance above 90%
  • CodeQL producing actionable findings (not noise) on at least three repos
  • Push protection blocking at least one real secret-leak event
  • Triage cadence operating with engineering owners present

InvestmentGHAS ~€45/committer/month for the trial cohort (~30 committers typical) plus Defender for DevOps free preview. Estimated ~€1.5–2k/month for the trial scope.

Proof metrics

  • ·Time-to-triage on new vulnerabilities measurable and trending down
  • ·Secret-leak push-protection events captured pre-merge
  • ·Defender for Cloud secure-score incorporating DevOps findings
  • ·SBOM produced for one production release end-to-end

Recommended cards

The SKUs and capabilities most likely to be part of the solution, with the editorial rationale for each in the context of this story. Add the ones that fit your situation.

Why for this story

Hosts the code; Advanced Security provides CodeQL SAST, secret scanning, and dependency review. Push protection blocks secret leaks before they reach the repo.

Why for this story

Defender for DevOps connects GHAS findings into the unified cloud posture surface. Engineering vulnerabilities and runtime posture appear in one secure-score view.

Back to Application & code security