On this page
Research context
Dependency alerts are plentiful, noisy, and easy to close without reading. This protocol asks a bounded question: for a declared period and a declared dependency inventory, are alerts triaged consistently against a written rule, and can a reviewer reconstruct each decision from records? It does not ask whether the codebase is secure. A closed alert is a workflow state, not proof that a vulnerable path is unreachable or that an upgrade is safe.
The population is alerts raised against direct and transitive dependencies of the declared services during the window. The observation unit is one alert on one package version affecting one service, linked to the advisory, the dependency path, and the triage decision. A package used by several services produces several units even when the advisory is identical, because the exposure and the owner can differ.
Deduplicate before counting, and state that the denominator is distinct advisory and service pairs rather than raw alerts. One advisory can appear once per lockfile, once per branch, and once per scanner. A count of alerts is not a count of risk, and the first table in the readout should show raw alerts, distinct advisory and service pairs, and duplicates removed. Keep the dedupe rule in the record so a later reviewer can test it on a sample rather than trusting the number.
Record the severity source. The advisory database, the package registry, and an internal rating can disagree. State which source drives the service target and whether an internal override exists, because a queue sorted by a different severity than the one reported is inconsistent by design. An override needs an owner and a reason, not a silent edit in a spreadsheet.
Build the dependency path. For a transitive alert, the path from the service manifest to the vulnerable package determines both reachability and the upgrade option. A path that runs through a build tool has a different exposure from one that runs in a request handler, and a path that exists only in a development dependency has a different owner as well.
Reachability evidence should be proportionate. For a low severity package used only in tests, a written statement and a path listing may be enough. For an internet facing service, ask for the route, the call site, and the configuration that enables the affected function. The evidence should be attached to the alert rather than summarised in a meeting note.
The triage clock needs a start and a stop. Start at alert creation or at the first assignment, stop at a decision or at the upgrade merge. Report both if they differ, and state whether the clock counts business hours. A queue that looks slow because alerts sit unassigned is a routing problem, while one that looks slow after assignment is a capacity or decision problem.
Practical application
Decisions should come from a closed set: upgrade, patch, mitigate with configuration, accept with expiry, or false positive with evidence. A free text field produces plausible sentences that cannot be compared across reviewers. A closed set also makes disagreement visible, which is the point of a reliability study rather than a compliance report.
Acceptances need an expiry and an owner. An accepted risk with no date is an unowned decision that will reappear in the next audit with no rationale. The protocol should treat a missing expiry as an incomplete case rather than an acceptance, and the readout should show the count of incomplete acceptances beside the closure rate.
The upgrade record needs more than a version number. Include the target version, the changelog reference, the test evidence, the rollback path, and the release identifier. A dependency bump merged without a passing test run is a state change, not a verified fix, and the next alert may reopen the same package because the vulnerable path remains.
Check for version range tricks. Updating a lockfile without changing the manifest can be reverted by the next install, and pinning a fork can move the package outside the advisory feed. Record the manifest and lockfile revisions together, and treat a change that only touches the lockfile as provisional until the next clean install is tested.
Independence is measured with agreement. Two reviewers triage a sample of distinct alerts using the same codebook. Compare the decision, the severity source, the reachability claim, and the expiry. Disagreement on severity is common and should be reported rather than averaged away, because the average hides the cases where one reviewer saw exploitability and the other saw a test only dependency.
Alternative explanations belong in the readout. A closure spike may follow a scanner upgrade, a bulk bot pull request, a change in advisory volume, or a holiday period. Without those notes, a trend becomes a story about team behaviour. The readout should also separate alerts closed by an automated upgrade from those closed after a manual review.
Time states should separate scanner ingestion, assignment, reviewer work, owner decision, upgrade build, and release. A queue that looks slow because one owner holds ten acceptances is a different problem from a scanner that delivers late. Report the median for each state separately, with the count of items that never reached the next state.
Operating controls
Source systems are the package manifest, the lockfile, the advisory database, the scanner, the pull request history, and the release record. Each field in the evidence table should name its source. A severity copied by hand without a source cannot be checked later, and a reachability claim with no call site is an opinion about architecture.
Access control matters because dependency data reveals architecture, and the same export that helps a triage queue can help an attacker map internal services, package versions, and release cadence. Use least-privilege access to the scanner and the repository, redact service names in published tables where needed, and keep the raw extract in approved storage with a retention date. An alert export that lists every internal package name is a map of the system for anyone who finds it. If the scanner cannot state which service introduced a transitive package, that gap is part of the finding and should be listed as an evidence limitation rather than filled with an assumption about the dependency tree.
Exceptions accumulate. Report the count of open acceptances by age band and owner. An acceptance older than its review date is a finding, and the protocol should not let it disappear into a dashboard filter. The same applies to a repeatedly deferred upgrade: count the deferrals rather than only the final decision date.
Sensitivity checks are required. Recompute with duplicates included, with acceptances counted as unresolved, and with transitive alerts excluded. If the queue reliability changes, publish both readings and the decision that depends on the definition. The method has limits: it evaluates workflow consistency, not exploitability. Advisory severity is not a local risk score, reachability evidence can be wrong, and a passing test run does not prove that an upgrade is behaviour preserving. The same discipline applies to deferred upgrades that never receive a decision, because silence is not an acceptance and it should not be counted as one.
Refresh the protocol when the scanner, advisory source, dependency manager, or release process changes. Compare periods only when the alert generation rule is comparable, and mark a scanner migration as a break in the series. The practical output is one repair: a dedupe rule, a severity mapping table, an expiry default, a reachability template, or a named owner for the acceptance queue. A reader who cannot reproduce the break in the series will compare two numbers that were generated under different rules and draw a conclusion the data cannot support.
No local alert counts, resolution times, or benchmarks are reported here. The sources describe secure development, access control, and dependency scoring practice; they do not measure any queue using this protocol. Acceptance is reproducibility. A second reviewer should rebuild the distinct advisory and service pairs, apply the same dedupe and severity rules, and reach the same decision set or a documented disagreement with cited evidence.
Sources
Frequently asked questions
What should happen first?
Begin with a bounded ticket, approved access, explicit acceptance evidence, and a named reviewer.
Who approves production changes?
The client's technical owner keeps final merge and release authority.
Related research
Verifying Test Coverage Claims Without Invented Numbers