One word, two risks
Search for dependency monitoring and nearly everything you find, Dependabot, Renovate, Snyk, OWASP Dependency-Track, is about one risk: the code you install. Those tools scan manifests and lockfiles for outdated packages, known CVEs, and license problems. It is mature, essential tooling, and it shares a name with a risk it does not cover at all: the services you call.
Your product's real dependency surface is both. The npm package is a dependency; so is the payments API it talks to, the model endpoint your agent calls, the auth provider your login rides on. The package can be pinned, scanned, and reproducible while the service behind it changes shape on a Tuesday without a version bump, a release note, or a CVE. Pinning a version pins your code; nothing pins the provider.
The two disciplines, side by side
- Watches: SCA watches manifests, lockfiles, and registries. Dependency intelligence watches live API behavior, the structure of real responses over time.
- Failure caught: SCA catches a vulnerable or outdated component before or at build. Dependency intelligence catches a contract change, a field removed, retyped, or restructured, before or as it reaches production behavior.
- Trigger: SCA fires on a release or advisory, artifacts the ecosystem publishes. Dependency intelligence fires on observed structural displacement, because for unannounced changes there is no artifact to fire on.
- Blind spot: SCA cannot see runtime service behavior. Dependency intelligence does not inventory your packages. Neither substitutes for the other.
Why the second discipline barely exists yet
The package side had raw material to build on: registries, semver, advisories, SBOM standards. The service side has none of that; there is no registry of API behavior and no advisory feed for undocumented changes. The observable truth lives only in traffic, so the discipline had to wait for a way to watch traffic without becoming a data-custody problem: reduce responses to structure at the edge, keep field names and types, discard every value permanently. That constraint, values never persist, is what makes runtime contract observation buildable and buyable; anything looser is a liability trade rather than a monitoring product.
What good coverage looks like
- Keep SCA. Dependabot or Renovate plus advisory scanning is non-negotiable baseline hygiene for code you ship.
- Add contract observation for the services that can hurt you. Payments, AI, auth, messaging, data feeds: profile the real responses, baseline structure, alert on sustained displacement with evidence. The approaches are compared honestly in API drift monitoring: an honest guide.
- Prefer network over solitude where it exists. A change to a shared provider hits many teams; a neutral cross-company watch turns the first encounter into everyone's warning. That is the dependency-intelligence layer ShiftGraph builds, seeded publicly at the Observatory.
Common questions
- Does Dependabot detect API drift?
- No, and it is not trying to. Dependabot, Renovate, and SCA platforms watch the packages declared in your manifests: new versions, known vulnerabilities, license changes. A provider changing a live API response shape involves no package release, so nothing in that toolchain fires. Both layers matter; they watch different things.
- Is dependency intelligence just APM with another name?
- No. APM watches your services: latency, errors, traces through code you deploy. Dependency intelligence watches the contracts of services you do not deploy and cannot instrument, the third-party APIs your code calls, for structural change. APM tells you your checkout slowed down; dependency intelligence tells you the payment API's response shape moved on Tuesday.
- We already get a software bill of materials. Does that cover this?
- An SBOM inventories the components inside your artifact at build time. It is the right answer to supply-chain questions about code you ship. It says nothing about the behavior of remote services at runtime, which is where API drift lives.