Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

Most of these attacks don't make it into the upstream source, so solutions[1] that build from source get you ~98% of the way there. If you can't get a from-source build vs. pulling directly from the registries, can reduce risk somewhat with a cooldown period.

For the long tail of stuff that makes it into GitHub, you need to do some combination of heuristics on the commits/maintainers and AI-driven analysis of the code change itself. Typically run that and then flag for human review.

[1] Here's the only one I know that builds everything from source: https://www.chainguard.dev/libraries

(Disclaimer: I work there.)

With pnpm, you can also use trustPolicy: no-downgrade, which prevents installing packages whose trust level has decreased since older releases (e.g. if a release was published with the npm cli after a previous release was published with the github OIDC flow).

Another one is to not run post-install scripts (which is the default with pnpm and configurable with npm).

These would catch most of the compromised packages, as most of them are published outside of the normal release workflow with stolen credentials, and are run from post-install scripts

I know it's far from watertight (and it's useless if you're working with bitwarden itself), but I hope it blocks the low hanging fruit sort of attacks.

Avoid software that tries to manage its own native dependencies or otherwise needs pre/post-install hooks to build.

If you do packaging work, try to build packages from source code fetched directly from source control rather than relying on release tarballs or other published release artifacts. These attacks are often more effective at hiding in release tarballs, NPM releases, Docker images, etc., than they are at hiding in Git history.

Learn how your tools actually build. Build your own containers.

Learn how your tools actually run. Write your own CI templates.

My team at work doesn't have super extreme or perfect security practices, but we try to be reasonably responsible. Just doing the things I outlined above has spared me from multiple supply chain attacks against tools that I use in the past few weeks.

Platform, DevEx, and AppSec teams are all positioned well to help with stuff like this so that it doesn't all fall on individual developers. They can:

  - write and distribute CI templates
  - run caches, proxies, and artifact repositories which might create room to
    - pull through packages on a delay
    - run automated scans on updates and flag packages for risks?
    - maybe block other package sources to help prevent devs from shooting themselves in the foot with misconfiguration
  - set up shared infrastructure for CI runners that
    - use such caches/repos/proxies by default
    - sandbox the network for build$
    - help replace or containerize or sandbox builds that currently only run on bare metal on some aging Jenkins box on bare metal
  - provide docs
    - on build sandboxing tools/standards/guidelines
    - on build guidelines surrounding build tools and their behaviours (e.g., npm ci vs npm install, package version locking and pinning standards)
  - promote packaging tools for development environments and artifact builds, e.g.,
    - promote deterministic tools like Nix
    - run build servers that push to internal artifact caches to address trust assumptions in community software distributions
    - figure out when/whether/how to delegate to vendors who do these things

You're still pulling a lot of dependencies. At least they're pinned though.

My two most precious digital possessions - my email and my Bitwarden account - are protected by a Yubikey that's always on my person (and another in another geographical location). I highly recommend such a setup, and it's not that much effort (I just keep my Yubikey with my house keys)

I got a bit scared reading the title, but I'm doing all I can to be reasonably secure without devolving into paranoia.

tl;dr

- https://cooldowns.dev

- https://depsguard.com

(disclaimer: I maintain the 2nd one, if I knew of the first, I wouldn't have released it, just didn't find something at that time, they do pretty much the same thing, mine in a bit of an overkill by using rust...)

That password cannot be cracked because it will always display as ** for anyone else.

My password is *****. See? It shows as asterisks so it's totally safe to share. Try it!

... Scnr •́ ‿ , •̀

obvious misdirection, but it does serve to make it very obvious it was a state actor.

Bitwarden vaults were not compromised, there was a problem in a tool you used to access the secrets.

What makes it impossible for KeePass access tools to have these issues?

https://cyberpress.org/hackers-exploit-keepass-password-mana...

I wrote a version in Python and then rust back before the official CLI was released. Now you can use https://github.com/doy/rbw instead, much better maintained (since I don't use Bitwarden anymore).

Assuming you had it already installed, you would be safe.

I lean toward cooldown by default, and bypass it when an actual reachable exploitable ZeroDay CVE is released.

> Bitwarden’s Chrome extension, MCP server, and other legitimate distributions have not been affected yet.

A password manager absolutely does need a CLI tool??

Not to mention that a graphical application is just as vulnerable to supply chain attacks.

Why not? Even macos keychain supports cli.

That's a wild statement. The CLI is just another UI.

The problem in this case is JS and the NPM ecosystem. Go would be an improvement, but complexity is the enemy of security. Something like (pass)age is my preference for storing sensitive data.