Which alert did that dependency raise?

A client says the dependency is vulnerable, or says the alert is gone. Tonight, three proofs, in a repository the agency or the client can open. Name the alert that dependency raised: the alert number, the state, the package, and the advisory. Show a different alert whose number, or whose package, is not this one. Show another client's repository that does not list this alert. If any of the three needs the person who installed the package, you have not shown the alert. You have a scanner slide and a guess.

This is the method on one alert. It is not the pin. Name the package the lockfile pinned is the range, the resolved version, and the integrity. An alert can be open on a version the lockfile already names, and a pin can be exact while no alert exists. It is not the runner. Which runner did that job use? is the label and the machine. A runner label is not an alert number. It is not the image. Which image did that deploy run? is the reference and the digest. A digest is not a GHSA id. It is not the review. Which review blocked that merge? is a review on a pull request. A blocking review is not state open on an alert, and dismissed as a review is not dismissed as an alert state.

None of what follows is a rate for this client's tree, and none of it is a legal opinion about a license. The fields below are one host's current description of a Dependabot alert. The counts below that are a 2025 study of security updates in public JavaScript projects. A state enum is not a census of your repositories. A paper that never opened this client's alert cannot name the number on the alert you opened tonight. They do tell you which numbers people mix up when they try to sound precise about an alert they have not opened.

GitHub's alert object has a number, and the number identifies the alert inside its repository. state is one of auto_dismissed, dismissed, fixed, or open. Four names. fixed is not dismissed. auto_dismissed is not dismissed. The dependency object carries a package name and an ecosystem. The ecosystem filter lists composer, go, maven, npm, nuget, pip, pub, rubygems, and rust. Nine names. severity is low, medium, high, or critical. Four names, and medium is the word on this page. scope is development, runtime, or null. relationship is unknown, direct, transitive, inconclusive, or null. unknown is not inconclusive. classification is general or malware. Two names. A malware classification is not a critical severity. The security advisory has a ghsa_id, and cve_id may be null. A null CVE is not a missing alert. summary is required and its max length is 1024. dismissed_comment may be null and its max length is 280. 1024 is not 280. CVSS v3 and v4 scores, when present, run from 0 to 10. EPSS percentage and percentile, when present, run from 0 to 100. 10 is not 100. A score of 10 is not a percentage of 10 (GitHub, REST API endpoints for Dependabot alerts).

Dismissal is a second vocabulary, and it is not the state list. dismissed_reason is fix_started, inaccurate, no_bandwidth, not_used, tolerable_risk, or null. Five names, plus null. fix_started is not state fixed. no_bandwidth is not state open. A null reason on an open alert is not the reason inaccurate. dismissal_request.status, when that object is present, is pending, approved, rejected, or cancelled. Four names. approved on a dismissal request is not an approving review on a pull request. cancelled is not state dismissed. dismissed_at and fixed_at are timestamps, and either can be null. A null fixed_at on an open alert is not a promise that nobody will fix it. The list endpoints take state and severity as comma-separated filters. Filtering to open is not the same as counting every state. per_page maxes at 100. 100 is not 1024, and it is not 10. Pagination on the same page is before, after, and per_page. before is a cursor. It is not a date. OAuth app tokens and classic personal access tokens need the security_events scope. A token that only has public_repo can call the endpoint when the repository is public. public_repo is not security_events. A private repository does not become readable because a public one was.

The study that counted how often a security update is merged is not an alert number. Hamid Mohayeji, Andrei Agaronian, Eleni Constantinou, Nicola Zannone, and Alexander Serebrenik started from 3151 engineered projects, found 1492 that had received at least one Dependabot security update, excluded 390 that also used other dependency bots, and filtered out 124 whose updates targeted ecosystems other than npm and yarn. 1492 minus 390 minus 124 is 978. They print 978. That subtraction holds. Later, commit history was reachable for 954 of the 978. They say 954 exceeds 97% of 978. 954 divided by 978 is above 97%. That sentence holds. The page says the rest were deleted or made private, and it does not print how many that rest is. Do not invent the gap. 954 is not 978. yarn is in their filter. yarn is not one of the nine ecosystem names on the REST page. Their background also says the advisory database uses severity low, moderate, high, or critical. moderate is not medium. Six ecosystems in that background sentence, including npm and yarn, is not the nine on the API. Do not rename moderate to medium to make the paper match the console (Mohayeji et al., Securing dependencies).

The update counts and the vulnerability counts are different denominators. They collected 4416 security updates: 2391 merged, 1804 closed, and 221 open. 2391 plus 1804 plus 221 is 4416. They then drop the open ones and analyze 4195. 4416 minus 221 is 4195. They print that 57% of the bot-initiated security updates are merged. 2391 divided by 4195 is 0.570, which rounds to 57%. That sentence is about updates, not about projects. Table 3 says projects merged 54% of their non-open security updates on average, and the median project merged 67%. 54% is not 57%, and 67% is not 54%. A mean of project ratios is not a share of updates. Do not cite 67% as the merge rate of the 4195.

The vulnerability arithmetic is a third pile, and one of its multiples does not match the prose. They first identified 5089 vulnerabilities, then removed redundant entries where Dependabot had recreated an update, and kept 4978. 5089 is not 4978. The page does not print how many redundant entries were removed. Do not invent that count. Of the 4978, 53.48% (2662) were fixed by merging a Dependabot security update, 30.27% (1507) were fixed manually, and 16.25% (809) stayed unfixed. 2662 plus 1507 plus 809 is 4978. 2662 divided by 4978 is 53.48%. Those three sentences hold. They also say bot fixes occur 1.8 times more frequently than manual fixes, and that bot fixes are almost two times more frequent. 2662 divided by 1507 is not 1.8, and it is not 2. Almost two is not the quotient of those two counts. They call 30.27% nearly one-third. One-third of 4978 is not 1507. 30.27% is not 33%. 16.25% is not 30.27%.

The clocks in that paper do not collapse into one wait. About 50% of Dependabot security updates are merged within a day, and another 25% within eleven days. 50 plus 25 is 75, not 100. The page does not print the rest as a third bucket. Less than a quarter, precisely 18%, of manual fixes happen within a day, and half of them take at least 1.5 months. 18% is not 50%. 1.5 months is not eleven days, and it is not one day. Inspired manual fixes have a median of 68 days. Non-inspired manual fixes have a median of 44 days. 68 is not 44. The Mann-Whitney test on those two distributions is p greater than or equal to 0.8. The bot-versus-manual time comparison is reported at a significance level of 0.01%. 0.8 is not 0.01%. The 75th percentile of both manual distributions is nearly 140 days. 140 is not 68, and 140 is not 44. Within 60 days, about 75% of vulnerabilities in their first four-month slice were resolved, against about 50% and 60% in the next two slices. 75 is not 50, and 50 is not 60. 60 days is not four months.

Two smaller counts are easy to promote into a rate for this repository. Their detector found 133 false positives on merged security updates, which they attribute to a Dependabot bug that leaves a vulnerable range in yarn.lock after the update. 133 is not 809, and it is not an alert number. A second rater checked 50 events, half of them complex, and the two raters did not disagree. 50 is not 133. The page says half of those events were the complex kind, and it does not print that half as an integer. Do not invent it. They also cite other papers: Kula and colleagues found 69% of interviewed developers were unaware of a vulnerable dependency, and Decan and colleagues reported nearly 14 months for half of dependent packages to address one, and more than 20% of projects with a direct dependency on a vulnerable package. 69% is not 53.48%. 14 months is not eleven days. 20% is not 16.25%. None of those is the number field on this client's alert.

Do the three proofs in the repository you administer, on one alert you can re-open. First, the binding. Copy the alert number, the state, the package name, the ecosystem, the manifest path if it is present, and the ghsa_id. If the state is auto_dismissed, write that, and write the dismissed_reason if the object has one. If cve_id is null, write null. Do not infer critical because the summary sounds severe. Do not infer 100 because a page size maxes there. Second, the other alert. A different number, or a different package, is not this one. A paper's merge rate is not that second alert. If you cannot show an alert that is not this one, you have a counter, not a record. Third, the other repository. A list that belongs to another client does not contain this number. Alert numbers are per repository. The same integer in two repositories is two alerts. If the only screen is an organization rollup and you cannot name the repository, write that. A client you cannot name is the finding.

Three moves feel like the proof and are a second problem. Dismissing the alert, or merging a pull request, because the state was embarrassing, before you have copied the number. A dismissal changes the record. It does not tell you which alert you were looking at. Quoting 57% or 67% because one of them looks precise, while the alert you were asked about is one row, and the public JavaScript projects that produced those shares are not this client's private repository. Asking a model which state it was. The model will pick one of the four. It will not open the alert. The version the lockfile resolved, if you still have not read it, remains the package the lockfile pinned. An advisory does not fill in a missing integrity line.

The path is ordinary when an operator can open one client's project without opening the next client's project as the way to prove it. Gigbase is an agency workspace that links projects to clients. The shape that matters here is one client's project you can point at, distinct from the next client's project. That case is not an alert ledger. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the screen mixes every client's dependencies into one list, you do not have this proof. You have a blended queue.

There is a version of this afternoon where an agency should not take the work. The work is not sold under the agency's name, so there is no client-facing repository to stand behind. The client has asked to meet the people writing the code. That is a disclosure decision, when to tell a client you subcontract, not a reason to skip the alert number. The room only has a slide. There is no repository to open. The buyer only wants a template of package names. Or the buyer wants a legal opinion about whether a license allows the copy to leave. Hire the lawyer. An alert state does not issue opinions, and neither does this page.

When the repository is real and the alert is not on a screen you can open, the missing object is specific. The number, the state, the package, and the advisory, a different alert that is not that one, and another client's repository that does not list it. A white label software development partner that expects this will put the repository in the client's organization, or in yours, before the first install, because an alert that lives only in a vendor dashboard is not a number you can hand the client. One that can only paste a severity word into chat is telling you who holds the graph. Where the next slice is one capability and the acceptance sentence names the alert number, an AI integration sprint is the shape that can require the three proofs as the definition of done. Where you are not sure which repository the current engagement installs from, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a promise that 57% of this tree is merged, and they are not a rate.

The dispute a charge opened, and the document a citation named, are different objects: which dispute did that charge open? and which document did that citation name?. Do not record either on this page. A dispute status is not an alert state. A document index is not an alert number. The release a tag named is a different object: which release did that tag name?. Do not record it on this page. A tag is not an alert number.

Before you tell the client the dependency is handled, write the three lines. The alert number, the state, the package, and the advisory, or the field that is missing. A different alert that is not that one. Another repository that does not hold it. Do not dismiss the alert to avoid the state, and do not ask a model which of the four it was. A paper can tell you how public JavaScript projects treated security updates. The binding is the alert you can defend.