Size-anomaly chip

The size-anomaly chip (#673) renders beside the verdict pill in the assessed-versions table on the packages search. It’s the pre-scan layer’s way of saying “this tarball has a shape that’s historically been a supply-chain compromise tell.”

What you see

A small chip in the verdict cell, reading size anomaly <reason> <observed-size>:

• size anomaly size_jump_5x_median 42 MB — the tarball is more than 5× the median of the three most recent prior versions of this package.
• size anomaly tarball_too_large — the tarball hit the 200 MiB cap during the pre-scan. The observed size may be absent because the scan never finished measuring before hitting the cap.

The chip’s title attribute (tooltip on hover) carries the raw reason token verbatim — size_jump_5x_median or tarball_too_large. SIEM pivots and table filters can key off that token without re-deriving from the pill label.

The chip appears alongside the version’s verdict pill; depending on policy, the verdict itself may be BLOCKED (the pre-scan layer escalated) or SAFE with a chip-only warning. The chip is the signal; the verdict is the enforcement.

When it appears

• The version trips one of the size-anomaly checks in the pre-scan layer.
• The check ran to completion or hit a defined cap; partial / errored scans don’t render the chip.
• The chip is per-version — rows for other versions of the same package render independently.

It does not render for:

• Versions that haven’t been pre-scanned (very old assessed versions from before the pre-scan layer existed).
• Versions where the tarball wasn’t fetchable (e.g. ecosystem doesn’t ship tarballs; manifest-only).

What the reasons actually mean

• size_jump_5x_median is the historically high-signal one. Real compromises that fit this shape: event-stream@3.3.6, ua-parser-js@0.7.29. A version that ships 5× more code than the three before it is either a major refactor (uncommon for patch releases) or an attacker has packed something extra in. The chip surfaces it; an operator decides which.
• tarball_too_large is the safety-rail one. The 200 MiB cap protects the pre-scan from runaway tarballs; hitting it doesn’t prove malice, just that the version is unusual. Most legitimate packages don’t ship tarballs above that cap.

What to do based on what you see

• Chip on a version that’s actively blocking a build. Open the row’s audit detail and confirm the verdict_source is size-jump. If it is, this is the pre-scan layer doing its job. Read the version’s release notes — is the size jump explained by a legitimate change (vendored binary, new format, …)? If yes, an allowlist entry for this version with the size jump noted in the # reason is appropriate. If you can’t explain the jump, treat it as a probable compromise: don’t allowlist, pin to the prior version.
• size_jump_5x_median on a fresh major release. Major bumps sometimes ship vendored dependencies that legitimately balloon the tarball. The chip is right that the shape is unusual; whether it’s malicious is a human judgement.
• tarball_too_large on a known-large package (TeX distributions, ML model packages, etc.). The cap is a pre-scan safety rail. Operators expecting these packages can allowlist the specific version; long-term, the cap may need tuning per ecosystem.
• Chip absent on a version a developer expected to be flagged. The pre-scan layer may not have measured this version yet — check the source column (proxy:<ecosystem>:tarball indicates a measured tarball; manifest indicates the version was assessed from manifest data only).

For the broader picture of how size-jump fits into the overall verdict pipeline, see verdicts and the scanner. For policy levers, see policy overrides.