Where Platform Engineering and AppSec Responsibilities Actually Overlap

By Adrian De Gendt, CEO & Co-Founder

The org chart says AppSec owns vulnerability management and platform engineering owns the runtime. In practice, the security properties of a microservice application emerge from the combination of both, and gaps persist most reliably at the seam between the two teams. Not because either team is negligent, but because the artifacts that matter for security, actual deployment topology, runtime call patterns, service mesh policies, secrets provisioning, live simultaneously in both teams' domains and neither team has a complete picture alone.

This is worth being specific about because "collaborate more" is easy advice that doesn't tell you where the handoffs actually break. The breakdown points are predictable and they cluster around a specific category of question: what does the running application actually look like, and which of its exposed paths reach sensitive data?

What each team typically knows and does not know

AppSec teams are expert in the vulnerability lifecycle: what the CVE means technically, which CWE it falls under, what a working exploit looks like, what remediation is required at the code level. They are oriented toward the static properties of code and the theoretical risk of vulnerability classes. What they frequently do not have direct access to is the runtime topology: which service is currently deployed where, which ingress rules are active, which endpoints are actually receiving external traffic versus internal traffic only, and how the deployment configuration has drifted from the code repository.

Platform engineering teams are expert in the operational properties of the service landscape: how services are deployed, what their network policies look like, what their resource constraints are, how the CI/CD pipeline produces the deployment artifacts, and how service identities work in the mesh. They are oriented toward the operational properties of the system. What they frequently do not have direct context for is the vulnerability risk represented by the code running inside those services: which CVEs affect which versions, which code paths are flagged by security tools, and what the threat model for the application looks like.

The overlap zone is the space where both kinds of knowledge are needed simultaneously: reachability analysis, incident triage, and security architecture decisions about the deployment.

Where reachability analysis lands in the overlap

A reachability determination for a specific vulnerability requires knowing two things: whether the vulnerable code is in a path reachable from an entry point (AppSec's domain, rooted in static analysis), and whether that entry point is actually exposed to relevant traffic in the running deployment (platform engineering's domain, rooted in operational configuration). Neither team can answer the reachability question correctly without the other's data.

The practical consequence is that vulnerability triage decisions that look like AppSec decisions are actually joint decisions. A finding classified as low priority because "the vulnerable handler requires authentication" is correct only if the authentication policy is implemented at the network or middleware layer and is actually enforced in the current deployment. An AppSec team that classifies based on code inspection and a platform team that hasn't communicated a network policy change are operating from different models of the same application.

We have seen this failure mode concretely. An authentication middleware is present in the code, the AppSec team classifies findings behind it as lower priority, but a configuration flag in the deployment environment disables the middleware for a specific environment that receives external traffic. The code says one thing; the deployed reality says another. Neither team caught the discrepancy because each was looking at their own domain.

The service catalog as shared ground truth

One structural response to this is the internal developer platform's service catalog. When platform teams maintain a service catalog that describes, for each service, its deployment topology, its network exposure, its service mesh policies, and its dependencies, that catalog becomes a shared data source that AppSec can consume when evaluating reachability. Rather than requiring an AppSec engineer to query the platform team every time they want to understand the deployment context for a finding, the catalog surfaces that context as a queryable data source.

This is the integration pattern that makes the most practical sense: platform engineering maintains the authoritative operational model of the deployment, AppSec maintains the authoritative model of vulnerability risk in the code, and the reachability analysis layer consumes both to produce prioritized findings that reflect actual deployed risk rather than theoretical code risk.

Incident response as the clearest overlap case

Security incident response is where the team boundary breaks down most visibly. When an alert fires on anomalous behavior from a service, the questions that need answering immediately are: what does the service call, what data can it reach, what credentials does it hold, and what other services can be reached from the compromised service? Those questions span the platform engineering model (what does the service call, what does the mesh topology look like) and the AppSec model (what does the code do with the access it has, what vulnerabilities are present that an attacker might be exploiting).

Teams that have pre-built a shared model of the application graph, combining service topology with code-level call graphs and vulnerability data, can answer those questions in minutes rather than hours. Teams that are assembling that model from scratch during an active incident are at a significant disadvantage.

Shared tooling as the practical answer

The organizational argument for shared tooling is not that AppSec and platform engineering should merge. Their expertise domains are genuinely distinct and both are necessary. The argument is that the security analysis layer, specifically the layer that evaluates exposure paths through the combined code-plus-deployment model, needs to be a shared resource that both teams contribute data to and consume findings from.

When AppSec owns a vulnerability triage queue that has no deployment context, and platform engineering owns a deployment model with no vulnerability context, the overlap zone remains dark. Connecting those two models is where the highest-value security work in a microservice organization currently lives, and it requires both teams to be stakeholders in the same tool rather than consumers of separate tools that don't communicate.