[imcritic]

I don't think what you want us even possible. How would such guarantees even look like? "Hello, we are a serious cybersec firm and we have evaluated the code and it's pretty sound, trust us!"?

"Hello, we are a serious cybersec firm and we have evaluated the code and here are our test with results that proof that we didn't find anything, the code is sound; Have we been through? We have, trust us!"

[gpm]

In terms of a one off product without active support - the only thing I can really imagine is a significant use of formal methods to prove correctness of the entire runtime. Which is of course entirely impractical given the state of the technology today.

Realistically security these days is an ongoing process, not a one off, compare to cloudflare's security page: https://developers.cloudflare.com/workers/reference/security... (to be clear when I use the pronoun "we" I'm paraphrasing and not personally employed by cloudflare/part of this at all)

- Implicit/from other pieces of marketing: We're a reputably company with these other big reputable companies who care about security and are juicy targets for attacks using this product.

- We update V8 within 24 hours of a security update, compared to weeks for the big juicy target of Google Chrome.

- We use various additional sandboxing techniques on top of V8, including the complete lack of high precision timers, and various OS level sandboxing techniques.

- We detect code doing strange things and move it out of the multi-tennant environment into an isolated one just in case.

- We detect code using APIs that increase the surface area (like debuggers) and move it out of the multi-tennant environment into an isolated on just in case.

- We will keep investing in security going forwards.

Running secure multi-tenant environments is not an easy problem. It seems unlikely that it's possible for a typical open source project (typical in terms of limited staffing, usually including a complete lack of on-call staff) to release software to do so today.

[max_lt]

Agreed. Cloudflare has dedicated security teams, 24h V8 patches, and years of hardening – I can't compete with that. The realistic use case for OpenWorkers is running your own code on your own infra, not multi-tenant SaaS. I will update the docs to reflect this.

[AgentME]

Something like "all code is run with no permissions to the filesystem or external IO by default, you have to do this to add fine-grained permissions for IO, the code is run within an unprivileged process that's sandboxed using standard APIs to defend in depth against possible v8 vulnerabilities, here's how this system protects against obvious possible attacks..." would be pretty good. Obviously it's not proof it's all implemented perfectly, but it would be a quick sign that the project is miles ahead of a naive implementation, and it would give someone interested some good pointers on what parts to start reviewing.

[max_lt]

This is exactly where we see things heading. The trust model is shifting - code isn't written by humans you trust anymore, it's generated by models that can be poisoned, confused, or just pick the wrong library.

We're thinking about OpenWorkers less as "self-hosted Cloudflare Workers" and more as a containment layer for code you don't fully control. V8 isolates, CPU/memory limits, no filesystem access, network via controlled bindings only.

We're also exploring execution recording - capture all I/O so you can replay and audit exactly what the code did.

Production bug -> replay -> AI fix -> verified -> deployed.

[simonw]

That's the problem! It's really hard to find trustworthy sandboxing solutions, I've been looking for a long time. It's kind of my white whale.

[laurencerowe]

As I understand it separate isolates in a single process are inherently less secure than separate processes (e.g. Chrome's site isolation) which is again less secure than virtualization based solutions.

As a TinyKVM / KVM Server contributor I'm obviously hopeful our approach will work out, but we still have some way to go to get to a level of polish that makes it easy to get going with and have the confidence of production level experience.

TinyKVM has the advantage of a much smaller surface area to secure as a KVM based solution and the ability to offer fast per-request isolation as we can reset the VM state a couple of orders of magnitude faster than v8 can create a new isolate from a snapshot.

https://github.com/libriscv/kvmserver

[indigodaddy]

I imagine you messed about with Sandstorm back in the day?

[d4mi3n]

Other response address how you could go about this, but I'd just like to note that you touch on the core problem of security as a domain: At the end of the day, it's a problem of figuring out who to trust, how much to trust them, and when those assessments need to change.

To use your example: Any cybersecurity firm or practitioner worth their salt should be *very* explicit about the scope of their assessment.

- That scope should exhaustively detail what was and wasn't tested.

- There should be proof of the work product, and an intelligible summary of why, how, and when an assessment was done.

- They should give you what you need to have confidence in *your understanding of* you security posture as well as evidence that you *have* a security posture you can prove with facts and data.

Anybody who tells you not to worry and take their word for something should be viewed with extreme skepticism. It is a completely unacceptable frame of mind when you're legally and ethically responsible for things you're stewarding for other people.