Topic 63

Dependency and Secret Scanning

Security

GitHub ships three distinct security scanners, and they get conflated constantly. Dependabot watches your dependency manifests for known-vulnerable versions, code scanning (CodeQL) analyzes the source you wrote, and secret scanning catches credentials committed to the repository. They cover three different problems and none of them substitutes for another.

The one worth singling out is push protection, the secret-scanning feature that stops a credential before it ever lands on the remote. Everything else here detects after the fact; push protection is the only one that prevents the leak rather than reporting it.

Dependabot

Dependabot reads your declared dependencies and cross-references the GitHub Advisory Database, raising alerts when a version you depend on has a known vulnerability and opening automated version-bump pull requests to fix it. It covers every ecosystem you enable, including github-actions — which is how you keep your SHA-pinned actions current. What it does not do is look at your own code; it only knows what your manifests declare.

Code Scanning / CodeQL

CodeQL is static analysis that runs as a workflow over the source you wrote, finding injection, authentication, and similar flaws by querying the code as data. Results surface in the Security tab and inline on pull requests. Because it runs as a workflow, you can make it a required status check — and that is what turns a finding from a suggestion into a merge blocker.

Secret Scanning

Secret scanning matches committed content against provider-specific credential patterns — AWS keys, GitHub tokens, Stripe keys, and many more. When a partner-recognized secret is found, the issuing partner is notified so the credential can be revoked. On its own, though, scanning runs after the commit exists, meaning the secret is already in history by the time you hear about it.

Push Protection

Push protection moves the check earlier: it inspects the push for a detected secret and blocks it before it reaches the remote, with an explicit override path for the rare false positive. This is the difference between "rotate the key and rewrite history" and "fix the commit locally and push again." Secret scanning without push protection still leaves you cleaning up a leak that already happened.

Wiring Into PRs

Detection is only useful if it can stop a merge. Make CodeQL a required status check and configure secret scanning and Dependabot alerts as blocking gates so vulnerable code or a committed credential fails the pull request instead of shipping. A scanner whose findings nobody is forced to act on is a dashboard, not a control.

Common Mistakes

Treating Dependabot as a code scanner — it only checks declared dependencies, so flaws in your own source go unseen.
Enabling secret scanning but leaving push protection off, so secrets still land in history and require rotation plus a history rewrite to clean up.
Letting Dependabot PRs pile up untriaged, leaving known-vulnerable dependencies shipping in production for weeks.
Assuming a committed secret is safe once you delete the commit — it remains in history, and anyone with a clone already has it.
Running CodeQL without making it a required check, so flagged vulnerabilities merge anyway.

Best Practices

Enable secret scanning with push protection so credentials are blocked before they reach the remote.
Turn on Dependabot alerts and security updates for every ecosystem, including github-actions.
Run CodeQL code scanning on pull requests and make it a required status check that blocks the merge.
Treat any committed secret as compromised: rotate the credential, do not merely delete the commit.
Triage Dependabot pull requests on a fixed cadence rather than letting them accumulate.

Comparable toolsGitLab built-in dependency scanning, SAST, and secret detection in CI templatesSnyk third-party SCA and SAST that bolts onto any CITrivy open-source dependency and secret scanningSemgrep third-party static analysis for custom rules

Knowledge Check

Which scanner finds vulnerabilities in the source code you wrote?

Code scanning with the CodeQL engine
Dependabot dependency scanning
Secret scanning on committed content
Push protection on the remote

Why does push protection beat post-commit secret scanning?

It blocks the secret before it reaches the remote, so there is no leaked credential in history to rotate and rewrite
It scans a wider range of credential providers than post-commit secret scanning does, recognizing partner token formats that the post-commit pass never inspects on its own
It completes its scan noticeably faster than the post-commit scan does, returning a verdict in the seconds the push is held open rather than minutes later
It notifies the partner credential provider, which post-commit scanning never does

A secret was committed, then the commit was deleted. Is the secret safe?

No — it remains in history and anyone with a clone already has it, so the credential must be rotated
Yes, deleting the commit removes it from the repository and from every existing clone entirely
Yes, as long as the branch holding the commit was never pushed to the remote
Yes, secret scanning automatically purges the leaked value from the whole repository history for you

What does Dependabot cover that CodeQL does not?

Known-vulnerable versions of your declared dependencies, including GitHub Actions
Injection and authentication flaws written directly into your own application source code
Live credentials accidentally committed in plaintext to the repository
Misconfigured branch protection rules on the default branch

You got correct