Malicious Package Versions Removed from deps.dev

[abhisek]

It appears if a package is marked as malicious then it is removed from deps.dev including the API.

Example: pkg:/npm/nx@20.12.0 is malicious and shows a 404 on deps.dev site. https://deps.dev/npm/nx/20.12.0

Example: pkg/npm/nx@20.8.0 is not malicious and is shown as expected. https://deps.dev/npm/nx/20.8.0

I have not verified if the malicious package version record is removed from the BigQuery dataset as well or is it a feature of the deps.dev app.

Is this expected behaviour? It seems counterintuitive to have these packages removed from deps.dev which serves as an enriched log / database of open source packages with its associated attributes for various use-cases.

[elitsa-gosst]

This is indeed the expected behaviour as we follow the upstream's practices.

Since the versions are removed from npm, we also remove them from deps.dev.

[abhisek]

@elitsa-gosst Thanks for the confirmation.

Is this decision open for discussion?

As a downstream user of deps.dev data for building security tools, so far I have "assumed" deps.dev as the source of truth for aggregated OSS package metadata. For security use-cases, this means the dataset should ideally be append only to enable auditing.

As upstream, it makes sense for npm to remove malicious packages to protect their users. But deps.dev is not serving malicious packages. It is holding a record of the fact that a given npm package was malicious. This fact can help users of deps.dev to detect security incidents in the version history of the package based on the deps.dev. If deps.dev removes the data then such use-cases will no longer be feasible based on deps.dev data.

Happy to discuss more if this is something that can be considered in future.

[nickyringland]

Hey @abhisek - yes, understand your reasoning here. Thus far, deps.dev has tried to follow upstream closely for a few reasons, but we have considered providing a 'tombstone' for packages that have been removed.

This wouldn't guarantee that we would preserve metadata about all malicious packages, though. The faster package managers are at removing malicious packages, the less likely deps.dev would see them at all (shout-out to PyPI who we know block and remove substantially more malicious and typosquatting etc packages before we see them).

Would an incomplete register still be useful? What would the minimum metadata be that you'd be interested?

One of the other challenges we've considered is that in some ecosystems, packages can be republished in the namespace of previously deleted packages (either at a version or package level), - but this is also inconsistent between ecosystems.

Happy to hear your thoughts!