> The incident also prompted LiteLLM to make changes to its compliance processes, including shifting from controversial startup Delve to Vanta for compliance certifications.
This is pretty funny.
The leaked excel sheet with customers of Delve is basically a shortlist of targets for hackers to try now. Not that they necessarily have bad security, but you can play the odds
I am not defending Delve or anything and I hope they get what they deserver but there is no correlation between SOC2 certification and the actual cyber capability of a company. SOC2 and ISO27001 is just compliance and frankly most of it is BS.
It might feel like BS, and I'm inclined to agree with you because of the security theater aspect. (For example, Mercor had their verification done by what appears to be a legitimate audit firm.)
But it's not useless. It still forces you to go through a very useful exercise of risk modeling and preparation that you most likely won't do without a formal program.
If your goal is to maximize your posture against cyber threats, spending your time on SOC 2 compliance with Vanta (or similar) is a waste of time if you consider the amount of time spent compared to security gained.
It's incredibly easy to get SOC 2 audited and still have terrible security.
> forces you to go through a very useful exercise of risk modeling
Have you actually done this in Vanta, though? You would have to go out of your way to do it in a manner that actually adds significant value to your security posture.
(I don't think SOC/ISO are a waste of time. We do it at our company, but for reasons that have nothing to do with security)
This is a good reminder that any tool handling sensitive data — even internal ones — needs to be transparent about where data goes. The assumption that SaaS tools protect your data is getting harder to defend.
I'll add this: Containers aren't as strong of a security boundary as VMs however this means that a successful attack now requires infection of the container AND a concurrent container-escape vulnerability. That's a really high bar, someone would need to burn a 0-day on that.
The bar right now is really, really low - blocking post-install scripts seems to be treated as "good enough" by most. Using a container-based sandbox is going to be infinitely better than not using one at all, and container-based solutions have a much easier time integrating with other tools and IDEs which is important for adoption. The usability and resource consumption trade-off that comes with VMs is pretty bad.
Just don't commit any mortal sins of container misconfigurations - don't mount the Docker socket inside the container (tempting when you're trying to build container images inside a container!), don't use --privileged, don't mount any host paths other than the project folder.
Confusingly, Docker now has a product called "Docker Sandboxes" [1] which claims to use "microVMs" for sandboxing (separate VM per "agent"), so it's unclear to me if those rely on the same trust boundaries that traditional docker containers do (namespaces, seccomp, capabilities, etc), or if they expect the VM to be the trust boundary.
This is pretty funny.
The leaked excel sheet with customers of Delve is basically a shortlist of targets for hackers to try now. Not that they necessarily have bad security, but you can play the odds
But it's not useless. It still forces you to go through a very useful exercise of risk modeling and preparation that you most likely won't do without a formal program.
It's incredibly easy to get SOC 2 audited and still have terrible security.
> forces you to go through a very useful exercise of risk modeling
Have you actually done this in Vanta, though? You would have to go out of your way to do it in a manner that actually adds significant value to your security posture.
(I don't think SOC/ISO are a waste of time. We do it at our company, but for reasons that have nothing to do with security)
https://cloud.google.com/blog/products/gcp/exploring-contain...
Running npm on your dev machine? Or running npm inside Docker?
I would always prefer the latter but would love to know what your approach to security is that's better than running npm inside Docker.
I definitely want to know how is it worse than running npm directly on the host
Escapes:
- privileged mode (misconfiguration, not default or common)
- excessive capabilities (same)
- CAP_SYS_ADMIN (same)
- CAP_SYS_PTRACE (same)
- DAC_READ_SEARCH (same)
- Docker socket exposure (same)
- sensitive host path mounts (same)
- CVE-2022-0847 (valid. https://www.docker.com/blog/vulnerability-alert-avoiding-dir...)
- CVE-2022-0185 (mitigated by default Docker config, requires miconfiguration of capabilities)
- CVE-2021-22555 (mitigated by default Docker config, requires miconfiguration of seccomp filters)
default seccomp filters in docker: https://docs.docker.com/engine/security/seccomp/#significant...
privileges that are dropped: https://docs.docker.com/engine/containers/run/#runtime-privi...
---
I'll add this: Containers aren't as strong of a security boundary as VMs however this means that a successful attack now requires infection of the container AND a concurrent container-escape vulnerability. That's a really high bar, someone would need to burn a 0-day on that.
The bar right now is really, really low - blocking post-install scripts seems to be treated as "good enough" by most. Using a container-based sandbox is going to be infinitely better than not using one at all, and container-based solutions have a much easier time integrating with other tools and IDEs which is important for adoption. The usability and resource consumption trade-off that comes with VMs is pretty bad.
Just don't commit any mortal sins of container misconfigurations - don't mount the Docker socket inside the container (tempting when you're trying to build container images inside a container!), don't use --privileged, don't mount any host paths other than the project folder.
[1]: https://www.docker.com/products/docker-sandboxes/
Your cab see the commit history ~10% of code is written by agents.
Rest was all written by me.
Unlike other criticisms of the project, this one feels personal as it is objectively incorrect.