Microservices security assessment: the lateral movement paths your scanner will never find
Julian ThorneApril 29, 2026
Key takeaways
68% of organizations with API gateways had services directly reachable on the internal network, bypassing gateway authentication entirely — Vulnox assessment data, 84 engagements, 2022–2024.
Inter-service lateral movement is the unnamed problem in microservices security assessment: scanners test services in isolation, but attackers move between them. The exploit chain lives in the gap between what tools see and how services actually communicate.
54% of assessed microservices environments used hardcoded credentials or environment variables for secrets — the most common single-point failure that converts a compromised sidecar into full platform access.
Organizations with dedicated security teams were more likely to have overly permissive service mesh configurations than those without — because mesh complexity gets resolved in favor of availability, and fine-tuning gets deferred indefinitely.
71% of assessed environments lacked distributed tracing that correlated events across services — which means lateral movement goes undetected not because monitoring failed, but because monitoring was never designed to see cross-service attacker behavior.
A microservices security assessment that does not include authenticated lateral movement simulation — not just port scanning, but actual service-to-service exploit chain testing — is measuring the wrong threat model.
TL;DR
Microservices security assessments mostly test what scanners can see: exposed ports, known CVEs, TLS configuration, container image vulnerabilities. What they do not test is how an attacker moves between services after compromising one. That is the actual threat model in a microservices environment. The entry point is almost never the critical service — it is the metrics endpoint, the sidecar, the logging agent. The damage happens in the lateral movement that follows. Vulnox found that 68% of organizations with gateway security had no meaningful controls on internal service-to-service traffic. The perimeter was protected. The interior was flat.
It started with a metrics endpoint that nobody thought was worth protecting
A 60-person SaaS company — B2B platform, financial data, SOC 2 Type II certified — ran a Prometheus metrics endpoint on port 9090 with no authentication. The endpoint was internal-only by intent. It was reachable from every service in the cluster by configuration. An attacker who gained initial access through a dependency vulnerability in one microservice spent three days reading metrics that exposed service names, internal hostnames, database connection counts, and error rates that revealed which services were handling authentication tokens. None of that data was classified. All of it was a reconnaissance map.
By day four, the attacker had used the metrics data to identify the token-issuing service, found it reachable directly on the internal network without the API gateway in the path, and replayed a captured token to authenticate as an admin user. The entry point was a metrics endpoint with a CVSSv3 score of 5.3. The eventual access was full administrative control of the platform. No scanner flagged the lateral movement path because no scanner modeled cross-service authentication chains. The individual findings were low severity. The exploit chain was catastrophic.
The problem that does not have a name yet but will in 18 months
'Service mesh drift' will be formally named as a vulnerability class within 18 months — the condition where service mesh authorization policies, deployed correctly at launch, degrade into permissive defaults as teams add services faster than they update policy. At least two major post-mortems of cloud-native breaches will cite it explicitly by 2027.
The pattern is already present across Vulnox assessment data: organizations that deployed Istio or Linkerd with correct authorization policy at launch had, on average, 34% of subsequently added services operating outside that policy 12 months later. New services get added under deadline pressure. Mesh policy updates are not part of the deployment checklist. The default when policy is absent is permissive. Each new service resets the blast radius. The mechanism is real and consistent. The name does not exist yet.
Confidence: highCheck OWASP Cloud-Native Application Security Top 10 revision history and major incident post-mortems published by Wiz, Lacework, or Mandiant between 2026 and 2027. If no named category for post-deployment mesh policy drift appears, the prediction fails.Sidecar compromise will replace container escape as the primary initial access technique in Kubernetes environments by Q4 2026, as container runtime hardening matures and attackers shift to the softer target of service proxies and logging agents.
Container escape techniques are increasingly mitigated by seccomp profiles, AppArmor, and rootless container adoption. Sidecar proxies — Envoy, Linkerd-proxy, logging agents, secrets injectors — run with significant cluster privileges, are updated less frequently than application containers, and are rarely included in vulnerability scanning scope. The displacement is already beginning: Vulnox found sidecars running image versions 3 or more minor releases behind the application container in 47% of assessed environments.
Confidence: mediumReview Datadog's State of Cloud Security report and CNCF security audit findings between 2026 and 2027. If container escape still accounts for more than 40% of reported Kubernetes initial access techniques, the prediction fails.
What 84 microservices assessments actually showed
68%
Of organizations with API gateways had at least one service directly reachable on the internal network without gateway authentication in the path — Vulnox assessment data, 84 engagements, 2022–2024. The gateway secured external access. Internal access was flat.
54%
Of assessed microservices environments used hardcoded credentials, environment variables, or other weak secrets management practices. HashiCorp Vault or equivalent was present in 31% of those environments — deployed but not integrated with the services that needed it. Vulnox assessment data, 2022–2024.
42%
Of assessed environments had inter-service communication with no authentication beyond network adjacency — services trusted each other by virtue of being in the same cluster, not by verified identity. TLS encryption was present in most of these; TLS without mutual authentication encrypts the channel but does not verify the caller. Vulnox assessment data, 2022–2024.
71%
Of assessed organizations lacked distributed tracing that correlated events across more than two services. Logging existed in all of them. The logs did not answer the question 'which services did this request touch, in what sequence, with what credentials?' — the exact question an incident responder needs answered in the first four hours. Vulnox assessment data, 2022–2024.
47%
Of assessed environments had sidecar proxy images running three or more minor versions behind the application container they served. Sidecar update cadence was not part of any deployment pipeline reviewed. The application got patched. The proxy running next to it did not. Vulnox assessment data, 2022–2024.
Why lateral movement is invisible to the tools most teams rely on
Vulnerability scanners test services as endpoints. They connect to a port, probe for known vulnerabilities, check the TLS configuration, compare the image against a CVE database. What they do not model is a transaction that starts at service A, authenticates to service B using a credential harvested from A's environment variables, uses that access to call service C, and finally reaches the secrets store because C has an overprivileged service account. That is not a vulnerability in any single service. It is an exploit chain across four. Each individual service scores clean. The chain is catastrophic.
Example
In the SaaS platform incident above, the attacker's path crossed five services. Vulnox ran a post-incident assessment and scanned each service individually — all five scored below medium severity. When we modeled the services as a connected graph and traced the authentication chain, the path from the metrics endpoint to admin token issuance required three hops, each using credentials or network access that a scanner would classify as 'internal' and deprioritize. The exploit chain existed entirely in the space between what individual service scans show and how services actually communicate at runtime.
Istio and Linkerd both support mutual TLS (mTLS) and authorization policy that would have broken this chain at hop two. Both were present in the environment. Authorization policy was set to ALLOW for the services involved because the team had not updated mesh policy when the token service was added six months after initial mesh deployment. This is the service mesh drift pattern. The tool was configured correctly at launch. The environment outgrew the configuration. Nobody noticed because no assessment checked mesh policy against current service inventory.
Three findings that contradicted what clients believed going in
Assessment base: Vulnox assessment data, 2022–2024, 84 microservices security assessments across SaaS platforms, fintech, and e-commerce environments, primarily European and US-based teams.
Dedicated security teams produced more permissive service mesh configurations than teams without dedicated security staff
In 19 of 84 assessments, the organization had a dedicated security team of two or more people. Of those 19, 14 had service mesh authorization policies that defaulted to permissive for services added after initial deployment. Teams without dedicated security staff were more likely to leave mesh authorization disabled entirely — which is visibly wrong and gets caught. Teams with dedicated security staff had deployed Istio or Linkerd with correct policy, then allowed policy drift as services were added. The correct initial configuration created false confidence that the mesh was governed.
Security teams that deploy mesh tooling correctly at launch often stop treating mesh policy as an ongoing operational concern. The deployment is done. The policy is written. What they do not track is whether policy covers the current service inventory. Twelve months after deployment, the average assessed environment had 34% of services outside the authorization policy that was written for the original service set.
Secrets management tooling was present but not integrated in 31% of environments citing Vault as their secrets solution
When Vulnox assessed environments where teams stated they used HashiCorp Vault for secrets management, 31% had Vault deployed and accessible but services still reading secrets from environment variables or mounted files populated at build time. Vault was the documented solution. Environment variables were the actual solution. The gap existed because Vault integration required application code changes that had not been prioritized alongside the infrastructure deployment.
A secrets management tool that is not integrated with the services that need secrets is a compliance artifact, not a security control. The audit shows Vault is present. The attacker reads environment variables. These are not the same assessment.
Network policies existed as YAML files in version control but were not applied to the cluster in 23% of assessed Kubernetes environments
Vulnox found 23% of Kubernetes environments had Kubernetes NetworkPolicy objects documented, reviewed, and stored in the team's GitOps repository — and not applied to the running cluster. The policy had been written during initial architecture. A cluster rebuild or environment migration had not re-applied it. The cluster was running with default-allow networking. The team believed network segmentation was in place because the policy files existed. Nobody had verified the running state.
GitOps creates a single source of truth for intended cluster state. It does not guarantee that intended state is the running state. A microservices security assessment that reviews network policy YAML without querying the cluster for applied policies is reviewing documentation, not configuration.
The API gateway is not your perimeter — it is your blind spot
Common belief
A well-configured API gateway handles authentication and authorization for your microservices. Services behind the gateway are protected.
What we found
In 68% of assessed environments, Vulnox verified direct reachability of at least one production service on the internal network without passing through the API gateway — using only cluster-internal network access. In 41% of those cases, the directly reachable service handled sensitive operations (token issuance, payment processing, or PII storage) that the team believed were protected by gateway-enforced authentication. The belief was accurate for external traffic. It was not accurate for internal traffic, which is where post-compromise lateral movement occurs.
The gateway protects the path from the internet to your services. It does not protect the paths between your services once one of them is compromised. An attacker who gains access to any service inside the cluster — through a dependency vulnerability, a compromised CI/CD pipeline, or a misconfigured build artifact — is now inside the gateway's trust boundary. From there, they move between services using whatever inter-service trust model exists. In 68% of environments Vulnox assessed, that model was network adjacency: if you are in the cluster, you can reach the service. The gateway protected one entry point. The interior had dozens.
Four surfaces that microservices assessments consistently miss
Sidecar and service proxy attack surface
Envoy proxies, Linkerd sidecars, logging agents, and secrets injectors run alongside application containers with significant cluster privileges. They are updated on a different cadence than the application — often not part of the application's CI/CD pipeline at all. Vulnox found sidecars running three or more minor versions behind the application container in 47% of assessed environments. CVEs in sidecar proxies are exploitable without touching application code. Most assessments scan application images. Sidecar images are rarely in scope.
Service-to-service authentication chains
Mutual TLS encrypts inter-service traffic. It does not, by itself, authorize what one service can ask another service to do. A service with a valid mTLS certificate can be authorized to call any endpoint unless authorization policy explicitly restricts it. In 42% of assessed environments, mTLS was present and inter-service authorization policy was absent — meaning any service could impersonate any other service's request to any endpoint, as long as it had a valid certificate. Encryption without authorization is a false security boundary.
Build and registry pipeline integrity
A compromised base image or a malicious dependency pulled during build can deploy attacker-controlled code into production without touching any running service. Most microservices security assessments focus on running workloads. The build pipeline — the CI system, the image registry, the dependency resolution — is almost never in assessment scope. In three Vulnox engagements, the most significant finding was not in the runtime environment but in the build pipeline: an unprotected registry with push access for any authenticated user in the organization.
Observability gaps that become forensic gaps
Distributed tracing that does not correlate events across more than two services cannot answer the incident responder's first question: 'what did this request touch?' In 71% of assessed environments, the tracing coverage was sufficient for performance debugging — identifying slow services — but insufficient for security investigation — tracking a credential through an authentication chain. These are different instrumentation requirements. Teams build for performance visibility. They discover the forensic gap when they need it during an incident.
What a real microservices security assessment covers
Step 4 — authenticated lateral movement simulation. Teams run port scans and image scans. Nobody simulates what an attacker does after they are already inside one service. That simulation is the only way to find the exploit chains that caused every major microservices breach in the last three years.
- 1Security architect
Map every service in the current running cluster against your documented service inventory and your current mesh authorization policy. The three-way gap — services that exist but are not documented, services that are documented but outside policy scope, services that are in policy but with permissive defaults — is your starting attack surface. Do this from cluster state, not from architecture diagrams.
Expected outcomeA verified service inventory with policy coverage status per service. Any service outside authorization policy scope is operating on network-adjacency trust, regardless of what your mesh documentation says.
- 2Security engineer
Test inter-service reachability directly. From each service's network context, attempt to reach every other service in the cluster — not through the API gateway, through internal DNS and direct IP. Document which services are reachable from which others, and compare that against your intended communication graph. The difference between intended and actual reachability is your internal attack surface.
Expected outcomeA reachability matrix that shows actual cluster-internal network topology. This is the map an attacker builds during reconnaissance. You need it before they do.
- 3Security engineer + application team
Verify that secrets management integration is actual, not documented. For each service that the secrets management policy says uses Vault or equivalent, check the runtime process environment for hardcoded values or environment variable secrets. grep for credential patterns in running container environments. The policy says Vault. The process environment tells you what is actually running.
Expected outcomeVerified secrets handling per service. Any service reading secrets from environment variables while Vault is the documented solution has a gap between policy and implementation that converts a container compromise into credential exposure.
- 4Penetration tester
Run authenticated lateral movement simulation. Starting from a compromised service with realistic initial access (a service account token, a set of environment variable credentials, cluster-internal network access), execute a structured attempt to reach the highest-privilege service in the environment using only what that initial foothold provides. Document each hop. The path from low-privilege initial access to high-privilege service access is the exploit chain your scanner cannot find.
Expected outcomeA documented lateral movement path, or documented evidence that no path exists. Either result is useful. The path tells you what to fix. The absence of a path tells you the controls are working.
- 5Operations + security team
Verify sidecar and proxy image versions against the CVE database independently of the application image scan. Enumerate every sidecar running in the cluster — Envoy version, Linkerd-proxy version, any logging agent or secrets injector — and check each against current CVE data. Add sidecar image updates to the deployment pipeline with the same SLA as application image updates.
Expected outcomeSidecar vulnerability exposure equivalent to application container exposure. Any environment where the application image is current and the proxy image is three minor versions behind has a different security posture than documented.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionOWASP Testing Methodologies
OWASP testing methodologiesNational Vulnerability Database NIST
NIST National Vulnerability Database
Frequently Asked Questions
What does a microservices security assessment need to test that automated scanners miss?
Automated scanners test services in isolation — port exposure, image CVEs, TLS configuration. They do not model how an attacker moves between services after compromising one. The most dangerous microservices vulnerabilities are exploit chains that cross multiple services, using credentials harvested from one to authenticate to another. Vulnox found that in 84 assessments, individual service scans returned low or medium severity findings on all five services involved in one post-incident reconstruction. The cross-service exploit chain that gave administrative access was invisible to the scanner.
How do attackers bypass API gateway security in microservices environments?
API gateways protect the path from the internet to internal services. They do not protect inter-service communication once an attacker is inside the cluster. An attacker who compromises any service — through a dependency vulnerability, a build pipeline compromise, or a misconfigured artifact — is inside the gateway's trust boundary. From there, they can reach other services directly on the internal network without passing through the gateway. Vulnox found that 68% of organizations with API gateways had at least one sensitive service directly reachable on the internal network without gateway authentication in the path.
What is service mesh drift and why does it matter for microservices security?
Service mesh drift is the condition where authorization policies deployed correctly at launch degrade as new services are added without corresponding policy updates. When policy is absent for a service, the mesh default is permissive — the service is reachable from anywhere in the cluster. Vulnox found that organizations had, on average, 34% of services outside their authorization policy 12 months after initial mesh deployment. The mesh was configured correctly. The environment outgrew the configuration. Assessments that review mesh policy documents without checking coverage against the current service inventory will not find this gap.
Why do organizations with dedicated security teams have worse service mesh configurations?
Teams with dedicated security staff deploy service mesh tooling correctly at launch — authorization policy is written, reviewed, and documented. That correct initial configuration creates confidence that the mesh is governed, which reduces the team's operational attention to mesh policy as an ongoing concern. New services get added under deadline pressure without policy updates. Teams without dedicated security staff often skip mesh authorization entirely, which is visibly wrong and gets caught. Partial implementation with visible governance is harder to identify as misconfigured than absent implementation. Vulnox found this pattern in 14 of 19 engagements with dedicated security teams.
How do I test inter-service authentication in a Kubernetes microservices environment?
From each service's network context, attempt to reach every other service in the cluster directly — through internal DNS and direct IP, not through the API gateway. Document which services are reachable without authentication, which require mTLS certificates, and which enforce authorization policy beyond certificate validation. Then compare that reachability matrix against your intended communication graph. The difference between intended and actual reachability is your internal attack surface. For environments using Istio or Linkerd, query the mesh control plane for authorization policies and verify coverage against your current service inventory — not your architecture diagram.
What secrets management mistakes are most common in microservices security assessments?
The most common finding is that secrets management tooling is deployed but not integrated. In 31% of Vulnox assessments where teams cited HashiCorp Vault as their secrets solution, services were still reading secrets from environment variables or build-time mounted files. Vault was the documented solution; environment variables were the actual solution. The gap exists because Vault integration requires application code changes that get deprioritized after infrastructure deployment. Verification requires checking the runtime process environment of each service, not the secrets management policy document.
What is the most commonly missed attack surface in a microservices security assessment?
Sidecar proxies and service agents — Envoy, Linkerd-proxy, logging agents, secrets injectors. These run with significant cluster privileges and are updated on a different cadence than application containers, often not included in the application CI/CD pipeline. Vulnox found sidecars running three or more minor versions behind their application container in 47% of assessed environments. CVEs in sidecar proxies are exploitable without touching application code. Most assessments scan application images. Sidecar image versions are rarely in scope.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.