guypod

(I'm the founder of Snyk and Tessl, apply what biases you wish)

I think we're mixing three optimizations: higher success rate, higher consistency and higher efficiency.

Success rate is about building confidence the agent can succeed. The hardest part here is defining what success is in the first place, and creating evals that help you measure it. Consistency is about guardrails. The harness shines here, as it takes control away from the model, moving it to hooks that force certain paths, or require the use of deterministic tools for certain steps. Given consistency and success rate, you can work on efficiency. You can save cognition (tokens) by moving work to tools, try to use a cheaper model, etc.

These three build on one another, at least if you want to scale them. You can't improve consistency if you don't define success, and you can't add efficiency if you're not consistent.

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.

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.

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/

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.

Snyk's done some analysis on that aspect specifically too: https://snyk.io/blog/77-percent-of-sites-use-vulnerable-js-l...

Rubysec is awesome but outdated, lacks many of the vulnerabilities in https://Snyk.io/

Also, Snyk covers JS issues, both Nodd and client side

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...