Declared dependencies are not deployed-version proof

What did the upgrade actually change?

Your coding assistant updates a lockfile and the tests pass. That is useful evidence about a source change. It does not yet tell you which dependency version is running in the application your users reach.

Build the distinction with this synthetic example. example-widget and its versions are invented teaching data, not a real package, advisory or SecurityFuse scan. Snapshot A and snapshot B are simply two recorded states of the source.

The broken connection is between source evidence and deployment evidence. You do not repair that connection by repeating the package name in a release note. You need records appropriate to the deployment question you are trying to answer.

Read the record you actually have

A manifest and a lockfile serve different jobs. For npm, the package-lock documentation describes the lockfile as a record of the generated dependency tree. That gives a reviewer a more specific source record than a dependency range alone. It still does not identify a running process.

Before discussing an upgrade, record the source revision and file you read. Check whether the entry is an ordinary registry dependency, a local reference or something the available parser cannot interpret. Keep an unsupported or missing record visible instead of treating a missing advisory match as a clean result.

You might have the right repository but the wrong revision. You might have a changed lockfile that was never included in a build. You might have deployed one environment while reviewing another. These are possibilities to investigate, not explanations established by the table.

An advisory is another piece of evidence

A dependency advisory concerns identified software and affected versions. The OSV schema separates package identity, explicit affected versions and version ranges. Those fields help answer whether a version falls within an advisory's stated scope. They do not tell you that your application deployed that version or that a particular route is exploitable.

The example does not need a fabricated advisory ID or an invented affected range. In a real review, retain the actual advisory reference and read its conditions. Then distinguish three questions: does the source record match, is that software used in the relevant build, and what evidence connects that build to the deployment?

An advisory service also has limits. A successful lookup does not establish that every dependency was inventoried or that every possible vulnerability has an entry. An unavailable lookup leaves a gap; it is not evidence that a package has no known issues.

What SecurityFuse's repository checks establish

SecurityFuse's repository-check implementation reads selected source snapshots without installing packages or executing their code. Its dependency parser supports exact entries from npm package-lock versions 2 and 3 and simple pinned requirements.txt entries. Unsupported formats and entries can leave coverage partial. This is a deliberately bounded inventory, not a claim to understand every dependency graph.

Hosted repository assessment is not offered in the current website beta. Hosted website scanning is live for invited users, but a website response does not establish which lockfile or package version produced it. The repository behavior described here must not be mistaken for a public repository-upload service.

For private repository material, the implementation also has a separate advisory-processing permission boundary. Do not assume permission to read source automatically permits sending dependency coordinates to another service. Keep that decision distinct from whether the parser recognizes a file.

Give the coding tool a source task

A useful repair request names the source revision, inventory entry and actual advisory basis. Ask the tool to investigate the dependency path, propose a suitable update and identify compatibility tests. Keep unrelated upgrades outside that request unless a reviewer deliberately expands it.

For our synthetic example, the task could be to explain why the selected version changes between A and B and which tests exercise the affected integration. The tool should not announce that production is repaired merely because it edited the record. A human still reviews the change and decides how it will be built and released.

The repair-to-recheck article explains why a statement of completion is separate from a later observation. Use that distinction here without asking a website check to answer a package-inventory question it cannot assess.

Keep the missing connection explicit

After the edit, inspect the new source record and its test results. Separately establish which artifact was built and which environment received it, using the records your delivery process actually provides. Do not infer those steps from a successful page load.

If you cannot connect the running application to the changed source, say that the dependency change is recorded in source and the deployed version is not established. That statement is useful: it identifies the next evidence to collect. It also avoids turning an unanswered deployment question into a claim that the live application has been repaired.