[Early Signal] Vet scan issues with pypi packages.

[KunalSin9h]

pypi package: epochly@0.6.3 is suspicous

vet inspect malware --purl PURl correctly findings suspicious.

vet scan --purl PURL is not able to identify it. (+ vet scan -D . with requirements.txt is also same issue).

[mrswastik-robot]

Hey @KunalSin9h, may I look into this?

[KunalSin9h]

@mrswastik-robot go ahead!!

[yuvrajnode]

I spent some time narrowing this down. @mrswastik-robot are you still working on it? Not looking to step on your work, just sharing what I ruled out in case it saves you time.

Two hypotheses I was able to eliminate:

1. The malware lookup was silently disabled. Not the case --malware-query defaults to true (scan.go), so the query enricher is registered on a plain vet scan run.

2. The PyPI purl maps to the wrong ecosystem, so the lookup misses. Also not the case. Both pkg:/pypi/epochly@0.6.3 and the canonical pkg:pypi/epochly@0.6.3 resolve to ECOSYSTEM_PYPI with name epochly / version 0.6.3 through purlReader, so the QueryPackageAnalysis request that vet scan sends is well-formed.

That leaves the difference in what the two commands actually do. vet scan only queries existing analysis records via QueryPackageAnalysis (pkg/scanner/enrich_malware_query.go), whereas vet inspect malware at v1.17.2 submitted the package and waited for a fresh verdict visible in the first screenshot ("Submitted package for malware analysis with ID: ..."). So the question is whether a SUSPICIOUS / MEDIUM-confidence automated verdict ends up in the queryable threat intelligence database at all. I can't check that from the client side.

Question for maintainers: given #752 removed on-demand analysis from vet inspect malware, is query-only the intended behaviour for both commands now? If so, is the expectation that suspicious-but-unverified automated results become queryable, i.e. is the fix here server-side rather than in this repo?

One client-side issue I did find regardless of the above. When the malware lookup fails for any reason, the error is only sent to the log file:

err := enricher.Enrich(item, s.packageDependencyHandler(pm, item, q))
if err != nil {
    logger.Errorf("Enricher %s failed with %v", enricher.Name(), err)
}

(pkg/scanner/scanner.go)

The summary then prints 0/1 libraries were scanned for malware, which is indistinguishable from "we looked it up and it came back clean". With logs redirected to a file by default, a user has no signal that the lookup failed which may be part of why this reads as vet being "not able to identify it" rather than "the lookup returned nothing".

vet already has the right pattern for surfacing this: quota errors are counted through IncrementMalwareAnalysisQuotaError and rendered at the end of the summary report. A parallel counter for lookup failures would fit the same shape and make the distinction visible.

Happy to put up a PR for that piece if it's wanted it's a partial fix, not a close of this issue. Let me know whether it's worth doing and whether the main symptom is server-side.