Completely agree tbh, and that would be one of my preferred approaches should npm be the actor to implement a solution.

I also think it makes sense for GitHub to implement the ability to mark a workflow as sensitive and requiring "sudo mode" (MFA prompt) to run. It's not miles away from what they already do around requiring maintainer approval to run workflows on PRs.

Ideally both of these would exist, as not every npm package is published via GitHub actions (or any CI system), and not every GitHub workflow taking a sensitive action is publishing an npm package.

There’s also a cost that installs take much longer, you need the full toolchain installed, and are no longer reproducible due to variations in the local build environment. If everything you do is a first-party CI build of a binary image you deploy, that’s okay but for tools you’re installing outside of that kind of environment it adds friction.

npm has had support for package-scoped publish tokens (with optional 2FA enforcement) for a few years by now. So in case of compromise, the blast radius would be a single package.

The OP gave the GH repo too broad permissions. There is no good reason for the repo CI workflow to have full access to everything under their account.

Thinking of biology, the reason often given for the disappearance of "unused" genes/base-pairs is that there's a metabolic cost to keeping them around and copying them on every cell division, so they vanish from a form of passive attrition.

I wonder if someday we'll find there's also a more active process, which resembles "remove old shit because it may contain security vulnerabilities."

I was confused too. Was it your npm token stored in angulartics2 as a Github Actions secret, so it could publish new angulartics2 versions?

I'm not sure why we never got around to more human in the loop with 2FA when it comes to this sort of stuff: "Oh, you want to publish a new package? Okay, confirm it on this app on your device/phone to make sure." Surely a button press on a pre-approved device wouldn't be too hard, pretty much how every user initiated online banking payment over here goes like.

I once heard from a sysadmin that didn't want to automate certificate renewal and other things, because he believed that doing so would take away useful skills or some inner knowledge of how the system works. Because of the human error risk, I thought that was stupid, but when it comes to approval processes, I think it makes sense. Especially because pushing code doesn't necessarily mean the same thing as such an approval, or the main device that you push code from could also get compromised, using your phone as 2FA could save you.

Then again, maybe I'm also stupid and the way we build our software is messed up on a fundamental level with all of the dependencies and nobody being able to practically audit all of the code they import, given deadlines, limited skills and resources and so on. Maybe it's all just fighting against a windmill.

The conclusion I'm coming to is that depending on packages which only have a single author is problematic. There are too many ways that packages published by one person can be compromised.

Packages which don't have approval and review by a reliable third party shouldn't be visible by default in a package manager.

and (as in this case), that 1 author may use a single token to authz publishing many packages

Yep I did see that, but I'm not planning on pushing anything, just want a tool to scan for any of the offending packages. Could make my own but feel like somebody must have already made something (and probably better than I can)

So add a wrapper for that, a quick script that checks which branch and revision you are publishing from. The issue here is publishing from a CI you do not control that well and with automated events.

You can run the exact same script locally as you do in CI, with the only difference being the addition of a 2FA prompt.

"Without a human in the loop, there’s still some “thing” that gets compromised, whether it’s a token or something that generates time-limited tokens."

Speaking knowingly reductionistically and with an indeterminate amount of sarcasm, one of the hardest problems in security is how to know something without knowing something. The first "knowing something" is being able to convince a security system to let you do something, and the second is the kind that an attacker can steal.

We do a lot of work trying to separate those two but it's a really, really hard problem, right down at its very deepest core.

I know I was amused 5-10 years ago as we went through a lot of gymnastics. "We have an SSH password here that we use to log in to this system over there and run this process." "That's not secure, because an attacker can get the password. Move that to an SSH key." "That's not secure, an attacker can get the key. Move the key into this secret manager." "That's not secure, an attacker can get into the secret manager. Move it to this 2FA system." "That's not secure, an attacker can get the 2FA token material, move it to...."

There are improvements you can make; if nothing else a well-done 2FA system means an attacker has to compromise 2 systems to get in, and if they are non-correlated that's a legit step up. But I don't think there's a full solution to "the attacker could" in the end. Just improvements.

Hence you need to start thinking about threat models and levels of compromise, even in your build system.

If I control the issuing and governance of these short-lived secrets, they very much help against many attacks. Go ahead and extract an upload token for one project which lives for 60 seconds, be my guest. Once I lose control how these tokens are created, most of these advantages go away - you can just create a token every minute, for any project this infrastructure might be responsible for.

If I maintain control about my pipeline definition, I can again do a lot of work to limit damage. For example, if I am in control, I can make sure the stages running untrusted codes have as little access to secrets as possible, and possibly isolate them in bubblewrap, VMs, ..., minimize the code with access to publishing rights. Once I lose control about the pipeline structure, all that goes away. Just add a build step to push all information and secrets to mastodon in individual toots, yey.

To me, this has very much raised questions about keeping pipeline definitions and code in one repository. Or at least, to keep a publishing/release process in there. I don't have a simple solution there, especially for OSS software with little infrastructure - it's not an easy topic. But with these supply chain attacks coming hot and fast every 2 weeks, it's something to think about.

Universal OIDC tokens would slow down the lateral expansion and make it more difficult.

You won't be able to exfiltrate a token that allows you to publish an NPM package outside of a workflow, the infection has to happen during a build on GH.