6 ms·

We just can't trust dependencies and dev setups. I wanted to say "anymore" but we never could. Dev containers were never good enough, too clumsy and too little

We just can't trust dependencies and dev setups. I wanted to say "anymore" but we never could. Dev containers were never good enough, too clumsy and too little isolation. We need to start working in full sandboxes with defence in depth that have real guardrails and UIs like vm isolation + container primitives and allow lists, egress filters, seccomp, gvisor and more but with much better usability. Its the same requirements we have for agent runtimes, lets use this momentum to make our dev environments safer! In such an environment the container would crash, we see the violations, delete it and dont' have to worry about it. We should treat this as an everyday possibility not as an isolated security incident.

kalib_tweli 7mo ago
Would value your opinion on my project to isolate creds from the container: https://github.com/calebfaruki/tightbeam https://github.com/calebfaruki/tightbeam https://github.com/calebfaruki/airlock https://github.com/calebfaruki/airlock This is literally the thing I'm trying to protect against.
- jFriedensreich 7mo ago
  I would split the agent loop totally from the main project of tightbeam, no one wants yet another new agent harness we need to focus on the operational problems. Airlock seems interesting in theory but its really hard to believe this could capture every single behaviour of the native local binaries, we need the native tools with native behaviour otherwise might as well use something like MCP. I would bet more on a git protocol proxy and native solutions for each of these.
  - kalib_tweli 7mo ago
    Good points across the board. I ran into a lot of problems auditing the security of my approach and it was just too easy to circumvent. First lesson was that the architecture had to be secure in structure, not configuration. Otherwise, a novice will run claude code on the host machine and just bork the entire setup. So now I've replaced tightbeam runtime with a small runtime on the workspace container. Tightbeam and Airlock have been moved to separate pods. So you don't need network egress on the workspace pod at all. Secondly, I'm isolating credentials on Tightbeam and Airlock with k8s jobs. Rather than airlock full CLI commands, you just create "airlock tools" with k8s secrets. Airlock controller never sees the secret. The tool could be like "git-create-branch" and "gh-create-pr". Tightbeam is pretty much symmetrical. LLM credentials are tied to jobs. I'm tying them together into a unified architecture now. Please do let me know if you have additional thoughts!
binsquare 7mo ago
So... I'm working on an open source technology to make a literal virtual machine shippable i.e. freezing everything inside it, isolated due to vm/hypervisor for sandboxing, with support for containers too since it's a real linux vm. The problems you mentioned resonated a lot with me and why I'm building it, any interest in working to solve that together?: https://github.com/smol-machines/smolvm https://github.com/smol-machines/smolvm
- vladvasiliu 7mo ago
  What would the advantage of this be compared to using something like a Firecracker backend for containerd?
  - jFriedensreich 7mo ago
    firecracker does not run on macos and has no GPU support
  - binsquare 7mo ago
    Run locally on macs, much easier to install/use, and designed to be "portable" meaning you can package a VM to preserve statefulness and run it somewhere else. worked in AWS and specifically with firecracker in the container space for 4 years - we had a very long onboarding doc to dev on firecracker for containers... So I made sure to focus on ease of use here.
- Bengalilol 7mo ago
  Probably on the side of your project, but did you try SmolBSD? <https://smolbsd.org https://smolbsd.org> It's a meta-OS for microVMs that boots in 10–15 ms. It can be dedicated to a single service (or a full OS), runs a real BSD kernel, and provides strong isolation. Overall, it fits into the "VM is the new container" vision. Disclaimer: I'm following iMil through his twitch streams (the developer of smolBSD and a contributor to NetBSD) and I truly love what he his doing. I haven't actually used smolBSD in production myself since I don't have a need for it (but I participated in his live streams by installing and running his previews), and my answer might be somewhat off-topic. More here <https://hn.algolia.com/?q=smolbsd https://hn.algolia.com/?q=smolbsd>
amelius 7mo ago
We need programming languages where every imported module is in its own sandbox by default.
- jFriedensreich 7mo ago
  We have one where thats possible: workerd (apache 2.0) no new language needed just a new runtime
  - amelius 7mo ago
    I mean, the sandboxing aspect of a language is just one thing. We should have sandboxing in Rust, Python, and every language in between.
- jerf 7mo ago
  Now is probably a pretty good time to start a capabilities-based language if someone is able to do that. I wish I had the time.
- saidnooneever 7mo ago
  just sandbox the interpreter (in this case), package manager and binaries. u can run in chroot jail and it wouldnt have accessed ssh keys outside of the jail... theres many more similar technologies aleady existing, for decades. doing it on a per language basis is not ideal. any new language would have to reinvent the wheel. better to do it at system level. with the already existing tooling. openbsd has plege/unveil, linux chroot, namespaces, cgroups, freebsd capsicum or w/e. theres many of these things. (i am not sure how well they play within these scenarios, but just triggering on the sandboxing comment. theres plenty of ways to do it as far as i can tell...)
  - amelius 7mo ago
    What if I wanted to write a program that uses untrusted libraries, but also does some very security sensitive stuff? You are probably going to suggest splitting the program into microservices. But that has a lot of problems and makes things slow. The problem is that programs can be entire systems, so "doing it at the system level" still means that you'd have to build boundaries inside a program.
wswin 7mo ago
Containers prevent this kind of info stealing greatly, only explicitly provided creds would be leaked.
- jFriedensreich 7mo ago
  Containers can mean many things, if you mean plain docker default configured containers then no, they are a packaging mechanism not safe environment by themselves.
  - wswin 7mo ago
    They don't have access to the host filesystem nor environment variables and this attack wouldn't work.
    - jFriedensreich 7mo ago
      Just because this attack example did not contain container escape exploits does not mean this is safe. Its better than nothing but nothing that will save us.
      - lyu07282 7mo ago
        Those supply chain attacks we are seeing are bad, but if someone burns a 0day container escape for it, it would probably be a net positive effect on security overall. Just saying this is FUD.
        jFriedensreich 7mo ago
        FUD is crypto and tech bro speech. Using containers without vm, gvisor or similar is just irresponsible.
        lyu07282 7mo ago
        Oh you are young, FUD was criticism to IBM sales people scaring customers away from PC compatible clones.
cedws 7mo ago
This is the security shortcuts of the past 50 years coming back to bite us. Software has historically been a world where we all just trust each other. I think that’s coming to an end very soon. We need sandboxing for sure, but it’s much bigger than that. Entire security models need to be rethought.
- 1313ed01 7mo ago
  This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties. Which sounds great, but the way things work now tend to be the exact opposite of that, so there will be no trustable platform to run the untrusted code in. If the sandbox, or the operating system the sandbox runs in, will get breaking changes and force everyone to always be on a recent release (or worse, track main branch) then that will still be a huge supply chain risk in itself.
  - dotancohen 7mo ago
    > This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties. For the most part you can. Just version pin slightly-stale versions of dependencies, after ensuring there are no known exploits for that version. Avoid the latest updates whenever possible. And keep aware of security updates, and affected versions. Don't just update every time the dependency project updates. Update specifically for security issues, new features, and specific performance benefits. And even then avoid the latest version when possible.
    - 1313ed01 7mo ago
      Sure, and that is basically what sane people do now, but that only works until something needs a security patch that was not provided for the old version, and changing one dependency is likely to cascade so now I am open to supply chain attacks in many dependencies again (even if briefly). To really run code without trust would need something more like a microkernel that is the only thing in my system I have to trust, and everything running on top of that is forced to behave and isolated from everything else. Ideally a kernel so small and popular and rarely modified that it can be well tested and trusted.
dotancohen 7mo ago
> We just can't trust dependencies and dev setups. In one of my vibe coded personal projects (Python and Rust project) I'm actually getting rid of most dependencies and vibe coding replacements that do just what I need. I think that we'll see far fewer dependencies in future projects. Also, I typically only update dependencies when either an exploit is known in the current version or I need a feature present in a later version - and even then not to the absolute latest version if possible. I do this for all my projects under the many eyes principal. Finding exploits takes time, new updates are riskier than slightly-stale versions. Though, if I'm filing a bug with a project, I do test and file against the latest version.
- adw 7mo ago
  > In one of my vibe coded personal projects (Python and Rust project) I'm actually getting rid of most dependencies and vibe coding replacements that do just what I need. I think that we'll see far fewer dependencies in future projects. No free lunch. LLMs are capable of writing exploitable code and you don’t get notifications (in the eg Dependabot sense, though it has its own problems) without audits.
  - dotancohen 7mo ago
    My vibe coded personal projects don't have the source code available for attackers to target specifically.
    - heavyset_go 7mo ago
      You don't need open source access to be exploitable or exploited
    - nimih 7mo ago
      It might surprise you to learn that a large number of software exploits are written without the attacker having direct access to the program's source code. In fact, shocking as it may seem today, huge numbers of computers running the Windows operating system and Internet Explorer were compromised without the attackers ever having access to the source code of either.
uyzstvqs 7mo ago
That's no solution. If you can't trust and/or verify dependencies, and they are malicious, then you have bigger problems than what a sandbox will protect against. Even if it's sandboxed and your host machine is safe, you're presumably still going to use that malicious code in production.
- nazcan 7mo ago
  I'm supportive of going further - like restricting what a library is able to do. e.g. if you are using some library to compute a hash, it should not make network calls. Without sub-processes, it would require OS support.
  - fn-mote 7mo ago
    Which exists: pledge in OpenBSD. Making this work on a per-library level … seems a lot harder. The cost for being very paranoid is a lot of processes right now.
    - lanstin 7mo ago
      It's a language/compiler/function call stack feature, not existing as far as I know, but it would be awesome - the caller of a function would specify what resources/syscalls could be made, and anything down the chain would be thusly restricted. The library could try to do its phone home stats and it would fail. Couldn't be C or a C type language runtime, or anything that can call to assembly of course. @compute_only decorator. Maybe could be implemented as a sys-call for a thread - thread_capability_remove(F_NETWORK + F_DISK)? Wouldn't be able to schedule any work on any thread in that case, but Go could have pools of threads for coroutines with varying capabilities. Something to put the developer back in charge of the mountain of dependencies we are all forced to manage now.
  - azornathogron 7mo ago
    In type system theory I think what you're looking for is "effect systems". You make the type system statically encode categories of side-effects, so you can tell from the type of a function whether it is pure computation, or if not what other things it might do. Exactly what categories of side-effect are visible this way depends on the type system; some are more expressive than others. But it means when you use a hash function you can know that it's, eg, only reading memory you gave it access to and doing some pure computation on it.
kkralev 7mo ago
[dead]
dist-epoch 7mo ago
This stuff already exists - mobile phone sandboxed applications with intents (allow Pictures access, ...) But mention that on HN and watch getting downvoted into oblivion: the war against general computation, walled gardens, locked down against device owners...
- jFriedensreich 7mo ago
  You are not being downvoted because the core premise is wrong but because your framing as a choice between being locked out of general purpose computing vs security is repeating the brainwashing companies like apple and meta do to justify their rent-seeking locking out out of competitors and user agency. We have all the tools to build safe systems that don't require up front manifest declaration and app store review by the lord but give tools for control, dials and visibility to the users themselves in the moment. And yes, many of these UIs might look like intent sheets. The difference is who ultimately controls how these Interfaces look and behave.
- MiddleEndian 7mo ago
  You can have both. Bazzite Linux lets you sandbox applications and also control your own device.
udave 7mo ago
strongly agree. we keep giving away trust to other entities in order to make our jobs easier. trusting maintainers is still better than trusting a clanker but still risky. We need a sandboxed environment where we can build our software without having to worry about these unreliable factors. On a personal note, I have been developing and talking to a clanker ( runs inside ) to get my day to day work done. I can have multiple instances of my project using worktrees, have them share some common dependencies and monitor all of them in one place. I plan to opensource this framework soon.
deleted 7mo ago
[deleted]
fulafel 7mo ago
> In such an environment the container would crash, we see the violations, delete it and dont' have to worry about it. This is the interesting part. What kind of UI or other mechanisms would help here? There's no silver bullet for detecting and crashing on "something bad". The adversary can test against your sandbox as well.
poemxo 7mo ago
"Anymore" is right though. This should be a call to change the global mindset regarding dependencies. We have to realize that the "good ol days" are behind us in order to take action. Otherwise people will naysay and detract from the cause. "It worked before" they will say. "Why don't we do it like before?" DISA STIG already forbids use of the EPEL for Red Hat Enterprise Linux. Enterprise software install instructions are littered with commands to turn off gpgcheck and install rpm's from sourceforge. The times are changing and we need cryptographically verifiable guarantees of safety!
miraculixx 7mo ago
I agree in general, but how are you ever upgrading any of that? Could be a "sleeper compromise" that only activates sometime in the future. Open problem.
- jFriedensreich 7mo ago
  A sleeper compromise that cannot execute can still not reach its goal. Generally speaking outdated dependencies without known compromise in a sandbox are still better than the latest deps with or without sandbox.
Andrei_dev 7mo ago
Sandboxes yes, but who even added the dependency? Half the projects I see have requirements.txt written by Copilot. AI says "add litellm", dev clicks accept, nobody even pins versions. Then we talk about containment like anyone actually looked at that dep list.
Aurornis 7mo ago
> Dev containers were never good enough, too clumsy and too little isolation. I haven't kept up with the recent exploits, so a side question: Have any of the recent supply chain attacks or related exploits included any escapes from basic dev containers?
AbanoubRodolf 7mo ago
[flagged]
ashishb 7mo ago
> We need to start working in full sandboxes with defence in depth that have real guardrails Happily sandboxing almost all third-party tools since 2025. `npm run dev` does not need access to my full disk.
pjc50 7mo ago
The trouble with sandboxing is that eventually everything you want to access ends up inside the sandbox. Otherwise the friction is infuriating. I see people going in the opposite direction with "dump everything in front of my army of LLMs" setups. Horribly insecure, but gotta go fast, right?
deleted 7mo ago
[deleted]
claud_ia 7mo ago
[dead]

kalib_tweli 7mo ago

Would value your opinion on my project to isolate creds from the container: https://github.com/calebfaruki/tightbeam https://github.com/calebfaruki/tightbeam https://github.com/calebfaruki/airlock https://github.com/calebfaruki/airlock This is literally the thing I'm trying to protect against.

jFriedensreich 7mo ago
I would split the agent loop totally from the main project of tightbeam, no one wants yet another new agent harness we need to focus on the operational problems. Airlock seems interesting in theory but its really hard to believe this could capture every single behaviour of the native local binaries, we need the native tools with native behaviour otherwise might as well use something like MCP. I would bet more on a git protocol proxy and native solutions for each of these.
- kalib_tweli 7mo ago
  Good points across the board. I ran into a lot of problems auditing the security of my approach and it was just too easy to circumvent. First lesson was that the architecture had to be secure in structure, not configuration. Otherwise, a novice will run claude code on the host machine and just bork the entire setup. So now I've replaced tightbeam runtime with a small runtime on the workspace container. Tightbeam and Airlock have been moved to separate pods. So you don't need network egress on the workspace pod at all. Secondly, I'm isolating credentials on Tightbeam and Airlock with k8s jobs. Rather than airlock full CLI commands, you just create "airlock tools" with k8s secrets. Airlock controller never sees the secret. The tool could be like "git-create-branch" and "gh-create-pr". Tightbeam is pretty much symmetrical. LLM credentials are tied to jobs. I'm tying them together into a unified architecture now. Please do let me know if you have additional thoughts!

binsquare 7mo ago

So... I'm working on an open source technology to make a literal virtual machine shippable i.e. freezing everything inside it, isolated due to vm/hypervisor for sandboxing, with support for containers too since it's a real linux vm. The problems you mentioned resonated a lot with me and why I'm building it, any interest in working to solve that together?: https://github.com/smol-machines/smolvm https://github.com/smol-machines/smolvm

vladvasiliu 7mo ago
What would the advantage of this be compared to using something like a Firecracker backend for containerd?
- jFriedensreich 7mo ago
  firecracker does not run on macos and has no GPU support
- binsquare 7mo ago
  Run locally on macs, much easier to install/use, and designed to be "portable" meaning you can package a VM to preserve statefulness and run it somewhere else. worked in AWS and specifically with firecracker in the container space for 4 years - we had a very long onboarding doc to dev on firecracker for containers... So I made sure to focus on ease of use here.
Bengalilol 7mo ago
Probably on the side of your project, but did you try SmolBSD? <https://smolbsd.org https://smolbsd.org> It's a meta-OS for microVMs that boots in 10–15 ms. It can be dedicated to a single service (or a full OS), runs a real BSD kernel, and provides strong isolation. Overall, it fits into the "VM is the new container" vision. Disclaimer: I'm following iMil through his twitch streams (the developer of smolBSD and a contributor to NetBSD) and I truly love what he his doing. I haven't actually used smolBSD in production myself since I don't have a need for it (but I participated in his live streams by installing and running his previews), and my answer might be somewhat off-topic. More here <https://hn.algolia.com/?q=smolbsd https://hn.algolia.com/?q=smolbsd>

amelius 7mo ago

We need programming languages where every imported module is in its own sandbox by default.

jFriedensreich 7mo ago
We have one where thats possible: workerd (apache 2.0) no new language needed just a new runtime
- amelius 7mo ago
  I mean, the sandboxing aspect of a language is just one thing. We should have sandboxing in Rust, Python, and every language in between.
jerf 7mo ago
Now is probably a pretty good time to start a capabilities-based language if someone is able to do that. I wish I had the time.
saidnooneever 7mo ago
just sandbox the interpreter (in this case), package manager and binaries. u can run in chroot jail and it wouldnt have accessed ssh keys outside of the jail... theres many more similar technologies aleady existing, for decades. doing it on a per language basis is not ideal. any new language would have to reinvent the wheel. better to do it at system level. with the already existing tooling. openbsd has plege/unveil, linux chroot, namespaces, cgroups, freebsd capsicum or w/e. theres many of these things. (i am not sure how well they play within these scenarios, but just triggering on the sandboxing comment. theres plenty of ways to do it as far as i can tell...)
- amelius 7mo ago
  What if I wanted to write a program that uses untrusted libraries, but also does some very security sensitive stuff? You are probably going to suggest splitting the program into microservices. But that has a lot of problems and makes things slow. The problem is that programs can be entire systems, so "doing it at the system level" still means that you'd have to build boundaries inside a program.

wswin 7mo ago

Containers prevent this kind of info stealing greatly, only explicitly provided creds would be leaked.

jFriedensreich 7mo ago
Containers can mean many things, if you mean plain docker default configured containers then no, they are a packaging mechanism not safe environment by themselves.
- wswin 7mo ago
  They don't have access to the host filesystem nor environment variables and this attack wouldn't work.
  - jFriedensreich 7mo ago
    Just because this attack example did not contain container escape exploits does not mean this is safe. Its better than nothing but nothing that will save us.
    - lyu07282 7mo ago
      Those supply chain attacks we are seeing are bad, but if someone burns a 0day container escape for it, it would probably be a net positive effect on security overall. Just saying this is FUD.
      - jFriedensreich 7mo ago
        FUD is crypto and tech bro speech. Using containers without vm, gvisor or similar is just irresponsible.
        lyu07282 7mo ago
        Oh you are young, FUD was criticism to IBM sales people scaring customers away from PC compatible clones.

cedws 7mo ago

This is the security shortcuts of the past 50 years coming back to bite us. Software has historically been a world where we all just trust each other. I think that’s coming to an end very soon. We need sandboxing for sure, but it’s much bigger than that. Entire security models need to be rethought.

1313ed01 7mo ago
This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties. Which sounds great, but the way things work now tend to be the exact opposite of that, so there will be no trustable platform to run the untrusted code in. If the sandbox, or the operating system the sandbox runs in, will get breaking changes and force everyone to always be on a recent release (or worse, track main branch) then that will still be a huge supply chain risk in itself.
- dotancohen 7mo ago
  > This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties. For the most part you can. Just version pin slightly-stale versions of dependencies, after ensuring there are no known exploits for that version. Avoid the latest updates whenever possible. And keep aware of security updates, and affected versions. Don't just update every time the dependency project updates. Update specifically for security issues, new features, and specific performance benefits. And even then avoid the latest version when possible.
  - 1313ed01 7mo ago
    Sure, and that is basically what sane people do now, but that only works until something needs a security patch that was not provided for the old version, and changing one dependency is likely to cascade so now I am open to supply chain attacks in many dependencies again (even if briefly). To really run code without trust would need something more like a microkernel that is the only thing in my system I have to trust, and everything running on top of that is forced to behave and isolated from everything else. Ideally a kernel so small and popular and rarely modified that it can be well tested and trusted.

dotancohen 7mo ago

> We just can't trust dependencies and dev setups. In one of my vibe coded personal projects (Python and Rust project) I'm actually getting rid of most dependencies and vibe coding replacements that do just what I need. I think that we'll see far fewer dependencies in future projects. Also, I typically only update dependencies when either an exploit is known in the current version or I need a feature present in a later version - and even then not to the absolute latest version if possible. I do this for all my projects under the many eyes principal. Finding exploits takes time, new updates are riskier than slightly-stale versions. Though, if I'm filing a bug with a project, I do test and file against the latest version.

adw 7mo ago
> In one of my vibe coded personal projects (Python and Rust project) I'm actually getting rid of most dependencies and vibe coding replacements that do just what I need. I think that we'll see far fewer dependencies in future projects. No free lunch. LLMs are capable of writing exploitable code and you don’t get notifications (in the eg Dependabot sense, though it has its own problems) without audits.
- dotancohen 7mo ago
  My vibe coded personal projects don't have the source code available for attackers to target specifically.
  - heavyset_go 7mo ago
    You don't need open source access to be exploitable or exploited
  - nimih 7mo ago
    It might surprise you to learn that a large number of software exploits are written without the attacker having direct access to the program's source code. In fact, shocking as it may seem today, huge numbers of computers running the Windows operating system and Internet Explorer were compromised without the attackers ever having access to the source code of either.

uyzstvqs 7mo ago

That's no solution. If you can't trust and/or verify dependencies, and they are malicious, then you have bigger problems than what a sandbox will protect against. Even if it's sandboxed and your host machine is safe, you're presumably still going to use that malicious code in production.

nazcan 7mo ago
I'm supportive of going further - like restricting what a library is able to do. e.g. if you are using some library to compute a hash, it should not make network calls. Without sub-processes, it would require OS support.
- fn-mote 7mo ago
  Which exists: pledge in OpenBSD. Making this work on a per-library level … seems a lot harder. The cost for being very paranoid is a lot of processes right now.
  - lanstin 7mo ago
    It's a language/compiler/function call stack feature, not existing as far as I know, but it would be awesome - the caller of a function would specify what resources/syscalls could be made, and anything down the chain would be thusly restricted. The library could try to do its phone home stats and it would fail. Couldn't be C or a C type language runtime, or anything that can call to assembly of course. @compute_only decorator. Maybe could be implemented as a sys-call for a thread - thread_capability_remove(F_NETWORK + F_DISK)? Wouldn't be able to schedule any work on any thread in that case, but Go could have pools of threads for coroutines with varying capabilities. Something to put the developer back in charge of the mountain of dependencies we are all forced to manage now.
- azornathogron 7mo ago
  In type system theory I think what you're looking for is "effect systems". You make the type system statically encode categories of side-effects, so you can tell from the type of a function whether it is pure computation, or if not what other things it might do. Exactly what categories of side-effect are visible this way depends on the type system; some are more expressive than others. But it means when you use a hash function you can know that it's, eg, only reading memory you gave it access to and doing some pure computation on it.

kkralev 7mo ago

[dead]

dist-epoch 7mo ago

This stuff already exists - mobile phone sandboxed applications with intents (allow Pictures access, ...) But mention that on HN and watch getting downvoted into oblivion: the war against general computation, walled gardens, locked down against device owners...

jFriedensreich 7mo ago
You are not being downvoted because the core premise is wrong but because your framing as a choice between being locked out of general purpose computing vs security is repeating the brainwashing companies like apple and meta do to justify their rent-seeking locking out out of competitors and user agency. We have all the tools to build safe systems that don't require up front manifest declaration and app store review by the lord but give tools for control, dials and visibility to the users themselves in the moment. And yes, many of these UIs might look like intent sheets. The difference is who ultimately controls how these Interfaces look and behave.
MiddleEndian 7mo ago
You can have both. Bazzite Linux lets you sandbox applications and also control your own device.

udave 7mo ago

strongly agree. we keep giving away trust to other entities in order to make our jobs easier. trusting maintainers is still better than trusting a clanker but still risky. We need a sandboxed environment where we can build our software without having to worry about these unreliable factors. On a personal note, I have been developing and talking to a clanker ( runs inside ) to get my day to day work done. I can have multiple instances of my project using worktrees, have them share some common dependencies and monitor all of them in one place. I plan to opensource this framework soon.

deleted 7mo ago

[deleted]

fulafel 7mo ago

> In such an environment the container would crash, we see the violations, delete it and dont' have to worry about it. This is the interesting part. What kind of UI or other mechanisms would help here? There's no silver bullet for detecting and crashing on "something bad". The adversary can test against your sandbox as well.

poemxo 7mo ago

"Anymore" is right though. This should be a call to change the global mindset regarding dependencies. We have to realize that the "good ol days" are behind us in order to take action. Otherwise people will naysay and detract from the cause. "It worked before" they will say. "Why don't we do it like before?" DISA STIG already forbids use of the EPEL for Red Hat Enterprise Linux. Enterprise software install instructions are littered with commands to turn off gpgcheck and install rpm's from sourceforge. The times are changing and we need cryptographically verifiable guarantees of safety!

miraculixx 7mo ago

I agree in general, but how are you ever upgrading any of that? Could be a "sleeper compromise" that only activates sometime in the future. Open problem.

jFriedensreich 7mo ago
A sleeper compromise that cannot execute can still not reach its goal. Generally speaking outdated dependencies without known compromise in a sandbox are still better than the latest deps with or without sandbox.

Andrei_dev 7mo ago

Sandboxes yes, but who even added the dependency? Half the projects I see have requirements.txt written by Copilot. AI says "add litellm", dev clicks accept, nobody even pins versions. Then we talk about containment like anyone actually looked at that dep list.

Aurornis 7mo ago

> Dev containers were never good enough, too clumsy and too little isolation. I haven't kept up with the recent exploits, so a side question: Have any of the recent supply chain attacks or related exploits included any escapes from basic dev containers?

AbanoubRodolf 7mo ago

[flagged]

ashishb 7mo ago

> We need to start working in full sandboxes with defence in depth that have real guardrails Happily sandboxing almost all third-party tools since 2025. `npm run dev` does not need access to my full disk.

pjc50 7mo ago

The trouble with sandboxing is that eventually everything you want to access ends up inside the sandbox. Otherwise the friction is infuriating. I see people going in the opposite direction with "dump everything in front of my army of LLMs" setups. Horribly insecure, but gotta go fast, right?

deleted 7mo ago

[deleted]

claud_ia 7mo ago

[dead]