GitHub — supply chain at platform scale

This is a real, named company's story, and it sticks to what GitHub has published itself — the GitHub Blog, the GitHub Changelog, GitHub Docs, and the company's own acquisition and feature announcements. GitHub occupies an unusual seat in supply-chain security: it isn't only defending its own product, it's the platform that a huge share of the world's dependency graph physically lives on. That position is what this page is really about. Rather than sell a scanner as an add-on, GitHub built three security capabilities directly into the platform every one of its repositories already sits on — Dependabot (automated dependency-update pull requests), native code scanning built on CodeQL, and a secret-scanning partner program that can get a leaked token revoked before an attacker ever gets to use it. None of the three is "a scanner you install." All three are properties of the platform itself.

A platform that sits at the head of the software supply chain

☺ Like you're 10: GitHub isn't just one company protecting itself — it's protecting the shelf that a huge share of the world's code sits on.

Every other tool this course covers — Semgrep, Trivy, gitleaks — bolts security onto a pipeline someone else built. GitHub's position is structurally different: it is the place the pipeline starts. A vulnerable version of a package, a leaked credential, an unreviewed dependency bump — for a huge fraction of the world's software, all three first become visible on GitHub, because that's where the source, the manifest files, and the commit history already live. That vantage point is what makes the rest of this page possible. GitHub doesn't have to wait for a customer to install an agent and start reporting findings; it can see the dependency graph, the commit diff, and the token pattern at the moment they're created, for every public repository at once.

What GitHub chose to do with that vantage point is the actual case study. It could have kept these capabilities as a single paid add-on sold to enterprises, the way most vendors in this course's tool landscape do. Instead, it split its approach in two: the detection layer for the riskiest, most exposed corner of the ecosystem — public open source — shipped free and on by default, while the same capabilities, wrapped as GitHub Advanced Security (GHAS), became a paid tier for private repositories. That's a real business decision, not pure altruism (more on that in the caveats below), but the technical outcome is genuine: a maintainer with zero security budget gets dependency alerts, code scanning, and secret-scanning protection on a public repo without asking anyone's permission.

Dependabot: turning "you have a vulnerable dependency" into a pull request, not a ticket

☺ Like you're 10: Instead of a report telling you a lock is broken, someone hands you a working new lock, already fitted, ready to install.

Dependabot started life as an independent startup, founded around 2017, before GitHub acquired it in May 2019 and — over the following year — folded it from an external GitHub App into a fully native platform feature. The whole system rests on one piece of infrastructure most teams never look at directly: the dependency graph, visible under a repository's Insights tab, which parses manifest and lockfiles across a long list of ecosystems (npm/yarn, pip, Maven and Gradle, NuGet, RubyGems, Go modules, Composer, Cargo, and more) into a graph of every direct and transitive dependency. Without that graph existing first, nothing else on this page works — you can't alert on what you haven't mapped.

Against that graph, GitHub matches entries from the GitHub Advisory Database (GHSA) — security advisories curated by GitHub's own Security Lab, contributed by the community, and synchronized with the National Vulnerability Database — and raises a Dependabot alert the moment a match lands in your graph. Two separate, layered automations then act on that alert:

• Dependabot security updates — when an alert fires, GitHub opens a pull request that bumps only the affected package to the minimum version that resolves the advisory. No configuration file required; it's a toggle in repository security settings. This is the automation that turns "someone has to notice this CVE and go fix it" into "a PR is already waiting for review."
• Dependabot version updates — a separate, schedule-driven automation, configured explicitly in .github/dependabot.yml, that opens regular PRs to keep dependencies current whether or not a known vulnerability exists yet. This is the less glamorous half of the story, and arguably the more important one: a security update has nowhere safe to land if your lockfile is four major versions behind, because the fix might require breaking changes the maintainers never back-ported. Version updates exist to keep that gap small before it becomes an emergency.

# .github/dependabot.yml — version updates, grouped to cut PR-review fatigue
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    groups:
      minor-and-patch:
        update-types: ["minor", "patch"]

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Notice the third block: Dependabot also updates the pinned versions of GitHub Actions themselves — a detail that matters more than it looks, since a compromised or hijacked third-party Action is exactly the kind of supply-chain foothold covered on container & supply-chain security.

CodeQL and code scanning: semantic analysis as a native, PR-blocking check

☺ Like you're 10: Instead of a separate tool you have to remember to run, the check just lives where the code already lives.

GitHub acquired Semmle — the company behind CodeQL's whole-program, queryable-database approach to static analysis, detailed on this course's own CodeQL page — in September 2019, four months after the Dependabot acquisition. Code scanning, the product that wraps CodeQL into GitHub's own UI, reached general availability in 2020: free for public repositories, and part of GitHub Advanced Security for private ones. For years the setup path required hand-writing a workflow file; GitHub later added default setup, a one-click flow that auto-detects a repo's languages and picks an appropriate query suite without anyone touching YAML. The manual path still exists for teams that want custom query packs or non-default triggers:

# .github/workflows/codeql.yml — the manual path; default setup skips this file entirely
name: "CodeQL"
on:
  push: { branches: [ main ] }
  pull_request: { branches: [ main ] }
  schedule:
    - cron: "30 1 * * 3"

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with: { languages: javascript-typescript }
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

Findings surface both as inline pull-request annotations on the exact changed lines and as durable alerts in the repository's Security tab, encoded in the standard SARIF format so third-party tools can consume the same output. In 2024, GitHub layered Copilot Autofix on top of code-scanning alerts — an AI-suggested patch attached directly to the finding, which a developer can review and apply from the same PR view rather than context-switching to research the fix. It's the same "map first, then automate the remediation" pattern Dependabot already established a few years earlier, applied to SAST findings instead of dependency CVEs.

Secret scanning and the partner program: catching a leak before it's useful

☺ Like you're 10: The instant a spare key shows up somewhere it shouldn't, the door it opens gets changed — often before anyone even goes looking for the key.

Secret scanning launched around 2018, initially as a GitHub Advanced Security capability alongside a beta of what became its most distinctive feature: the secret-scanning partner program. GitHub's scanner recognizes structured token formats belonging to well over a hundred enrolled partners — cloud providers, payment processors, package registries, chat and messaging platforms, and more (check GitHub's current partner list for the exact, still-growing count). When a matching pattern lands in a push to a public repository — or a private one with the feature enabled under GHAS — GitHub calls that partner's own verification endpoint in near real time. The partner independently confirms whether the credential is actually live and, under its own policy, may auto-revoke it and notify the account owner, often within minutes, before a human ever has to triage a GitHub alert at all.

That last detail is the part worth sitting with: GitHub doesn't revoke the token. It can't — it has no relationship with an AWS account or a Stripe account. What it built instead is the notification pipe, and partnered directly with the systems that actually hold the power to act. That's a meaningfully different design than "we found a secret, here's a ticket," and it only works at GitHub's scale because enough token-issuing companies found it worth the integration effort to be listed as a partner.

Push protection: refusing the commit instead of cleaning up after it

☺ Like you're 10: Stopping a letter before it's mailed beats chasing it down after the mail truck has already left.

Push protection moves the same pattern-matching engine one step earlier: instead of scanning a secret after it lands on GitHub, it scans the diff at the moment of git push and rejects the push outright if a high-confidence pattern is found, returning an actionable error straight to the developer's terminal. The distinction matters more than it sounds: a secret that's already in git history has to be treated as compromised even after the offending line is removed in a follow-up commit, because the credential remains readable in history to anyone who already cloned, forked, or mirrored the repository before the cleanup. Push protection avoids creating that history in the first place. It reached general availability and became default-on for public repositories through 2023, and is available as an opt-in, org-wide default for private repositories under GHAS.

Beyond scanning: provenance, attestations, and becoming a CVE Numbering Authority

☺ Like you're 10: It's not enough to check for known problems — GitHub also started proving, cryptographically, exactly where a package came from.

Scanning for known-bad patterns only ever answers half the supply-chain question. The other half is provenance: is this artifact actually what it claims to be? GitHub's answer leans on Sigstore, the same keyless-signing project this course covers on Sigstore & cosign. npm provenance attestations, in beta from 2023, let a published npm package carry a cryptographic, publicly verifiable link back to the exact GitHub Actions workflow run that built it — closing the gap where "the source repo looks fine" told you nothing about whether the published package actually came from that source. GitHub Artifact Attestations generalized the same idea to any Actions build output, reaching general availability in 2024 and producing SLSA-style build provenance without a team having to stand up its own signing infrastructure.

GitHub also inserted itself directly into the vulnerability-disclosure standards chain. In September 2022, GitHub became a CVE Numbering Authority (CNA) — a status that lets it assign CVE identifiers directly to vulnerabilities reported through GitHub Security Advisories in open-source projects it hosts, shortening the path from "a maintainer confirms a real vulnerability" to "a CVE exists and Dependabot alerts fire for every affected downstream repo," without that report first waiting in a queue at MITRE or NVD. Underneath both of these moves sits the GitHub Security Lab, a dedicated research team that finds and responsibly discloses vulnerabilities in major open-source projects and runs a public bug bounty, and GitHub's own founding membership — alongside Google, Microsoft, IBM, and others — in the Open Source Security Foundation (OpenSSF), formed under the Linux Foundation in 2020, which co-funds ecosystem-wide tooling like the OSSF Scorecard project covered in this course's broader software bills of materials material.

What GitHub has published about the outcomes

☺ Like you're 10: GitHub has said a lot about how well this works — treat that the way you'd treat any company grading its own homework.

As with any self-reported figures, treat what follows as evidence the approach clearly works at scale, not as independently audited numbers with a published methodology — the same caution this course applies to any vendor's own claims about its tooling, and the same caution the Netflix case study in the Platform Engineering course applies to Netflix's own self-reported deploy-frequency numbers.

• Scale of coverage. GitHub's dependency graph and Dependabot alerts run across tens of millions of public repositories and dozens of package ecosystems — GitHub's own Octoverse reports are the place to check the current, growing figures rather than treating any single year's snapshot as still accurate.
• Speed of partner revocation. GitHub's own posts on the secret-scanning partner program describe partner-side revocation completing in minutes for many token types once a match is confirmed — a meaningfully different outcome than a manual audit finding the same leak weeks or months later.
• A growing partner list. The number of partner services enrolled in secret scanning has grown steadily since the program's 2018 beta into the hundreds of recognized token patterns; GitHub's own secret-scanning partner documentation lists the current, up-to-date count.
• Standards-chain participation, not just tooling. Becoming a CVE Numbering Authority and a founding OpenSSF member are structural moves, not features — they're GitHub choosing to sit inside the actual authority chain for vulnerability identifiers and ecosystem-wide tooling funding, not just building a product that consumes them.

What to steal for your own platform

☺ Like you're 10: You don't need to be the size of GitHub to copy the habits — map first, automate the fix, and partner with whoever can actually pull the plug.

• Separate the map from the action. The dependency graph exists before Dependabot alerts exist, and alerts exist before automated PRs exist. Each layer is useless without the one beneath it — build the inventory first, or "we'll add automation later" has nothing real to automate against.
• Default-on beats a great optional add-on nobody installs. Secret scanning and push protection being free and on by default for public repos protects far more of the ecosystem than the same feature sitting behind an opt-in toggle ever would. A platform team's real job, argued the same way on Platform Engineering for Security Guardrails, is making the secure path the path of least resistance, not merely available.
• Partner with whoever can actually revoke the credential. Detecting a leaked secret is table stakes; GitHub's actual innovation was building relationships with the systems that can act on that detection within minutes. Inside a single company, the equivalent is wiring your own secret scanner directly into your cloud provider's or vault's revocation API, not just opening a ticket — see secrets management for the discipline that makes that wiring possible in the first place.
• Block the commit whenever you can, not just the merge. Push protection is strictly better than after-the-fact scanning wherever it's technically possible, because a secret that never enters git history never needs a rotation-and-cleanup story.
• Use your own vantage point. A platform team inside one company can see patterns across every repo and every team's pipeline the same way GitHub sees them across the whole internet — just at organizational scale instead of ecosystem scale. That cross-repo visibility, not any single scanner, is the actual asset.

Honest caveats: what doesn't transfer

☺ Like you're 10: Even a landlord this good doesn't watch every door for free, and some of the doors still need their own separate lock.

• "Free" is scoped deliberately, and it's also a funnel. The free tier covers public repositories — the corner of the ecosystem GitHub benefits most from defending, and also the one least likely to ever become a paying GHAS customer. Private-repo protection is a genuinely paid product. That's a reasonable business model, not a scandal, but it's worth naming plainly rather than reading the free tier as pure altruism.
• Automated PR volume causes real fatigue. A repository with a stale lockfile can wake up to a flood of Dependabot PRs at once. GitHub's own answer — the groups: key shown above, plus configurable PR limits — helps, but only if a team actually configures it; left on defaults, "helpful automation" becomes noise a team learns to bulk-dismiss, which defeats the entire point.
• Secret-scanning coverage is opt-in per partner and pattern-based. A bespoke internal token format, or a partner that never joined the program, gets none of the auto-revocation benefit — it still needs the discipline this course covers on secrets management plus tools like gitleaks and TruffleHog for anything GitHub's partner list doesn't recognize.
• CodeQL's depth has a cost this course already names. Whole-program semantic analysis is slower and narrower in language coverage than a lightweight, per-file scanner like Semgrep — the exact tradeoff explained on this course's own CodeQL page. Code scanning is not a replacement for every SAST tool in a polyglot org's toolchain.
• None of this activates itself. Even the free public-repo defaults rolled out gradually rather than protecting every repository that ever existed on day one, and every GHAS feature on a private repo requires a team to actually pay for and turn it on. A platform capability nobody enables protects nobody — the same lesson this course's security culture & champions page makes about tooling in general.

Where this connects in the course

☺ Like you're 10: This one company's story touches nearly every module in this course — read whichever matches what you're building next.

The dependency-inventory and remediation mechanics are covered in full on Software Composition Analysis in Depth and Software Bills of Materials. The static-analysis and secrets side of this story is Static Analysis & Secrets Detection, alongside this course's own SAST, DAST & SCA and secrets management pages. The provenance and signing half lives on Sigstore & cosign, and the broader discipline of building guardrails once, centrally, instead of every team re-solving detection alone is Platform Engineering for Security Guardrails. For the other side of this coin — what happens when a known, patchable vulnerability sits unaddressed for months instead of triggering an automated fix — see Equifax — an unpatched dependency; for a supply-chain compromise that succeeded despite scanners existing elsewhere in the industry, see SolarWinds — a supply-chain attack. For the other real-company stories in this reference set, return to the course's tooling landscape page.