Guide · Updated September 29, 2026

How to triage Dependabot, code scanning and Security Hub alerts

Sort security alerts by known exploitation first, then by exposure, then by severity. Severity alone puts too many alerts at the top. Research by the Cyentia Institute, cited by GitHub in April 2025, found that working on the 10% of vulnerabilities most likely to be exploited covered 87% of the ones that were.

On this page

Where your alerts come from

A team on GitHub and AWS usually gets security alerts from three places. They don't share one severity scale, so sort all of them with the same three questions. The GitHub post behind the numbers above recommends combining EPSS (exploit likelihood), CVSS (severity) and what you know about each repository. This guide turns that into an order.

Security alert sources, what each finds and where to read it
Source	What it finds	Where to read it
Dependabot alerts	Dependencies with a known advisory in the GitHub Advisory Database	Repository Security tab, Dependabot
Code scanning	Security issues in your own code, from CodeQL or any tool that uploads SARIF	Security tab, Code scanning
AWS Security Hub CSPM	Failed security controls, plus findings from GuardDuty, Inspector and other services you enabled	Security Hub CSPM console, Findings

AWS now runs two services with similar names. Security Hub CSPM, the original Security Hub, runs the control checks and collects findings. The newer AWS Security Hub receives CSPM findings and correlates them with other services, such as Inspector, to show exposures (AWS). The labels and settings below are Security Hub CSPM's. If you run in more than one Region, set an aggregation Region so findings from all linked Regions show in one list (AWS).

The triage order

Ask three questions about each alert, in this order. The first two move alerts up or down the list; severity only orders the alerts that tie on them.

1. Known exploitation

Check whether attackers already use the vulnerability. CISA's Known Exploited Vulnerabilities (KEV) catalog lists CVEs with confirmed exploitation in the wild; it had 1,729 entries as of September 29, 2026. CISA tells organizations to use it as an input to their vulnerability prioritization.

For CVEs not in KEV, use EPSS from FIRST: a daily estimate of the probability that a CVE will be exploited in the next 30 days. Dependabot alerts show the EPSS score and percentile (GitHub changelog, February 2025), and sort:epss-percentage orders the alert list by it (filter reference).

A KEV entry, or an EPSS probability of 10% or more (our suggestion), puts an alert at the top whatever its severity.

2. Exposure

Next, ask whether the vulnerable code or resource can be reached in a way that matters:

Runtime or development dependency. Filter with scope:runtime or scope:development. A flaw in a test runner rarely reaches production.
Reachable code. The advisory usually names the affected function or feature. Search your code for it. If you never call it, the risk is lower; record why.
Internet-facing. A public API or website is more exposed than an internal batch job.
Production or sandbox. The same finding matters more in the production account than in a sandbox with no customer data.

GitHub's default sort, Most important, already weighs CVSS, dependency scope and whether vulnerable function calls were detected (GitHub docs). Security Hub CSPM does not: AWS says a control's severity does not take into account the criticality of the resource (AWS). You add that part.

3. Severity

Dependabot shows each advisory's severity, based on its CVSS score. The CVSS v3.1 scale is low 0.1 to 3.9, medium 4.0 to 6.9, high 7.0 to 8.9 and critical 9.0 to 10.0. The specification itself says to combine the score with factors outside CVSS when you rank threats, which is what the first two questions do.

Security Hub CSPM labels findings CRITICAL, HIGH, MEDIUM, LOW or INFORMATIONAL. INFORMATIONAL means no weakness was found, so there is nothing to fix (AWS).

Example: three alerts in order

This is an illustration, not real data. On Monday your list has these three alerts:

Example: three alerts and the order they end up in
Alert	Order	Why
Dependabot: a CVE in a runtime dependency of your public API, CVSS 6.5 (medium), listed in KEV	1st	Confirmed exploitation and internet-facing. Patch it this week.
Security Hub CSPM: S3.8, a production bucket doesn't block public access (HIGH)	2nd	Exposed and in production. Check what the bucket holds and whether public access is intended.
Dependabot: CVSS 9.8 (critical) in a test runner in devDependencies, not in KEV, low EPSS	3rd	Development only, with no sign of exploitation. Take it in the next dependency update.

If the bucket in the second alert holds customer data, fix it the same day as the first. The HIGH label doesn't reflect what the bucket contains.

Suggested response times

Give each class of alert a fix-by time, so the owner knows the deadline without a meeting. The times below are a starting point, not a standard. Tighten them if customer contracts set their own.

Suggested fix-by times by alert condition (a starting point, not a standard)
Condition	Fix within	Note
In KEV, or EPSS 10% or more, and reachable in production	7 days	Patch, or mitigate and record how
CRITICAL or HIGH, runtime or production	14 days	Includes Security Hub CSPM findings in production accounts
CRITICAL or HIGH, development only	30 days	Or the next dependency update, if sooner
MEDIUM or LOW	Next planned update	Or accept it with a review date

For comparison, CISA's BOD 26-04 (June 10, 2026) sets fix times for US federal civilian agencies. It asks four questions: is the asset publicly exposed, is the CVE in KEV, can exploitation be automated, and does it give partial or total control. When all four answers are the worst case, the deadline is 3 days, plus a check for prior compromise. The directive doesn't apply to private companies, but its four questions are a useful check on your own table.

Rules that shorten the alert list

Rules keep the list short enough to read every week. Record a reason with every dismissal, so nobody triages the same alert twice.

Dependabot

Auto-triage rules. The GitHub preset "Dismiss low impact issues for development-scoped dependencies" dismisses certain low-impact alerts in npm development dependencies. It covers npm only, is on by default for public repositories and can be turned on for private ones. Custom rules match on severity, package name, CWE and more, and can dismiss or snooze alerts or choose which ones get a pull request. Organization-owned private repositories need GitHub Code Security for custom rules (GitHub docs).
Grouped security updates. Turn on grouping in the repository's Advanced Security settings (GitHub docs), or add a group with applies-to: security-updates in dependabot.yml (options reference). Related fixes then arrive in fewer pull requests. Dependabot doesn't group across ecosystems or mix security and version updates.
Dismissal reasons. Pick the one that fits, such as vulnerable code is not actually used or risk is tolerable, and add a comment.

Code scanning

Dismiss with a reason (false positive, used in tests or won't fix) and a comment. The comment is saved on the alert timeline, and a dismissed alert can be reopened (GitHub docs).

Security Hub CSPM

Disable controls that don't apply to your setup. AWS recommends this over suppressing their findings; a disabled control isn't checked and isn't charged (AWS).
Use automation rules to suppress findings you accept, such as findings in a test account, and put the reason in the finding's note.
Keep consolidated control findings on, so a control shared by several standards produces one finding instead of one per standard. It is on by default for accounts that enabled Security Hub CSPM on or after February 23, 2023.

A 20-minute weekly routine

Give the routine one owner and a fixed day, usually the CTO or whoever runs your weekly operations review. Once the rules above are in place, 20 minutes is a realistic target (our suggestion).

List what is new since last week: is:open sort:newest in Dependabot, the Code scanning list, and Security Hub CSPM findings with workflow status NEW.
Check each CVE against KEV and read its EPSS score. Move any match to the top.
Mark exposure: runtime or development, reachable or not, internet-facing or internal, production or sandbox.
Give every alert that stays open an owner and a fix-by date from the table above.
Close the rest: dismiss with a reason, suppress with a note, or accept with a review date.
Bring overdue items and anything new in KEV to the weekly operations review.

If the list takes longer than 20 minutes, triage only what is new and in KEV this week, then add a rule for the largest group of alerts you keep dismissing before next week. If your whole weekly review of CI, cost, runtime and security takes more than an hour, compare it with the signs in when to hire your first DevOps engineer.

Where Grant fits, and what he doesn't do

Priya covers security on Grant's team. She reads your existing Dependabot alerts, code scanning alerts and Security Hub CSPM findings, keeps their source IDs and severity, and separates a vulnerability being present from being exposed or confirmed exploited. Scheduled check-ins run daily on Pro and every six hours on Studio, and on paid plans a new Dependabot or code scanning alert starts a check-in. Grant answers in Slack, the dashboard and MCP.

She never starts scans or enables scanners. If a scanner isn't on, its evidence is unknown, not clean.
She can't confirm exploitability and makes no compliance claims.
A finding doesn't give anyone permission to write code or change production.

Separately, Since.dev records public changes from its public sources, which include OSV and CISA KEV. Grant and his team are AI agents. Their check-ins only read, except Vera's tests of your own agents, and nothing merges or deploys. Meet Grant and his team or read how to limit or pause them under stop, pause and limits.

Questions

Should we auto-merge Dependabot security updates?

Our advice: only patch-level updates, in repositories with good test coverage, and only after CI passes. Review minor and major updates by hand, since they can change behavior. Keep branch protection on so nothing merges without passing checks.

What is EPSS?

The Exploit Prediction Scoring System, published by FIRST. It estimates the probability that a published CVE will be exploited in the wild in the next 30 days, as a score from 0 to 1 with a percentile. Scores are updated daily and free to use.

Do development dependencies matter?

Less for vulnerabilities in code you ship, because development tools usually don't run in production. More for build-time attacks: a compromised package can run install scripts on laptops and CI runners that hold secrets. Keep them updated, and treat a report of a malicious package as urgent.

How does this relate to software supply chain security?

Supply chain security is the wider field: software bills of materials, signed builds, provenance and vendor review. Weekly alert triage is the part a small team can run today with the tools it already has.

How to track breaking changes and deprecations in your dependenciesDependabot flags vulnerable and outdated versions, not announced breaking changes. Where deprecation and end-of-life notices appear, and how to catch them.
Weekly operations review: a template for small software teamsA 30-minute weekly operations review for small software teams: the agenda, the checks for CI, AWS, security and dependencies, and a decision log to copy.
DevOps for startups without a DevOps teamSet up four things once, then check five every week. A practical DevOps checklist for startups on GitHub and AWS that have no DevOps engineer yet.