List every tool that runs during your build, then answer four questions for each: where does it come from, what runs when it installs, what can it reach while it runs, and who approves a change. One focused hour is enough to find the biggest gaps in a typical front-end repository.
Why the toolchain deserves its own audit
Your shipped code is produced by a chain of packages: bundler, loaders, transpiler, minifier, CSS tooling, linter, test runner, end to end tester and git hooks. Each executes as Node.js on a developer laptop or a CI runner, usually with network access and often with tokens. Reviews of runtime dependencies rarely cover them. The related posts below go deeper on each piece.
Minutes 0 to 10: build the list
Open package.json in every workspace package and the config files for each tool. Write down every tool, plugin and preset. Include things loaded by name from config, such as Babel plugins, Jest transformers and ESLint plugins, because they do not always appear as direct imports in code. A table helps:
| Tool type | Where it is configured | Example question |
|---|---|---|
| Bundler | webpack, Vite or similar config | Which loaders and plugins load? |
| Transpiler | Babel config or framework default | Which plugins and presets apply? |
| Linter | ESLint config | Which plugins and shared configs run? |
| Test runner | Jest or similar config | Which transformers and setup files? |
| Browser test tool | Cypress or Playwright config | Where do binaries download from? |
| Git hooks | Husky or similar | Does it install in CI? |
| CI | Workflow files | Which third party actions run? |
Minutes 10 to 25: find install time and run time code
- Search the lockfile and node_modules for packages with install scripts or a binding.gyp file. See why npm runs node-gyp when a package has a binding.gyp.
- Read your own scripts for prebuild, postbuild, pretest and similar. See npm run build also runs prebuild and postbuild.
- Note downloaded binaries that are not in the lockfile, as in Cypress and Playwright binaries.
- Check hooks run only where needed, see Husky in CI and Docker.
Minutes 25 to 40: limit what the tools can reach
- Look at which secrets the build job holds. Move deploy and publish credentials to a separate job, as in split front-end build and deploy.
- Cut the GITHUB_TOKEN to read only for build jobs. See GitHub Actions token permissions.
- Check that CI installs with npm ci from a committed lockfile.
- Check the final Docker image does not include build tools, per do build tools end up in your production image.
Minutes 40 to 55: check versions and age
- Run a dependency scan across the whole tree, including dev tools. Read the findings for the bundler, transpiler and test runner first.
- Check for deprecated tools, such as old compilers. See Node Sass is deprecated.
- Check dev servers are on patched versions, see can a malicious website steal source code from your dev server.
- Decide your pinning rule, see pin build tools to exact versions or ranges.
Minutes 55 to 60: set the rule
Write one paragraph in your contributing guide: new build tools, plugins and presets need a reviewer, a stated reason and a look at their install scripts and dependencies. Add a pull request check that flags changes to the lockfile, and review those diffs with the steps in how to review a lockfile diff after upgrading a build tool.
What to expect
Most teams find a few forgotten plugins, one job with more secrets than it needs, and at least one tool that has not had an update in a long time. Fixing those three removes most of the practical risk. The list also becomes a baseline, so the next audit only needs to look at what changed.
Safeguard's SBOM and dependency scanning cover build tooling in the same inventory as runtime packages, and its policies and gates can enforce your review rule at the pull request. 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 findings are prioritised after a scan.
Quick check
Should dev tools be audited as carefully as runtime packages?
They need a different lens. They may not ship, but they run on machines that hold credentials.
How often should I repeat this audit?
Run the full hour yearly and a short version, new tools and lockfile changes only, whenever the toolchain changes.
Last reviewed: 19 October 2026.
