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.
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.
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.
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.
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.
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/
You're right, I tried to keep this section as brief as I could. DOM Based XSS could happen from any source, but the hardest-to-detect (and very common) variant is using the fragment (the part after the #) to inject the payload, which is never sent to the user.
It's worth noting this isn't unique to MongoDB.
The "Marked" npm package, with it's 2 million downloads, doesn't sanitize input by default. "st", another popular package, allows directory listing by default. Quite a few of those...
Fair point, language is probably too broad (was just in the lawyers template...). Note it is "limited to the extent needed to provide the service", but can be reduced further, as we (Snyk) never had any intent to do anything more than what's needed for the service. We'll remedy that in the next couple of weeks.
You've omitted the previous paragraph:
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, to enable your use of the Platform, we do need to inspect portions of your code, communicate parts of it (e.g. the dependencies being used) to the Snyk servers, etc. For that purpose, by uploading or posting content to...
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 ;)