Third-Party Integration Risk and the Application Graph

By Mikael Sundqvist, CTO & Co-Founder

Third-party integrations introduce a class of risk that standard dependency analysis is not designed to evaluate. An SCA scanner tells you which of your dependencies has known CVEs and which version fixes them. It does not tell you what the integration does with the data you send it, what access the integration callback has to your internal data structures, or what happens to your service graph's security properties when that external node is treated as trusted.

The reachability framing for third-party integration risk has two directions. The inbound direction: which paths from external attacker input can influence what your application sends to the third-party service, potentially causing the integration to act on attacker-controlled data? The outbound direction: if the third-party service is compromised or behaves maliciously, which parts of your application graph can it reach through the integration callbacks, webhooks, and data it returns to your services?

Third-party nodes in the application graph

When you call an external API, you are creating an edge in your application graph from your service node to an external node. The external node's internal behavior is a black box you cannot instrument or inspect. You can model the interface: what you send, what you receive, what callbacks the service may make back to your endpoints. But the trust assumptions built into that edge are security-relevant and frequently underspecified.

Consider an analytics integration that your application calls with event data. The call looks like a simple outbound HTTP request from your analytics service. But the data sent to the integration may include session identifiers, user identifiers, or behavioral data that, if the integration is compromised, could be used to enumerate or correlate user accounts. The integration node is outside your control; the data flowing into it is within your control, but only if someone has modeled which code paths produce that outbound call and what data they include.

Inbound callbacks are higher risk. An integration that makes webhook callbacks to your application is effectively an entry point into your service. A compromised webhook delivery mechanism, or a maliciously crafted webhook payload, is an attacker-controlled input arriving at a trusted-looking internal endpoint. The callback handler is an entry point from a source you may not be treating with the same scrutiny as your public API endpoints.

Dependency CVEs at the integration boundary

The standard SCA problem becomes more complex at integration boundaries. Your application imports a client library for a third-party service. The library has a known vulnerability in version X. SCA correctly flags this. The reachability question is: which of your handlers call through the client library to the vulnerable function?

Here the situation is identical to any other library vulnerability: you need the call graph from your entry points through your service logic to the client library's vulnerable function. What makes integration-specific vulnerability assessment harder is that the attack vector sometimes runs in reverse: a maliciously crafted response from the third-party service, processed by a vulnerable deserialization function in the client library, is an exploitation path that originates not from your entry points but from the integration's outbound response.

This is a different traversal direction than the standard inbound attack path. It requires modeling the data flow from third-party response objects through your client library and into your application code, looking for vulnerable parsing or deserialization functions that process external data arriving through the integration response channel.

Building the inter-service graph with external nodes

Most application graph models focus on the internal service topology: service A calls service B, service B queries database C. Third-party integrations are external nodes that should appear in the graph with typed edges indicating what data crosses the boundary and what trust level the integration node receives from your services.

The trust level question has practical consequences. An integration that receives an API key as a bearer token in outbound requests is a node that, if it becomes malicious, can make authenticated calls back to any endpoint that accepts that key. The key-bearing edge in the graph is a potential path from the external node back into your services. Including external nodes and their trust relationships in the application graph makes these paths visible for analysis.

This is not an argument for avoiding all third-party integrations. Most integrations are legitimate, useful, and lower-risk than building equivalent functionality internally. The argument is for modeling the integration boundary accurately: which data flows to which external node, which callbacks from that node are accepted and how they are authenticated, and which of your internal services' data stores are accessible to the integration through the permissions it holds.

Where third-party risk assessment should focus

Standard vendor security questionnaires ask about the third party's own security controls. Those are relevant for evaluating the third party as an organization, but they do not tell you about the architectural risk the integration introduces into your application graph. The questions that matter for your application's security posture are different.

Which of your entry points can be influenced to send attacker-controlled data to the integration? This identifies inbound attack paths that flow out through the integration boundary. Which callback or webhook endpoints in your application accept data from the integration? These are entry points that deserve the same scrutiny as any public API endpoint. What credentials does the integration hold that provide access to your internal resources? These define the blast radius of integration compromise. What sensitive data does the integration receive from your application over time? This defines the data exposure surface if the integration's storage is breached.

Answering these questions accurately requires the application graph to include the integration nodes and the data flows across the integration boundary. That is a more complete model than a dependency manifest lookup, and it produces a different and more actionable set of risk findings.

What this looks like in practice

Take a payment processing integration as a concrete example. Your checkout service calls the payment API to process transactions. The integration receives card data, transaction amounts, and customer identifiers. It makes webhook callbacks to your order management service to confirm completed transactions.

The graph model for this integration includes: the edge from checkout service to the payment processor node (outbound, carrying sensitive payment data), and the edge from the payment processor node to your order management service's webhook handler (inbound callback, carries transaction confirmation data). A reachability analysis of this graph asks: which paths from checkout service entry points can influence the data sent to the payment processor (relevant for data leakage risk), and which paths can an attacker create by controlling the webhook delivery (relevant for injection or replay attacks through the callback handler)?

These are not hypothetical questions. They are the concrete risk questions that determine whether your payment integration introduces exploitable paths into your application, and answering them requires the graph, not just the vendor security questionnaire.