Skip to main content

Supply-chain tamper detection

A managed package or a deployment bundle can be tampered with after review and before install: a benign-looking static resource can be padded with a hidden payload, or a package's declared apiVersion can be quietly lowered to slip under a newer security default. These findings look for the tell-tale shapes of that kind of tampering in the artifact you are about to trust.

The goal is integrity at the install boundary. A package that passed review should be the package that lands in the org, and these detectors flag the discrepancies that suggest it is not.

SF-TAMPER-001: oversized static resource or base64-blob Apex​

Triggers when a static resource is unexpectedly large for its declared purpose, or when an Apex class embeds a large base64-encoded blob as a string literal.

Why it matters: an oversized static resource or a base64 blob hidden in Apex is a classic carrier for smuggled payload: code or data that was not part of what a reviewer read but rides along inside an otherwise normal component. A reviewer reading the Apex source would never see the decoded content of an embedded blob.

How to fix: open the flagged resource or decode the embedded blob and confirm its contents are exactly what the component is supposed to carry. If the payload is unexplained, treat the package as untrusted and do not install it. Where a large asset is legitimate, move it to a clearly named resource so its size is expected rather than surprising.

SF-TAMPER-002: apiVersion downgrade vs the package modal​

Triggers when a component's declared apiVersion is lower than the version shown in the package install modal (the version the package advertises at install time), indicating the deployed component runs under an older API contract than the package presents.

Why it matters: an apiVersion downgrade silently opts a component out of the platform security defaults that the advertised, higher API version would enforce. The package looks current in the modal while a component inside it runs under weaker, older behavior, which is exactly what a tamperer would do to re-enable a removed default.

How to fix: compare each component's apiVersion against the version the package modal advertises and reconcile the discrepancy. Raise the downgraded component to the advertised version, or reject the package if the downgrade is unexplained.

npm install-time lifecycle script​

A Salesforce DX project is also a Node project: it ships a package.json for its LWC tooling. If that package.json declares a preinstall, install, or postinstall lifecycle script, npm runs that command automatically on every npm install - before a single line of application code runs. The npm-install-lifecycle-script signal (CWE-1357) flags this install-time code-execution surface: a compromised or typo-squatted dependency, or a malicious commit to the package itself, executes attacker code on any developer or CI machine that installs it.

Why it matters: install-time hooks are the most direct supply-chain foothold in the npm ecosystem - they run with the developer's full privileges and are invisible in normal code review. The detector reports the hook name and the command; an empty or absent hook does not fire.

How to fix: remove the install-time hook if it is not essential. If a build step is genuinely required, move it to an explicit script the developer runs by name (a build script in CI) rather than an install hook, and install dependencies with npm ci --ignore-scripts in untrusted contexts.