A bare import launched the hidden Go binary in compromised MemTensor packages, Socket says

A functional test asks whether a package returns the right result. A supply-chain gate has to ask first what the package did before the test called any feature, jfisher4002 argues in a dev.to post ^[4]. In the post's plain-English summary of the memos case, loading the library was itself the execution trigger, and the application never had to call a risky feature ^[3]. "If your test begins after import, you may already be late," the author wrote ^[19].

Socket counted three malicious npm releases and one on PyPI, each carrying cross-platform Go binaries named sckit ^[5][6]. A package whose job includes memory recall has no evident use for a background executable with that name ^[2]. Because Socket worked from static analysis ^[8], the import trigger is a finding about what the code would do. A traced cold import, the core of the proposed gate, would record what it actually does ^[11].

The author keeps the release decision apart from the forensic question. Prompt text reaching the hidden process establishes an unauthorized data path, but it does not prove every prompt was exfiltrated ^[9]. I think that split is right for a gate, because it rests on behavior the gate can observe. "A package that silently starts an undeclared executable during import should fail before anyone argues about the payload's final success," the author wrote ^[10].

Gate 1 in the post runs in this order:

1. Isolate. Skip the developer laptop and the normal CI runner. Use a disposable environment with no real credentials, no repository write token and no package-publishing token ^[12]. 2. Fetch the exact registry artifact, not just the repository tag, with `pip download --no-deps --only-binary=:all:` for wheels and `npm pack --ignore-scripts` for the plugin ^[13]. 3. Record the registry URL, version, digest, download time and the source commit the release claims to represent ^[14]. 4. Diff against the last approved release, looking for new native binaries, executable-permission changes, new build backends and abrupt growth in unpacked size ^[16].

The diff script is plain, and it only reads bytes from the archive ^[17]. For a zip archive such as a wheel, it reads each member and hashes it with SHA-256. A member counts as native when its first bytes match the ELF header, the MZ header or one of six Mach-O magic values. The executable flag comes from the mode bits in the zip's external attributes ^[17]. Its two-times size-growth threshold is an example, and the author says to set it from the package's own release history ^[18].

The magic-byte test looks only at the raw start of each file. A binary shipped compressed, or encoded inside a Python source file, would not match ^[2]. I'd treat the diff as a cheap first filter and the cold-import trace as the gate itself. Provenance has its own condition. It helps only when the consumer checks it against an expected source and builder, and a badge does not replace that comparison ^[15].