A dependency alert fires on one of two events: a new advisory is added to the advisory database, or your dependency graph changes. That means your first notice depends on when the advisory is published and reviewed, not on when the flaw was found. Knowing this tells you which stage of the exposure window you cannot control.
The two triggers
GitHub's Dependabot documentation states that Dependabot scans a repository's default branch and sends alerts when a new vulnerability is added to the GitHub Advisory Database, or when the dependency graph changes, for example when you push commits that update packages or versions.
Two things follow.
- Advisory side. If the advisory is not in the database yet, no alert can fire, however long the flaw has existed.
- Repository side. A newly added dependency that already has a known flaw alerts when it enters your graph, because the graph changed.
Also notice the words default branch. A vulnerable dependency that lives just on a feature or release branch may not appear in your alerts at all.
Reviewed and unreviewed advisories
The GitHub Advisory Database documentation distinguishes advisories it has reviewed from unreviewed ones that are published automatically from the National Vulnerability Database feed. It says you are notified automatically when a new GitHub-reviewed advisory reports a vulnerability for a package you depend on. Unreviewed advisories are published without package mapping review, which is why they do not behave the same way for alerting.
For your timeline, record which kind an advisory was. A delay between a CVE record and a reviewed, package-mapped advisory is time you wait on someone else.
The stages before your clock starts
| Stage | Who controls it | Can you shorten it? |
|---|---|---|
| Flaw discovered | Researcher or maintainer | No |
| Advisory published | Maintainer, coordinator or database | Rarely |
| Advisory mapped to packages | Database curators | No |
| Alert in your repository | Your settings and branch choice | Yes |
| Alert seen by a human | Your notifications and ownership | Yes |
The last two rows are where you have control. Make sure alerts are enabled on every repository, that the default branch reflects what you deploy, and that each alert has an owner. GitHub's documentation notes that people with write access can assign alerts to collaborators or teams, which prevents alerts from being overlooked.
What to do with this
- List the repositories where alerts are not enabled. Fix those first.
- Compare branches. If you deploy from a release branch, find out whether it is scanned.
- Route alerts. Send them to a channel or queue someone watches, with an assignee.
- Add a second source if you need earlier warning, such as a feed of advisories for your ecosystems, and treat its entries as leads to verify.
- Log the advisory published date next to the alert date on each finding, so the gap is visible.
Why a continuous check matters
Because new advisories arrive after you shipped, a scan at build time is a snapshot. The repository-side trigger covers code changes, and the advisory-side trigger covers new knowledge about old code. You want both.
Try it yourself
Open the continuous monitoring demo and watch how a package that was clean at build time gets flagged later.
Click through it at your own pace, or open it full screen.
Safeguard offers dependency scanning with continuous monitoring and SBOM generation; you can try a scan free at gold.safeguard.sh/scan.
Quick check
Will I get an alert for a flaw nobody has published?
No. Alerts depend on published advisories. Unpublished flaws are outside what advisory based alerting can see.
Do alerts cover branches other than the default?
Per GitHub's documentation, scanning is of the default branch. Check how you scan the branches you deploy from.
Sources
Last reviewed: 19 October 2026.
