GitHub Security Features And Alert Response

Use GitHub's official documentation for current platform behavior. GitHub documents Dependabot alerts, secret scanning, code scanning, and security advisories. Which features are free, which require GitHub Advanced Security, and exact configuration screens change; the stable lesson is what each signal means and how to build a response process around it.

Three Different Detectors

The three features answer three different questions, and conflating them is the most common mistake:

• Dependabot alerts ask "does a dependency I've declared have a known vulnerability?" It compares your composer.lock (and other manifests) against public vulnerability databases and opens an alert per affected dependency, with a severity and, often, a suggested fixed version. Dependabot can also open pull requests that bump the version automatically.
• Secret scanning asks "did a credential get committed to this repository?" It pattern-matches commits (and, on public repos and with push protection enabled, pushes themselves) against known secret formats — API keys, tokens, private keys — and can also partner with providers to auto-revoke some leaked credentials.
• Code scanning (commonly powered by CodeQL) asks "does the code itself contain a known vulnerability pattern?" — SQL built from unescaped input, a deserialization sink, a path traversal shape — by analyzing the code, not the dependency graph or the commit history.

A project can have a clean Dependabot tab, a clean secret-scanning tab, and still ship a SQL injection that only code scanning would catch, or the reverse. Treat the three as complementary, not redundant.

Dependabot In A PHP Project

For Composer-based PHP projects, Dependabot reads composer.json/composer.lock and cross-references the advisory database. A typical alert names the vulnerable package, the vulnerable version range, the patched version, and a severity. The response is one of a small set of moves:

• Upgrade to the patched version — the default, correct response when the fix is a drop-in replacement.
• Pin and mitigate when the patched version has breaking changes you can't absorb immediately — apply a compensating control (disable the vulnerable code path, add input validation upstream) and track the upgrade as follow-up work, not as closed.
• Dismiss with a reason when the vulnerable code path is genuinely unreachable in your application (a vulnerability in a CLI tool your project depends on but never invokes) — GitHub records dismissal reasons, and a dismissal without one is indistinguishable from an alert nobody read.

Dependabot can also be configured (via a dependabot.yml file) to open version-bump pull requests automatically on a schedule, separate from security alerts — useful for staying current, but a bot-opened PR still needs the same review and CI gate as a human-authored one; auto-merging dependency bumps without tests is how a "routine" update becomes an outage.

Secret Scanning And Push Protection

A secret committed to Git history is compromised the moment it's pushed, regardless of whether it's later removed — anyone who cloned or fetched in between has it, and Git history retains it unless the history itself is rewritten. Secret scanning exists because "don't commit secrets" is a rule people break under deadline pressure, not a rule that needs re-teaching.

Two distinct capabilities matter:

• Detection finds secrets already in the repository's history and raises an alert.
• Push protection (where enabled) blocks the push before the secret lands in history at all — the better outcome, since it prevents the leak instead of reacting to it.

When a real secret is found, the response is not "delete the file and commit again" — the old commit still exists in history and is still fetchable. The response is: rotate the credential first, treating it as compromised regardless of whether anyone is known to have used it; only after rotation does cleaning history (if the repository is public or history exposure itself is a concern) become worth the disruption of a force-push. Rotation is the step that actually removes the risk; history cleanup is hygiene that only matters afterward.

Code Scanning And CodeQL

Code scanning runs static analysis against your source and flags patterns known to be exploitable — the code-level equivalent of what the security-review skill's static-analysis pass looks for, but running automatically on every push and pull request. For PHP specifically, look for CodeQL's PHP query support and any framework-aware static analyzers you already run (PHPStan security-focused rulesets, Psalm's taint analysis) and wire whichever apply into the same security tab or CI gate so findings live in one place.

A typical setup runs code scanning as a required check on pull requests:

name: CodeQL

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: php
      - uses: github/codeql-action/analyze@v3

Findings appear as annotations on the pull request and in the repository's security tab, with severity and a description of the pattern matched. Like Dependabot, each finding needs a real disposition — fixed, mitigated, or dismissed with a reason — not just visibility.

Triage: Turning Alerts Into A Workflow

An alert nobody owns is not a control, it's a dashboard. A working triage process names:

• Who is notified. GitHub can route alerts by CODEOWNERS or team configuration; confirm the right people actually receive them, not just whoever set up the feature originally.
• How fast, by severity. A critical remote-code-execution alert on a production dependency deserves a same-day response; a low-severity alert on a dev-only tool can wait for the next sprint. Write the SLA down so "we'll get to it" isn't the default for everything.
• What "resolved" means. Merged fix, verified mitigation, or a documented, time-bounded acceptance of risk — not just a closed tab.
• Where the decision is recorded. A dismissal reason, a linked issue, or a comment on the alert itself — so six months later, someone can tell whether an old alert was actually assessed or just ignored.

Failure Modes

The most common failure is enabled but unowned: someone turns on Dependabot, secret scanning, and code scanning during initial repository setup, and no process exists for what happens when they fire. The features report faithfully; nobody reads the report.

The second is alert fatigue from noise: a repository with hundreds of low-severity alerts on transitive dependencies trains reviewers to stop looking, which means the one critical alert buried in the list gets the same treatment as the routine ones. Triage severity aggressively and suppress what's genuinely not actionable, rather than letting volume erode attention.

The third is treating a green security tab as proof of safety. These are automated pattern-matchers against known signatures and known code shapes — they don't find novel vulnerabilities, logic errors, or business-logic authorization bugs. A clean Dependabot and CodeQL run says "no known problems of the kinds these tools check," not "this application is secure."

The fourth is secret leaks handled as a file deletion instead of a rotation. Removing a committed secret from the current file state without rotating the credential leaves the actual exposure open — the credential in the old commit still works.

Review Checklist

• Dependabot, secret scanning, and code scanning are all enabled, and someone can name who is notified when each fires.
• A written (even if brief) triage SLA exists per severity level, and recent alerts show it being followed rather than accumulating unaddressed.
• Push protection is enabled where available, so secrets are blocked before they enter history, not just detected after.
• At least one past secret-scanning alert can be traced to an actual credential rotation, not just a commit removing the file.
• Code-scanning findings on recent pull requests were given a real disposition (fixed/mitigated/dismissed with reason), not silently merged past.
• The team can articulate what these three tools do not catch, so a clean security tab isn't mistaken for a completed security review.

What You Should Be Able To Do

After this lesson, you should be able to explain what Dependabot alerts, secret scanning, and code scanning each detect and don't detect, configure them for a PHP/Composer project, design a triage process that turns alerts into owned decisions with an SLA, and correctly respond to a leaked secret by rotating the credential first rather than treating history cleanup as the fix.

name: CodeQL

on:
  workflow_dispatch:

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: php
      - uses: github/codeql-action/analyze@v3

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]