Supply chain - install-time credential access and workflow planting

supply-chain-install-credential-access is a critical severity check in the tooling category, written in shell. Its source is templates/tooling/supply-chain/supply-chain-install-credential-access.sh in cert-x-gen-templates.

What it checks

Installs a package with a real package manager inside a hermetic lab whose sentinel HOME has been seeded with per-file CANARY credentials - ~/.npmrc, ~/.aws/credentials, ~/.config/gh/hosts.yml - and canary credential environment variables, then answers the two questions the Shai-Hulud / CHAINDROP worm mechanic turns on: WHICH secret did the install step read, and did it plant a GitHub Actions workflow. Reads are witnessed by access time against a liveness-tested oracle, workflow planting by a path appearing under .github/workflows outside any install prefix, and exfiltration by a canary value arriving at the lab’s loopback sink. Every observation is differential against the same package manager installing a synthesised inert package, so npm reading its own ~/.npmrc can never be the finding. Behavioural, not signature-based: it never looks at the hook’s source.

There is a playbook for this check

Install-time credential access and workflow planting sets out the use case, the probe flow, the oracle, and the fixture that proves it in both directions.

Header

Field	Value
Id	supply-chain-install-credential-access
Severity	critical
Language	shell
Category	tooling
Author	CERT-X-GEN / Bugb Technologies
Template version	not recorded
Confidence	95
CVSS	not recorded
Weakness	CWE-522
Tags	supply-chain, tooling, npm, pypi, install-hook, postinstall, credential-theft, worm, shai-hulud, github-actions, behavioural
Target kind	cli
Oracle	property, diff, detector

Conventions of the repository, not fields the engine reads

@target_kinds and @oracles are documented in the templates repository’s contribution guide, and cxg’s annotation parser does not carry them into a template’s metadata. Nothing at scan time selects on them. The annotation header schema is every field the parser does read.

References

Declared in the header. cxg parses @references and then discards it, and nothing at scan time reads it, so this is the only place the links a template cites are surfaced.

• https://unit42.paloaltonetworks.com/npm-supply-chain-attack/

Run it

To see what the copy on your machine says about itself, and to confirm it is installed at all:

cxg template info supply-chain-install-credential-access

The id it prints is the one to pass anywhere a template is selected. See cxg template for the rest of the subcommand, Scan a target for running a scan, and A match is not a finding for how to read what comes back.

Related

• Template catalog is the whole corpus.
• tooling is the rest of this category.
• Templates by weakness class groups checks by the defect they look for.
• Contribute a template is the route from a check you needed and could not find to a merged one.