oss-intake

Evidence for deciding whether to adopt, keep or replace an open source component: known vulnerabilities, malicious releases, public exploits, how long fixes have gone unshipped, and project health.

Why scan again after approval

Each package below was trusted and widely used. Each had one release that was malicious. A team that approved the package before that release, and never checked again, would have pulled it in on the next install.

PackageReleaseWhat happened
chalk5.6.1September 2025: a maintainer's npm account was phished and malicious versions of widely used packages were published.
debug4.4.2The same incident as chalk.
@ctrl/tinycolor4.1.1September 2025: Shai-Hulud, a self-spreading npm worm.
ua-parser-js0.7.292021: hijacked account; cryptominer and password stealer.
event-stream3.3.62018: handed to a new maintainer, who added a dependency on the malicious flatmap-stream.
flatmap-stream0.1.1The payload of the event-stream attack, aimed at a cryptocurrency wallet.

The sample report scans a lockfile that contains all six. Every one is flagged as malicious and put first, under Act now, with the advice to remove it rather than patch it.

No tool flags a release like these on the day it is published, because the advisory does not exist yet. Once it does, the next scan flags it. That is the case for scanning on a schedule, not once at approval. Only the lockfile was read to produce the sample: nothing was downloaded from npm or installed. The report lists every finding as CSV.

What a report adds to a scanner

Results are version matching, not proof of exploitability. The report says so, and leaves the decision to the assessor.

Try it

pipx install oss-intake
# install Trivy and Grype, pinned and verified (see the README)
oss-intake scan --path package-lock.json --out report
oss-intake scan --image <image:tag> --repo <owner/name> --out report

Python 3.10 or later on Windows, macOS or Linux. Releases are built in GitHub Actions, published to PyPI with provenance, and signed with Sigstore.