Yes. A test runner such as Jest executes your code, and it also loads transformers, setup modules and test environments from packages you install. Those modules run in the same Node.js process as your tests, on the same CI job, with whatever environment variables and tokens that job holds.
What a test runner actually loads
Jest's documentation says it runs the code in your project as JavaScript and passes files through code transformation on demand, whenever a require or import is evaluated. A transformer is a module that provides a method for transforming source files. Jest ships with one by default, babel-jest, which loads your project's Babel configuration and transforms matching files.
That means a test run is a chain of third party code, each link resolved from node_modules:
| Config option | What it points at | When it runs |
|---|---|---|
| transform | A transformer module | Every time a matching file is loaded |
| setupFiles | Modules to run before tests | Before each test file |
| globalSetup | A module exporting a function | Once, before all test files |
| testEnvironment | An environment such as node, jsdom or a custom string | Around each test file |
| snapshotSerializers | Serializer modules | When snapshots are written or compared |
The Jest configuration page describes globalSetup as a module that must export a function triggered once before all test files. It is ordinary code with ordinary Node access.
Why that matters for secrets
Test jobs often get more than they need. A pipeline that runs install, build, test and deploy in one job tends to expose a registry token, a cloud credential or a deploy key to every step. If a transformer, a custom environment or one of their dependencies is replaced by a malicious version, it can read those variables while your tests are green.
Jest also notes that test files run inside a vm. That is an implementation detail of how it runs tests, and nothing in the documentation presents it as a security boundary for untrusted packages. Do not treat it as one.
Steps to reduce the exposure
- List every module your test config references. Open your Jest configuration file and write down each transform, setup file, environment and reporter.
- Check where each one comes from: your repo, an official package, or a community package. Community packages deserve the checks in how to check an npm package before you install it.
- Run tests in a job that has no deploy or publish credentials. Pass only what the tests need, such as a read only token for a fixture service.
- Install with a committed lockfile using npm ci so the test toolchain does not drift between runs.
- Keep install scripts off where you can. See how to disable install scripts and what breaks when you do.
- Limit the job token. The pattern in GitHub Actions token permissions applies to test jobs too.
What about local runs
Developers run the same config on laptops, where the exposed material is SSH keys, cloud profiles and browser sessions. A pull request that changes the test config or adds a transformer deserves the same review as a change to production code, because it executes on every machine that runs the suite.
Where Safeguard fits
Safeguard's SBOM and dependency scanning cover test tooling like any other package, and its policies and gates can hold a pull request that adds a risky dependency. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how dev tooling shows up in the same inventory as runtime packages.
Quick check
Is a devDependency safe because it never ships to users?
No. It does not ship, but it runs on build and test machines, which often hold more secrets than a browser ever sees.
Does the Jest vm sandbox contain a malicious package?
Do not rely on it. The documentation describes it as how test files run, not as a security control. Limit what the job can reach instead.
Sources
Last reviewed: 19 October 2026.
