Security Trust

Dependencies are part of the threat model

2 min read

A dependency changes more than the import graph.

It can alter install-time behavior, production authority, native build requirements, patch speed, and the amount of code a team must trust. A formatter, an HTML sanitizer, an image library, and a browser package do not have the same surface.

On this site, Astro, MDX, React islands, Tailwind, sharp, sanitize-html, zod, biome, and rumdl each do different work. The useful review question is not whether a package is popular. It is what the package can do, where it runs, and how painful it would be to remove.

A small review note is often enough:

adds: sanitize-html
purpose: strip unsafe markup before rendering content
surface: build/server only
why not custom code: edge cases are easy to miss
watch item: security fixes and changelog activity

That note gives the next maintainer a reason, a boundary, and a removal signal.

Install time deserves special attention. Postinstall scripts, native builds, and binary downloads happen while everyone thinks they are simply installing the project. A package that needs that work is not automatically wrong. The team should know it is happening and understand what breaks when the platform changes.

Maintenance is part of the threat model too. A library with active releases and a clean ecosystem is easier to patch than an abandoned package with frozen peers and unusual build steps. A short import can still bring a large transitive tree. Removal cost is part of the original decision.

Before approving a package, I want answers to a short set of questions:

  • Does it run during install?
  • Does it run in production?
  • Does it parse untrusted input?
  • Does it touch the filesystem or network?
  • What does its transitive tree add?
  • How quickly could the team patch or remove it?

That is threat modeling in ordinary review language. It keeps the project explainable without pretending a dependency-free system is the goal.

Packages earn their place when their authority is understood, their maintenance path is visible, and somebody can still explain why they exist after the original feature has shipped.

Jeremy London

About Jeremy London

Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.