Most teams review application code before it reaches production.
Fewer teams review the tools that help create that code.
That is the uncomfortable part of software supply chain security.
A developer extension can run on a machine.
A GitHub Action can run inside a workflow.
A Jenkins plugin can influence build behavior.
A container image can enter a deployment path.
A third-party developer tool can sit close to source code, credentials, environment variables, and build outputs.
That means the question is no longer only:
Is our code safe?
The better question is:
Which tools are allowed to touch the path from code to production?
That is the useful field note from the Checkmarx supply chain security incident update.
Checkmarx said the incident affected certain developer artifacts distributed through third-party channels, including VS Code extensions, GitHub Actions workflows, and a Jenkins plugin. The company also said it removed malicious artifacts, published clean replacements, rotated and revoked exposed credentials, and strengthened its GitHub and AWS environments after investigation with Mandiant.
This is not only a story about one company.
It is a reminder that developer tooling has become part of the product security surface.
Why developer tools deserve their own review
Developer tools are trusted by default because they help teams move faster.
That trust is practical.
Teams depend on extensions, actions, plugins, scanners, CLI tools, container images, package managers, CI runners, and automation scripts every day.
But convenience creates proximity.
A tool close to the development workflow may see or influence:
- source code,
- build scripts,
- environment variables,
- repository secrets,
- CI tokens,
- deployment paths,
- package publishing,
- artifact generation,
- container images,
- and local developer machines.
That does not mean every tool is unsafe.
It means tool trust should be reviewed, not assumed.
The hidden risk
A developer tool can create risk without looking like a normal application vulnerability.
It may not be part of your product codebase.
It may not be deployed to your production app.
It may not sit inside your cloud account.
But if it touches the build path, it can still matter.
For software teams, the important boundary is the delivery path:
Can this tool influence what reaches production, what credentials are used, or what artifacts are trusted?
If the answer is yes, it belongs in the security review.
The 7-check developer tool trust checklist
1. Tool inventory
Start by listing the tools that touch development and delivery.
That includes:
- IDE extensions,
- GitHub Actions,
- Jenkins plugins,
- CI/CD marketplace actions,
- Docker images,
- package managers,
- scanners,
- code assistants,
- local CLIs,
- deployment helpers,
- and internal scripts.
The goal is not to create bureaucracy.
The goal is to know what the team already trusts.
Readiness question:
Which external tools can run inside our development or build workflow?
2. Install source
The same tool can come from different places.
A VS Code extension from one marketplace may not be identical to a similar package from another marketplace. A GitHub Action pinned to a branch is not the same as one pinned to a commit. A Docker image tagged latest is not the same as a pinned digest.
Review:
- official marketplace source,
- publisher identity,
- download path,
- package signature where available,
- release history,
- and whether the source is maintained.
Readiness question:
Do we know where this tool came from and whether the source is trusted?
3. Version pinning
Floating versions are convenient.
They are also harder to reason about.
If a workflow uses a moving tag, branch, or loosely pinned package version, the team may receive changes without an explicit review.
Use stronger version control for tools that touch sensitive paths:
- pin GitHub Actions to commit SHA where needed,
- pin container images to digest,
- lock package versions,
- review plugin updates,
- and record why an update is accepted.
Readiness question:
Can this tool change under us without a review?
4. Permission scope
Developer tools should not receive broad access by default.
Review what each tool can access:
- repository contents,
- write permissions,
- workflow tokens,
- cloud credentials,
- package publishing rights,
- secrets,
- local file access,
- outbound network access,
- and deployment permissions.
A tool that only needs to scan code should not be able to publish artifacts.
A workflow step that only needs read access should not carry write permissions.
Readiness question:
Does this tool have only the access needed for its job?
5. Artifact verification
Teams often focus on source code and forget the artifact.
But customers and production systems do not run intentions. They run built artifacts.
Review:
- where artifacts are built,
- who can publish them,
- whether checksums or signatures are used,
- whether build provenance is available,
- whether releases are reproducible enough to trust,
- and whether suspicious artifacts can be pulled back quickly.
Readiness question:
Can we prove the artifact came from the expected build path?
6. Network behavior
A compromised developer tool may try to communicate externally.
That does not mean every network call is suspicious, but it should be explainable.
For sensitive tools, review:
- expected outbound domains,
- telemetry behavior,
- update endpoints,
- package download endpoints,
- webhook destinations,
- and whether the tool can reach unknown infrastructure.
This matters in CI/CD and local developer environments.
Readiness question:
Do we know where this tool sends data?
7. Removal path
A tool review is incomplete without an offboarding plan.
If a tool becomes risky, the team should know how to remove it fast.
That means:
- disabling the extension,
- removing the workflow action,
- replacing the plugin,
- rotating any exposed credentials,
- removing cached artifacts,
- checking affected builds,
- blocking known bad destinations,
- and communicating the internal action clearly.
Readiness question:
If this tool were compromised, how quickly could we remove it and verify the path is clean?
A practical 30-minute review
Use this quick review for any tool that touches development or delivery.
Step 1: What is the tool?
Name the tool, source, owner, and current version.
Step 2: Where does it run?
Developer machine, CI runner, build server, cloud workflow, package registry, or deployment path.
Step 3: What can it access?
Code, secrets, tokens, artifacts, production credentials, cloud resources, package publishing, or customer data.
Step 4: What can it change?
Files, workflow output, build artifacts, releases, deployment steps, or published packages.
Step 5: How is it updated?
Manual review, automatic update, marketplace update, branch reference, tag reference, or pinned digest.
Step 6: How do we remove it?
Disable, revoke, rotate, replace, block network path, audit builds, and notify teams.
What founders should take from this
A founder does not need to approve every developer plugin.
But they should know whether the company has a policy for tools that touch the path to production.
The practical questions are simple:
- Which tools can run in our build path?
- Which tools can access secrets?
- Which tools can publish or change artifacts?
- Which tools are pinned and reviewed?
- Which tools can be removed quickly if trust changes?
Software supply chain security is not only about open source libraries.
It is also about the trusted tools around the code.
The build path is part of the product.
If the build path is not reviewed, the product is carrying trust the business may not see.
Top comments (0)