Package checks
We're building a way to check a software package before you install it. Here is what it looks for, what it covers and what it can't see.
Where it stands
Public lookups are coming soon. We're scanning packages now, in private batches, while we measure how well the checks work. You can't look up a package here yet.
- PyPI and RubyGems: being scanned now, in batches. Not every package or every new release has been scanned yet.
- npm: next, and only to track which new versions appear. We won't be reading npm package files, so we won't be able to say whether an npm package is risky.
What the checks look for
- Install files that contact the internet
- Install files that start other programs
- Install files that run code stored as text
- Code that decodes hidden text and then runs it
- A very long block of encoded text inside code
- Packages that run their own step during install. Many ordinary packages do this, so we only note it.
What they can't see
- We read a package's files for these patterns. We don't install or run it, so we don't see what it only does when it runs.
- We can't read compiled files, and very large files are skipped. Archives inside a package aren't opened.
- Today we read one file for each version of a package. Other files for that version aren't checked, and those may be the ones your computer installs.
- We don't yet know how well these checks catch real attacks. So far we've measured them only on ordinary packages.
When lookups open, each result will say which file was checked, when, and how many files we couldn't read.
What the answers will mean
- Nothing risky found in what we checked
- None of the checks fired on the file we read. This isn't a guarantee.
- Worth a look
- A check fired. Many ordinary packages do the same, so we show what we found and leave it there. It doesn't mean the package is harmful.
- Risky behaviour found
- A person at MinakiLabs reviewed the evidence and confirmed it.