81–90 of 368 posts
So how was this attack gonna generate "revenue" for the attacker? What kind of info did they get hold of?
Whenever I look at a web project, it starts with "npm install" and literally dozens of libraries get downloaded. The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.
There is a reason. The prevailing wisdom has thus far been: "don't re-invent the wheel", or it non-HN equivalent "there is an app for that". I am absolutely not suggesting everyone should be rolling their own crypto, but there must be a healthy middle ground between that and a library that lets you pick font color.
When I was doing Perl more I actually highly liked the Mojolicious module for precisely this reason. It had very few external dependencies beyond Perl standard libs and because of this it was possible to use it without needing to be plugged into all of CPAN.
But with the libraries it provided on its own, it was extremely full featured, and it was otherwise very consistent with how you'd build a standard Web app in basically any modern language, so there was less of an issue with lockin if you did end up deciding you needed to migrate away.
Whenever I look at a web project, it starts with "npm install" and literally dozens of libraries get downloaded. The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.
Earlier quoted context omitted.
> And with this much at stake, they can afford to simply buy your software dependencies, or to offer one of your employees some retirement money in exchange for making a "mistake". LAPSUS$ was prolific by just bribing employees with admin access. This is far from theoretical. Just imagine the kind of money your average nation state has laying around to bribe someone with internal access.
And because it is surprisingly difficult to distinguish between 'oops' and 'malice' a lot of the actual perps get away with it too, as long as they limit their involvement. In-house threats are an under appreciated - and somewhat uncomfortable - topic for many companies, they don't have the funds to do things by the book but they do have outsized responsibilities and pray that they can trust their employees.
I really wish that the FAIR package manager project had been successful, but they recently gave up after the WordPress drama died down. https://fair.pm/ FAIR has a very interesting architecture, inspired by atproto, that I think has the potential to mitigate some of the supply-chain attacks we've seen recently. In FAIR, there's no central package repository. Anyone can run one, like an atproto PDS. Packages have DIDs…
The supply chain attack surface in WordPress plugins has always been particularly dangerous because the ecosystem encourages users to install many small single-purpose plugins from individual developers, most of whom aren't security-focused organizations. Buying out an established plugin with a large install base is a clever approach because you inherit years of user trust that took the original developer a long time…
This is a perfect illustration of what cracks me up about the hyperbolic reactions to Mythos. Yes, increased automation of cutting-edge vulnerability discovery will shake things up a bit. No, it's nowhere near the top of what should be keeping you awake at night if you're working in infosec. We've built our existing tech stacks and corporate governance structures for a different era. If you want to credit one specifi…
Earlier quoted context omitted.
I agree. I don't know many people who have shit on Java more than I have, but I have been using it for a lot of stuff in the last year primarily because it has a gigantic standard library, to a point where I often don't even need to pull in any external dependencies. I don't love Oracle, but I suspect that at least if there's a security vulnerability in the JVM or GraalVM, they will likely want to fix it else they ri…
Do you really need to roll your own NIO HTTP server? You could just use Jetty with virtual threads (still uses NIO under the hood though) and enjoy the synchronous code style (same as Go)
The answer is no, obviously I could use Jetty or Netty or Vert.x and have done all of those plenty of times; of course any of those would require pulling in a third party dependency.
And it's not like the stuff I write performs significantly better; usually I get roughly the same speed as Vert.x when I write it.
I just like having and building my own framework for this stuff. I have opinions on how things should be done, and I am decidedly not a luddite with this stuff. I abuse pretty much every Java 21 feature, and if I control every single aspect of the HTTP server then I'm able to use every single new feature that I want.
Whenever I look at a web project, it starts with "npm install" and literally dozens of libraries get downloaded. The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.
There is a reason. The prevailing wisdom has thus far been: "don't re-invent the wheel", or it non-HN equivalent "there is an app for that". I am absolutely not suggesting everyone should be rolling their own crypto, but there must be a healthy middle ground between that and a library that lets you pick font color.
I think maybe the pendulum needs to swing back a little to being very selective about adding dependencies and expecting releases to be stable for the long term. Users shouldn't have to worry about needing to hack around code that was written just 3-4 years ago.
WordPress is now a dangerous ecosystem because of the plugins and their current security model.
I moved to Hugo and encourage others to do so - https://ashishb.net/tech/wordpress-to-hugo/