Guide: using Semgrep to catch dependency confusion attacks

Hi everyone. I've been thinking a lot about supply chain security lately, especially as we integrate more third-party tools and libraries into our CI/CD pipelines. One vulnerability that keeps me up at night is dependency confusion—where a malicious package with a name identical to your internal, private package gets pulled from a public registry instead. It's a sneaky attack vector that can slip right into your builds.

I've found Semgrep to be surprisingly effective as a preventative guardrail here, not just for static code analysis. Its pattern-matching is great for writing custom rules that catch risky configurations before they merge. I wanted to share a thorough, step-by-step approach my team has implemented.

The core idea is to write Semgrep rules that scan your dependency manifest files (like `package.json`, `requirements.txt`, `pyproject.toml`, or `pom.xml`) for packages that *should* be sourced from your private registry. Here’s the general strategy we follow:

* **First, identify your private package names.** List all your internal library namespaces or naming conventions (e.g., `@mycompany/`, `mycompany-` prefixes, or specific internal package names like `internal-auth-lib`).
* **Write a Semgrep rule to flag any of these names *without* your private registry source.** For example, in a `package.json`, you want to ensure dependencies with your prefix specify your private registry URL. The rule looks for the package name pattern and then checks that the `resolutions` field or a `.npmrc` configuration isn't missing or pointing to the public registry.
* **Extend this to CI configuration files.** Scan your `.gitlab-ci.yml`, GitHub Actions workflows, or Jenkinsfiles to ensure the private registry is being authenticated and used in the dependency installation steps. A rule can catch if the `npm install` or `pip install` step is running without the proper `--registry` flag or configured credentials.
* **Run these rules in PRs.** Integrate Semgrep into your pull request process. This creates a mandatory check, so developers get immediate feedback if they've accidentally omitted the private source for an internal dependency.

The beauty is that these rules are declarative and live with your code. They become part of your team's knowledge base for secure configuration. It's not a silver bullet—you still need proper registry configuration and scoping—but it adds a critical layer of defense that's automated and consistent.

Has anyone else tried a similar approach? I'm particularly curious if you've crafted rules for other file types like Dockerfiles or internal Go modules. Let's compare notes and tighten our defenses together.

~Jane