Remix.run Logo
pxc 2 hours ago

Install tools using a package manager that performs builds as an unprivileged user account other than your own, sandboxes builds in a way that restricts network and filesystem access, and doesn't run let packages run arbitrary pre/post-install hooks by default.

Avoid software that tries to manage its own native (external, outside the language ecosystem) 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
I think there's a lot of things to do here. The hardest parts are probably organizational and social; coordination is hard and network effects are strong. But I also think that there are some basics that help a lot. And developers who serve other developers, whether they are formally security professionals or not, are generally well-positioned to make it easier to do the right thing than the sloppy thing over time.