> Also, auditing the code you pull in. Yeah. Reading code sucks. Yeah. It's a lotta work. But if you don't check, you don't effing know.
While I do generally agree with this sentiment, it’s not always possible in the ways you imply:
- Plenty of systems pull packages that are not human readable. For example WASM plugins. Or it might even by in unfamiliar languages such as a Python package calling C.
- You might argue that “if you cannot understand the code then don’t use the package” but that isn’t always practical. Security packages will include maths that is beyond the average software engineer. Other performance-critical packages (such as libraries in the ML space) will have highly optimised code that isn’t easy for the average developer to read through.
- Some supply chain attacks have been targeting popular packages. So now you need to re-read every single point version (!!!) on every update. Heck, even using lock files to the patch version in semver might not save you for some language ecosystems because you can overwrite git tags. So a package version that is safe on your local machine might end up compromised when compiled via CI/CD.
- And then there’s CI/CD itself. We are seeing supply chain attacks in GitHub Actions plugins. So now you have to pin all of your actions to their SHA instead of semver.
There definitely needs to be a better security model to support developers because the current status quo makes it very hard to vet everything you run, and very easy to fuck up. In all other fields of IT, we’d say that was a failure of the process rather than a failure of the individual.
