While Flox does improve the Nix UX, I don't think that's the most exciting thing about it. The real impact is in bringing the underlying power of Nix to people who would have never used it.

Nix has all sorts of core portability, security and management capabilities that are massively valuable in a distributed and diverse env dev team, but are rarely used because they're too hard.

If Flox takes off, many more developers would benefit from those capabilities, and most of those would still have minimal to know understanding of the underlying Ni complexity.

FWIW, that's at least why I invested in them ;)

Fair point. I see the security concern, as far as availability goes, as something FaaS improves, but it's definitely up to you to decide whether downtime is better or worse than a big bill.

The fact OS patching is done by people whose entire job and profession is to keep systems patched matters - they are patched more often and faster. In addition, the fact servers don't live long means it's easier to patch servers (since there's no need to patch a running system). So there's a very real difference here.

- A sys admin will not be rolling out OS patches. The platform does itself. - Attackers typically use DoS to make a system unavailable, not just make it expensive to operate. I do note the cost concern, but if attackers are unsuccessful taking a system down, they are less likely to attack it. - I indeed meant "attacking through the OS is unreachable", referring to the portion explaining the OS patches are better managed. It's indeed not perfectly accurate phrasing, but allow a guy some literal freedom in the summary - the details came before.

Some attackers are perfectly fine with costing a company a ton of money without taking their service down.

I have no doubt the operators of those networks do - on average - a far better job operating the systems. My concern is that FaaS developers would therefore consider FaaS naturally secure, and forget there are still quite a few security risks they have to tackle themselves.

It's entirely doable to manage permissions granularly, but it's not the most natural thing to do. It's FAR easier to broaden permissions.

The more functions you have and the more time they've had to morph, the more likely they are to have far greater permissions than they should.

I think it's an absolute statement about the lack of awareness to this risk.

Of course some of these site would not actually be vulnerable, but I would bet the vast majority of them don't even know they're using a library with a known vulnerability.

Agreed, but the tools (nsp) are there to make it simple to know. Devs who are not going to update/patch are not the target here, so making big claims like this does not strongly add to the conversation IMO.

Also, this is nothing new on the web, the amount of wordpress sites with known voulns is probably MUCH higher.

Scanning for vulnerable components is different. All the tool has to do is find out the site is using the specific library, the vulnerabilities themselves are manually validated.

awkward typo there! Fixed now.

This article was very much about the data we've collected and our analysis of it, as opposed to our opinions as to why - had to keep it to a reasonable length! So we kept that section short in the end. I do plan follow up posts that provide my theories as to why it's happening, and I think a best practices guide that discusses template-related XSS is a good idea. In the meantime, you can check out this related post: https://snyk.io/blog/type-manipulation/