Most of What You Ship, You Did Not Write

Last timeThe Settings Nobody Changed

You chose forty packages and you run a thousand. A report arrives about one of them. The useful questions are what you actually run, whether it is reachable, and what to do.

What you actually run

Open the file where your dependencies are listed. It has perhaps forty

entries, each chosen by somebody who had a reason. Now look at what

actually gets installed. It is a thousand packages, or several thousand,

written by hundreds of people, and nobody on your team has read a line of

the overwhelming majority of it.

FIG 1How your list becomes your closure

: packages actually installed and running
: dependencies you chose deliberately
: average packages brought in per chosen one

The packages you run n is roughly the number you chose d times the average number each brings with it f. The multiplier is not two or three; measured across ecosystems it is routinely twenty or thirty, because each dependency has its own list and the expansion repeats until it stops. Everything beyond d is code that arrived without a decision.

FIG 2Where the installed packages came from

Four per cent of what you install was a decision. The large middle is the part that matters most and gets attention least, because there is nobody whose job it is: the team that chose a package did not choose its dependencies, and the maintainer who did choose them is not responsible for your system.

Two consequences follow immediately. First, you cannot answer any

question about your exposure without a list of what is actually installed,

resolved, with versions, which is a file your build already produces and

nobody reads. Second, the build-only portion is worth separating, because

a flaw in something that runs only on your build machine is a different

problem than one in something that serves requests, and it is sometimes

the more serious of the two since build machines hold credentials.

An advisory is not a finding

A report arrives. A library you depend on, three levels down, has a

published flaw. The scanner marks it serious and your tooling turns red.

That report is a fact about a library. It is not yet a fact about your

system, and treating the two as the same thing produces the failure mode

every team with a scanner eventually reaches: a long red list that nobody

can act on, which is then ignored entirely, including the three entries

that mattered.

The lesson stops here

3 more paragraphs to go

You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.

The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.

See the plan The contents

This is the reading half

Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.

The contents

Most of What You Ship, You Did Not Write

What you actually run

An advisory is not a finding

3 more paragraphs to go

This is the reading half

Read alongside