peteatphylum

Another huge fan of just, here. I love that it's installable with a one-liner and I've added this as an option to my dotfile setup.

I'm done trying to cast spells at Make

This attack is particularly interesting. The attackers targeted the massively popular 'requests' package in PyPI, used bitsquatting to target typosquat candidates, and results in ransomware getting deployed.

There be dragons in here

Not only great work in taking the bugs all the way, but a great writeup too

Totally agree. It feels like there is a pretty strong inverse correlation between standard library size, and average depth of a dependency tree for projects in a given language. In our world, that is pretty close to attack surface.

We've found a lot of open-source packages that are authored by (well, released by authors identified by) disposable email addresses. We were shocked to find companies doing this, too.

Package Dependency land is a crazy place

This is the double-edged sword of open-source. It's awesome because anyone can contribute. It can be dangerous for the same reason, unfortunately.

I think the majority of the functionality in leap can be had in IntelliJ IDE's with the AceJump plugin

(Disclaimer: I work at Phylum, which has a very similar capability)

Not all of it has to be manual. Some vulnerabilities come with enough information to deduce vulnerability reachability with a high degree of confidence with some slightly clever automation.

Not all vulns come with this information, but as time goes on the percentage that do is increasing. I'm very optimistic that automation + a bit of human curation can drastically improve the S/N for open source library vulns.

A nice property of this is: you only have to solve it once per vuln. If you look at the total set of vulns (and temporarily ignore super old C stuff) it's not insurmountable at all.

This is a terrific project. Write a scraper to do this!

I suggest this having read another comment of yours (https://news.ycombinator.com/item?id=31763001) Scrapers are fun projects and there are tons of resources online to assist.

A project like this is a great thing to discuss in an interview as well.

We're building a solution to solve exactly this at phylum. I'm not trying to be a sales shill, but if anyone is interested in discussing ideas on how to best defend open-source libraries from these types of attacks, please get in touch, I'd love to hear from you!

We're consuming everything we can about a package to figure this out. We've built a static analysis system to reason about code (it's not perfect, but we're getting better and better). We process all the data we can get, then build analytics, heuristics and ML models to extract evidence. The evidence is then pieced together to identify software supply chain risk.

In this case there is a lot of signal to show both bad and suspicious things are happening.

1. Obfuscation: this creates a comparatively deep AST of the code, and isn't difficult to identify.

2. Command execution: curl, wget, LOLBINs like certutil are pretty easy to identify. This isn't a slam dunk every time you see it, but it adds evidence to a potentially malicious claim.

3. URLs: These are uncommon in libraries and add evidence.

4. Pre/Post install scripts: These are fairly commonly used for other things as well, but invoking node on a source file that is likely obfuscated is a good sign something suspicious is happening.

We're trying to build everything fast enough to make the target far less attractive for attackers before it gets a lot worse.

I wish it worked that way. I just peeked into how python packages in debian-based distros work. They are most frequently PyPI packages with some debian wrapping, so we're back at the same problem.