API supply chain security and SBOMs

Why SBOMs matter

A software bill of materials records components included in a build. It helps a team identify affected services when a dependency vulnerability is disclosed. An OpenAPI document describes an HTTP interface; it is not itself a complete inventory of libraries, transitive packages, or container layers. Generate the SBOM from the service build and link it to the deployed artifact and owner.

Building an API-aware SBOM

• Generate an SBOM from the built service and its dependencies, not from the OpenAPI document alone.
• Include hashes, licenses, and component versions; avoid floating versions in SDK dependencies.
• Share an SBOM with authorised consumers when your disclosure policy calls for it; do not publish internal dependency details automatically.

Generate an SBOM from the service build and use dependency scanning to flag outdated libraries. APISAST's API SAST checks cover OpenAPI design, not software dependencies.

Connect the SBOM to a deployed service

Create the SBOM in the build pipeline for the exact image or package that will be released. Record its version, build identifier, and owner so an alert can be mapped to the running API. An SBOM generated from a developer's checkout may differ from the deployed artifact when the build adds system packages or resolves newer transitive dependencies. Keep the generated file alongside release evidence and regenerate it on every build rather than editing it by hand.

Include direct and transitive components where the build tooling can identify them. Review missing versions, ambiguous names, and components from private registries. A dependency scanner needs accurate identifiers to match advisories. A hash can help tie a component to a particular artifact, but a hash does not establish that the component is safe. Keep access to internal SBOMs appropriate for their sensitivity.

Track upstream API dependencies separately

A service may call payment, identity, or messaging APIs that are not libraries inside its build. Keep an inventory of these providers, the endpoints used, the credentials involved, and the team responsible for each integration. An OpenAPI document may describe callbacks or external links, but it is rarely a complete dependency inventory. Review the provider's contract, outage procedures, and data handling separately from package vulnerability scanning.

When an upstream API changes, run contract and integration tests against the behaviour your service depends on. A dependency alert about a library calls for a package update; an upstream response change calls for a compatibility fix. Distinguishing these two failure modes keeps incident response focused. The OpenAPI versioning guide covers how to communicate interface changes to your own consumers.

Prioritise a vulnerability response

An advisory match is the start of triage. Confirm whether the affected component and version are in the deployed artifact, whether the vulnerable code path is reachable, and whether a fixed version is available. Record the decision and its evidence. Patch and redeploy when possible; when a fix must wait, document an owner, temporary mitigation, and review date. Do not treat a low dashboard score as proof that an API is protected.

After the rebuild, compare the new SBOM with the previous one and verify the affected version is gone. Run the API's functional and contract tests so a dependency update does not silently change serialization or authentication behaviour. If a public security notice is needed, describe the impacted versions and remediation without exposing credentials or unnecessary internal architecture.

Continuous monitoring

Subscribe to vulnerability advisories and open an issue when a deployed component is affected. Rebuild and regenerate the SBOM after a dependency change. Run contract tests against upstream API behaviour and use SAST testing for APIs to review OpenAPI design changes; neither check identifies vulnerable package versions.

Set a review cadence for packages with no maintainer, unknown version, or an unavailable fix. Ask whether the service actually loads the component and which endpoints depend on it. Document temporary mitigations and an owner when an update must wait. After remediation, confirm that the new deployed artifact contains the fixed version rather than trusting a pull request merge alone. Keep package scanning, contract scanning, and live API tests as separate evidence streams: each answers a different question about supply-chain and interface risk.

Recheck the inventory after removing a service or changing a build pipeline, because an obsolete SBOM can make incident triage slower than having a clearly marked gap.