Microservices split a single application into dozens, hundreds, or — in Uber's case, by its own 2020 engineering blog post — more than 4,000 independently deployed services. That architecture shift changed what "securing an application" means. Instead of one codebase with one attack surface, you now have hundreds of network-exposed endpoints, each with its own dependencies, its own service account, and its own path to production. Netflix has publicly described running over 1,000 microservices handling roughly a billion API requests a day; Monzo's engineering team has written about operating more than 1,500 services for a single banking app. Microservices security is the set of practices — authentication between services, encrypted service-to-service traffic, dependency and container scanning, and runtime access control — that keeps that sprawl from becoming an unmanaged attack surface. The 2019 Capital One breach, where an attacker exploited a misconfigured web application firewall to pivot through internal services and reach data on 106 million customers, is the canonical example of what happens when that discipline is missing.
What Is Microservices Security?
Microservices security is the practice of protecting an application that's been decomposed into independently deployable services, each communicating over a network rather than through in-process function calls. In a monolith, a function call between two modules never leaves the process and is implicitly trusted. In a microservices architecture, that same interaction becomes an HTTP or gRPC call across a network boundary — which means it can be intercepted, spoofed, or exploited by anything else running on that network. Securing microservices covers four layers: the code and dependencies inside each service, the container and image it ships in, the network path between services, and the identity/authorization model that decides which service can call which. Missing any one layer creates a gap an attacker can use to move laterally once they land on a single compromised service.
Why Is Microservices Security Harder Than Monolith Security?
Microservices security is harder because it multiplies the number of things that need independent authentication, patching, and monitoring instead of consolidating them into one. A monolith might have one dependency tree and one deployment pipeline; a microservices estate with 200 services can have 200 separate dependency trees, 200 separate container images, and 200 separate opportunities for a stale library or exposed port. Google's internal Zanzibar paper, which describes the authorization system built to handle this problem at scale, was written precisely because per-service, ad-hoc authorization checks don't hold up once you're past a few dozen services. The blast radius problem compounds this: in a monolith, a vulnerable function is contained inside one process boundary. In a microservices architecture, a vulnerable service with an open network path to a database or an internal API can let an attacker move from a low-value entry point — say, an image-resizing service — to a high-value one, like a payments service, in a single hop if there's no segmentation between them.
What Are the Biggest Microservices Security Risks?
The three biggest microservices security risks are excessive inter-service trust, unpatched transitive dependencies, and exposed internal APIs. Excessive inter-service trust means any service on the internal network can call any other service without re-authenticating — this is exactly the lateral-movement pattern used in the Capital One breach, where SSRF against a misconfigured WAF gave the attacker credentials that worked against internal services never designed to face untrusted callers. Unpatched transitive dependencies are the second risk: Log4Shell (CVE-2021-44228), disclosed in December 2021 with a maximum CVSS score of 10.0, sat several layers deep inside the dependency tree of countless services, and organizations running microservices struggled for weeks to even enumerate which of their hundreds of services pulled in the vulnerable Log4j version. Third, exposed internal APIs — endpoints meant only for service-to-service traffic but reachable from outside because of a misconfigured ingress rule — are common enough that the OWASP API Security Top 10 dedicates a category (API8:2023, Security Misconfiguration) specifically to this failure mode.
How Do You Secure Service-to-Service Communication?
You secure service-to-service communication with mutual TLS (mTLS) and a service mesh that enforces it by default rather than per-application. mTLS requires both the calling service and the receiving service to present certificates, so a compromised or rogue workload can't simply call an internal API because it's on the same VPC. Service meshes like Istio and Linkerd implement this at the infrastructure layer — sidecar proxies handle certificate issuance, rotation, and encryption so individual development teams don't have to build TLS handling into every service. Without a mesh, mTLS adoption tends to be inconsistent: some teams wire it up, others skip it under deadline pressure, and the resulting gaps are exactly where lateral movement happens. Beyond encryption, service-to-service authorization should follow a default-deny model — a service should have to be explicitly allow-listed to call another service, not implicitly trusted because it's inside the cluster network.
What Tools Are Used for Microservices Security?
Microservices security relies on five tool categories: software composition analysis (SCA), container image scanning, service mesh/mTLS, API gateways, and runtime detection. SCA tools scan each service's dependency manifest — package.json, requirements.txt, go.mod — against known-vulnerability databases like the NVD, which is how teams found out whether any of their services depended on the vulnerable Log4j 2.x line during the Log4Shell response. Container image scanners check the base image and installed packages inside each service's Docker image for known CVEs before it ships, catching issues like the 2019 runc container escape (CVE-2019-5736, CVSS 8.6) at build time rather than in production. API gateways centralize authentication, rate limiting, and request validation for the services they front, reducing the number of places that logic has to be implemented correctly. Runtime detection tools — eBPF-based agents are increasingly common here — watch for anomalous behavior like a service suddenly making outbound connections it's never made before, which is often the first observable sign of compromise.
What Are Best Practices for Microservices Security?
The core best practices are least-privilege service accounts, default-deny network policies, automated dependency updates, and centralized secrets management. Each service should run with its own identity and only the permissions it needs — a service that reads from a queue shouldn't also have write access to a database three services away. Kubernetes NetworkPolicies or a service mesh's authorization policies should deny traffic by default and require explicit rules to permit it, so a newly deployed or compromised service doesn't automatically inherit access to everything else in the cluster. Dependency updates need automation because manual tracking doesn't scale past a handful of services — teams that were still manually auditing dependency manifests during the Log4Shell response in December 2021 took days to weeks to find every affected service, while teams with automated SBOM inventories found and patched theirs in hours. Secrets — API keys, database credentials, service tokens — belong in a dedicated secrets manager (Vault, AWS Secrets Manager, or equivalent), never in environment variables baked into a container image, since a leaked image or misconfigured registry then leaks the secret too.
How Safeguard Helps
Safeguard addresses microservices security by tying every finding to actual exploitability instead of raw CVE counts. Our reachability analysis traces whether a vulnerable function in a dependency is actually called by your service's code paths, so a team running 300 microservices can immediately tell which handful of alerts matter instead of triaging hundreds of theoretical CVEs. Griffin, Safeguard's AI security analyst, reviews pull requests and dependency changes across every service in the mesh and flags risky patterns — like a new outbound call to an unauthenticated internal endpoint — before merge. Safeguard generates and ingests SBOMs at the service level, giving you a real-time inventory of what's running where, which is exactly the capability that separates a days-long Log4Shell-style scramble from an hours-long fix. When a fix is available, Safeguard opens an auto-fix pull request with the patched dependency version pre-tested against your build, so remediation across a large service fleet doesn't require a security team manually filing tickets against every affected repo.