Sign Here: Attributing a Source for a More Trustworthy Software Supply Chain

What it is

"Sign Here" is an October 2026 arXiv paper by Derek Garcia of Chainguard. It tests one rule as a malware filter: only install a package if its metadata attributes a source repository you could clone and build, and skip the registry artifact. The authors' hypothesis is that malicious packages avoid naming a source to stay hidden, while benign ones link their repositories for visibility. The data and analysis are public at https://github.com/chainguard-sandbox/build-from-source.

How it works

The paper defines three kinds of source attribution:

• Direct source: a cloneable URL with a domain, owner and repository, such as a GitHub, GitLab or Bitbucket repo link. This counts.
• Derived source: a direct source that can be extracted from another metadata URL with no network request. For example, https://github.com/foo/bar can be derived from https://github.com/foo/bar/issues in a "bugs" or "homepage" key. This counts when it can reasonably be derived.
• Interpreted source: one found only by following URLs, such as a documentation site or homepage. It is excluded because it needs manual review and risks path explosion.

The analysis reads source distributions (sdists) without running any install-time scripts. PyPI packages with no sdist were left out of the index.

Data:

• Malicious set: 64,239 packages from five datasets (Backstabber's Knife, MalOSS, Datadog, Malregistry, MalwareBench). Fuzzy matching on name and version leaves 47,066 unique packages.
• Benign index: 3,947,045 npm and 764,244 PyPI packages, indexed 15 to 19 March 2026.
• Benign sample: 16,569 packages per registry, giving a 99 percent confidence level with a 1 percent margin of error.
• Security holdings: 150,741 npm packages (3.8 percent) were replaced by placeholders and excluded from sampling.

Preconditions / Affected

The approach applies to npm and PyPI consumers who can build from a repository. The paper's motivation is install-time execution:

• npm: 85 percent of 8,830 malicious npm packages used an install lifecycle script, against under 2 percent of a random benign sample (the authors' internal research).
• PyPI: builds fall back to setup.py when no matching wheel exists. The paper cites Górny finding that 89 percent of popular setuptools-using packages still use setup.py.

What to do

The page gives no commands. The practical reading is that a source-attribution check can act as a pre-install gate:

1. Check for a direct or derived source.
2. Build from that source rather than pulling the registry artifact.

The paper reports this blocks 87.7 to 99.9 percent of malware, depending on how strictly the source is vetted. The text I had does not describe the vetting levels, so check the full paper for them.

Caveats

• Only 47.4 percent of benign packages attribute a source an end user could build from, so a strict gate would reject about half of legitimate packages.
• The paper's own comparison puts the alternatives short. Attestation proves provenance, not trustworthiness, and account takeovers can ship malware under a trusted signature. Reproducible builds are costly to adopt. Cooldowns lose value over time: about 75 percent of malicious packages are removed within 18 days (npm) and 7 days (PyPI), but about 18 percent survive beyond 31 days.
• The paper checks that a source is attributed. The text I had does not show whether it checks that the artifact matches that source.
• The comparison with security scanners (RQ3) and the threats-to-validity section were cut off in the text I had, so those results are not covered here.