abhisek

This is exactly what PMG is designed for ie. install/build time process level sandboxing. It currently doesn't support cargo, but I believe the challenges are same.

Here is my learning building PMG:

Sandboxing is good when the workload is predictable, and the goal of sandbox is to guard against exploitation of vulnerabilities, like sandbox protecting chrome tabs (renderers). But unfortunately build scripts are not predictable, at least not in npm/pypi world and I have seen build scripts doing weirdest of the things which is no different from malware. When popular packages do weird things, build breaks and users end up turning off the sandbox. This is a perpetual problem to deal with while building sandbox (or any least privilege solution) to protect unbounded workloads.

https://github.com/safedep/pmg

GitHub announced this a while back:

https://github.blog/changelog/2026-07-28-npm-publish-time-ma...

#2 post on HN currently is: India’s first privately developed rocket reaches orbit on dramatic debut launch. In the same page, there is this news about banning an OSS app, built on open tech. Just saying.

Over engineering is really an NFR of green field projects.

Building Package Manager Guard (PMG) - https://github.com/safedep/pmg

With all the supply chain attacks on OSS ecosystems targeting developers, PMG is a practical protection using a combination of threat intel, policy and sandbox.

It’s a package firewall on the terminal really. It has been surprisingly effective against most of the recent attacks.

Smells like contagious interview campaign by DPRK folks. They have been doing this for a while. Even using IDE settings, Claude hooks for malicious code execution.

Attackers are just having fun due to abysmal state of npm and some of the insecure design choices by GitHub and GitHub Actions. Every attack gives them credentials which in turn used to stage more attacks.

I partly agree. Agents are not going to replace senior devs. Exactly for the internal context and the decision making that comes with it.

But senior devs are also expected to have a compounding effect even pre-AI. Writing a single doc, refactoring legacy code to make it extensible, building security frameworks specific to the project and many more. All of these would compound the dev team.

I think the same will happen with agents working on a org specific paved path set by senior devs.

Just implemented Landlock + seccomp notify based sandbox in PMG. A tool to protect cli package managers against malicious packages. There were quite a few quirks involved due to Go routines when it comes to handling messages from the kernel.

https://github.com/safedep/pmg

We just analysed the payload. Technical details here: https://safedep.io/malicious-litellm-1-82-8-analysis/

We are looking at similar attack vectors (pth injection), signatures etc. in other PyPI packages that we know of.

I have been using superpowers for Gryph development for a while. Love the brainstorming and exploration that it brings in. Haven’t really compared token usage but something in my bucket.

I think this is the right approach to building sandbox for agents ie. over existing OS native sandbox capabilities so that they are truly enforced.

However the challenge is, sandbox profiles (rules) are always workload specific. How do you define “least privilege” for a workload and then enforce it through the sandbox.

Which is why general sandboxes wont be useful or even feasible. The value is observing and probably auto-generating baseline policy for a given workload.

Wrong or overly relaxed policies would make sandbox ineffective against real threats it is expected to protect against.

We found a malicious npm package pino-sdk-v2 impersonating pino, one of the most widely used Node.js loggers with nearly 20 million weekly downloads. The package is a near copy of pino’s source, docs, and README with one addition: an obfuscated payload in lib/tools.js that scans .env files for secrets and exfiltrates them to a Discord webhook on require().

pino-sdk-v2@9.9.0 copies pino’s entire source tree with a single modification: obfuscated credential stealing code injected into lib/tools.js

The payload scans .env, .env.local, .env.production, .env.development, and .env.example for secret keys

Extracted credentials are sent to a hardcoded Discord webhook

No install hooks. The code executes on require(), bypassing scanners that only flag install scripts

Everybody wants to build infra. Automate something which is known and well understood. Hoping someone else will use it to solve end user's problem which is hard to understand, messy and often highly contextual.

To summarize: Everyone wants to automate stuff. Most people do not want to touch boring, large problems.

110 tools. That’s probably a reason why Anthropic is probably switching to sandboxed code execution over MCPs.

It’s just easier to write code and do something specific for a task than load so many tool metadata.

I did not go past IDA. But I remember idc and IDA python. I wonder if it’s a better approach to expose a single tool to execute scripts to query what the agent needs.

I see this as “libs” for the agents. They can discover relevant skills by searching a known index, extend their capability for on a given task.

While this makes sense for higher autonomy, it brings the well known supply chain security issue.

Currently all index list skills that are unverified. There are already examples of malicious skills.

LFS. Brings back so many painful memories. But then, learned so much.

Loved the idea of AI talking to AI and inventing something new.

Sure. You can dump the DB. Most of the data was public anyway.

Tried installing clawdbot. Got blocked by (my own) sandbox because it tried to git clone some stuff which in turn was accessing my private keys.

- clawdbot depends on @whiskeysockets/baileys

- @whiskeysockets/baileys depends on libsignal

npm view @whiskeysockets/baileys dependencies

[..] libsignal: 'git+https://github.com/whiskeysockets/libsignal-node.git', [..]

libsignal is not a regular npm package but a GitHub repository, which need to be cloned and built locally.

So suddenly, my sandbox profile, tuned for npm package installation no longer works because npm decides to treat my system as a build environment.

May be genuine use-case but its hard to keep up.

I still think metadata associated with packages (like stars, download count and more) are easy to fake and not the best metric. OpenSSF scorecard has some adoption among project maintainers but hardly any adoption in terms of making security decision based on it.

IMHO code is the source of truth. It may seem infeasible to mass analyse OSS code, but given the recent incidents (Shai-Hulud et.al) I think that’s the way forward. Personally am more bullish on SLSA or other artefact provenance technology adoption. Till that happens, metadata will be misused by attackers.

Documenting technical details and payload analysis here: https://safedep.io/shai-hulud-second-coming-supply-chain-att...

Like previous variant, it has credential harvesting, self-replication and GitHub public repository based exfiltration.

Double base64 encoded credentials being exposed using GitHub repositories: https://github.com/search?q=%22Sha1-Hulud%3A%20The%20Second%...

This is crazy. The internet has so much direct and transitive dependency on Cloudflare today. Pretty much the #1 dev slacking excuse today is no longer code compiling but cloudflare is down.

Building vet. The goal is to automate open source package vetting beyond just CVE but actually identify code capabilities, malicious code and other security sensitive attributes through code analysis.

https://github.com/safedep/vet

May be give vet a try. It detected most of the malicious packages within few hours of publishing to npm.

GitHub: https://github.com/safedep/vet

Good idea. Just the other day I was thinking of writing a templatized generator for coding agent instructions for various agents like Claude Code, GitHub Copilot and others that use their own unique file convention.

About time. Much needed. I just wish this was open source and built in public.

On my todo list to build a bot that finds sly AI responses for engagement farming

Love it. Thanks for taking the time to write this. Hope it will encourage more folks to contribute.

Uh oh. I am thinking all the ways this can be misused to ship malicious dependencies. Pretty much all SCA tools today will be blind to this.

Yes. Many times. Kubernetes upgrade during maintenance schedule borks up entire cluster, yet everything is green on status page. Support case under enterprise support plan took almost 6 hours to get it resolved.

The thing that people miss out is Git is really a content addressed storage. This means all commits, even the ones not linked to any refs are still stored and addressable.

p.s: If you run OSS project, please use Github Advanced Security and enable Push Protection against secrets.