The Scenario Nobody Talks About
It is 2:00 AM. Your on-call engineer gets paged. The checkout flow is returning 500 errors. Revenue is bleeding at $12,000 per hour. The team scrambles. They check the deployment log: nothing was deployed in the last 24 hours. They check the dependency dashboard: no new CVEs, no package updates. The SBOM is clean. Every compliance check is green.
Forty-five minutes later, someone finds it. The internal Payments API, maintained by a different team, shipped a breaking change three hours ago. They renamed a required response field from card_token to payment_method_id. Their tests passed. Their SBOM was valid. Their deployment was clean. But your service, which consumes that API, is now parsing a response that no longer contains the field it expects.
Your SBOM told you everything was fine. It was wrong.
What SBOMs Actually Track
Software Bills of Materials have become a cornerstone of modern supply chain security, and for good reason. Following the 2021 Executive Order on Improving the Nation's Cybersecurity, SBOMs are now required for software sold to the U.S. federal government. Tools like Syft, Trivy, and CycloneDX have made SBOM generation nearly effortless. Platforms like Sonatype Nexus, JFrog Xray, and Snyk continuously monitor your dependency tree for known vulnerabilities.
An SBOM answers a critical question: what software components is my application built from? It catalogs every library, framework, and transitive dependency, along with their versions, licenses, and known CVEs. This is essential for vulnerability management, license compliance, and incident response.
But there is a question SBOMs do not answer, and it is equally critical: are the APIs my application depends on still compatible with my code?
The SBOM Blind Spot
Consider a typical microservices architecture. Your Order Service depends on three internal APIs: Payments, Inventory, and Notifications. Your SBOM faithfully records that you depend on payments-sdk@2.3.0, inventory-client@1.7.2, and notifications-lib@3.1.0. If any of those packages has a known vulnerability, your SBOM tooling will flag it immediately.
But what happens when the Payments team ships a new version of their API that removes a required field, changes a response type from integer to string, or restructures a nested object? Your SBOM does not change. Your dependency versions have not changed. No CVE has been published. From the perspective of every supply chain security tool in your pipeline, nothing happened.
Yet your application is broken.
This blind spot exists because SBOMs were designed to track code dependencies, not runtime contracts. An API contract is a fundamentally different kind of dependency. It is not a package you install. It is a promise that another service makes about the shape, types, and behavior of its responses. When that promise is broken, no amount of dependency scanning will catch it.
| Dimension | SBOM Coverage | API Contract Coverage |
|---|---|---|
| Library vulnerabilities (CVEs) | Yes | No |
| License compliance | Yes | No |
| Transitive dependency tracking | Yes | No |
| Breaking field removals | No | Yes |
| Response type changes | No | Yes |
| Endpoint deprecation | No | Yes |
| Authentication scheme changes | No | Yes |
API Contracts Are Supply Chain Artifacts
The software supply chain is typically understood as a chain of code artifacts: source code, compiled binaries, container images, and the libraries they depend on. But in a service-oriented architecture, the chain extends beyond code. Every API your service calls is a link in your supply chain. Every OpenAPI specification, every GraphQL schema, every gRPC protobuf definition is a supply chain artifact that your application depends on at runtime.
The OWASP CI/CD Security Cheat Sheet identifies "insufficient artifact integrity validation" as a top risk in modern CI/CD pipelines. While this guidance typically refers to code artifacts, the principle applies equally to API contracts. If you are not validating that the APIs you depend on have not changed in incompatible ways, you have an integrity gap in your pipeline.
Think about it this way: if a malicious actor compromised an npm package you depend on, your SBOM tooling would catch it. But if a well-meaning colleague on another team accidentally removes a required field from an internal API, nothing catches it. The impact can be identical: a production outage that costs your organization tens of thousands of dollars. The only difference is intent, and your users do not care about intent when the checkout page is broken.
Why This Is Getting Worse
Three trends are making the API contract blind spot more dangerous:
- Microservices proliferation. The average enterprise now operates hundreds of internal APIs. Each one is a potential source of breaking changes. The blast radius of a single field rename grows exponentially with the number of consumers.
- API-first development. As organizations adopt API-first practices, the API specification becomes the primary interface between teams. But most teams treat their OpenAPI spec as documentation, not as a versioned, validated contract with downstream consumers.
- AI-generated code. Large language models are increasingly used to generate API clients, SDK wrappers, and integration code. These generated artifacts are tightly coupled to the API schema at generation time. A breaking change in the upstream API silently invalidates the generated code, and no SBOM tool will flag it.
The Missing Link: Contract Validation in CI/CD
Closing the SBOM blind spot requires adding a new layer to your CI/CD pipeline: API contract validation. Just as you scan dependencies for vulnerabilities on every build, you should validate API contracts for breaking changes on every pull request.
This means treating your OpenAPI specification (or GraphQL schema, or protobuf definition) as a first-class artifact in your supply chain. Every change to the spec should be diffed against the previous version. Breaking changes should be flagged, scored for risk, and routed through an approval process before they reach production.
The validation layer should answer three questions on every PR that modifies an API schema:
- What changed? A precise diff of the API contract, showing added, removed, and modified fields, endpoints, and types.
- Is it breaking? Automated classification of each change as breaking or non-breaking, with confidence scoring for ambiguous cases.
- What is the blast radius? An estimate of how many downstream consumers will be affected, based on known API dependencies and consumer mappings.
Building a Complete Supply Chain Picture
The goal is not to replace SBOMs. SBOMs are essential and will remain so. The goal is to complement them with a parallel layer that covers the contract dimension of your supply chain. Together, these two layers create a complete integrity picture:
- SBOM layer: "What code components am I using, and are any of them vulnerable?"
- Contract layer: "What API contracts am I depending on, and are any of them broken?"
Organizations that implement both layers can answer a question that neither layer can answer alone: is my application safe to deploy? Not just "are my dependencies free of known CVEs," but "will my application actually work when it reaches production, given the current state of every API it depends on?"
How CodeRifts Fills the Gap
CodeRifts is an API governance engine that adds the contract validation layer to your CI/CD pipeline. It installs as a GitHub App and runs automatically on every pull request that modifies an OpenAPI or GraphQL schema. Here is what it provides:
- Automated schema diffing. Every PR gets a detailed breakdown of what changed in the API contract: added endpoints, removed fields, type changes, and more.
- Breaking change detection with risk scoring. Each breaking change is scored on a 0-100 scale based on severity, blast radius, and domain criticality. A removed optional field in a low-traffic endpoint scores differently than a removed required field in the payments API.
- Policy enforcement. Define governance rules like "no required field removals without a 30-day deprecation period" or "authentication changes require security team approval." CodeRifts enforces these policies automatically.
- Economic impact estimation. Breaking changes are not just technical risks; they are financial risks. CodeRifts estimates the cost of each breaking change based on engineering hours, testing overhead, and downstream consumer count.
- Deprecation lifecycle management. Track deprecated fields and endpoints through their full lifecycle, from initial deprecation to final removal, with automated reminders and policy checks.
Combined with your existing SBOM tooling, CodeRifts creates the complete supply chain integrity picture that modern organizations need. Your SBOM tools watch for vulnerable dependencies. CodeRifts watches for broken contracts. Together, they ensure that your application is both secure and functional before it reaches production.
For teams already using Spectral for API linting, CodeRifts adds the runtime governance layer that design-time linting cannot provide. Spectral validates that your spec follows style rules. CodeRifts validates that your spec changes do not break consumers. Both are valuable; together, they are comprehensive.
CodeRifts is free during beta. Every Pro and Team feature is available at no cost. Install on GitHub and start catching breaking API changes before they reach production. See a live demo PR to see it in action. Or explore pricing for when the beta ends.