firecracker-microvm/firecracker: technical due diligence, read from its repository

The median source file here is 154 lines. 11 files exceed 1,540 lines, the largest being 2,935. Size is not a defect on its own — some problems genuinely live in one place — but these are where merge conflicts, review fatigue and single-owner knowledge concentrate, and they are the first thing that slows an inheriting engineer down.

The newest release, v1.17.0, is not on the branch this survey read; the newest release on it is v1.2.0. The shipped product may differ from what this report describes. Survey the release branch too.

1 step pipes a download straight into a shell. Tags have been moved to malicious commits in real supply-chain attacks, and a piped script is whatever the server returns that minute. Pinning to a commit is the fix, and it is small.

Third-party code is committed into this repository without any statement of the terms it arrived under. Unknown terms are harder to deal with than inconvenient ones: an awkward licence can be complied with, an absent one cannot. Each of these needs its origin established before the code changes hands.

The newest was published on 2026-04-07. A project that publishes advisories is telling its users about its fixes, and the count and pace say how much security work it carries. Whether 2 of them are fixed in the code you ship could not be told from this history: its version is only known to be at least 1.2.0. Answer lives in: the release you run, set against each fixed version.

Nothing in the service initialises an error reporter (Sentry, Rollbar, Bugsnag, Honeybadger or an APM agent). An exception in production reaches a person only if someone is reading the logs, which usually means a customer reports it first.