ASVS 5.0 V12.3.3 requires TLS, or another suitable transport encryption, for all HTTP traffic between the internal services that make up your application, and no fallback to plaintext. It is Level 2.
Where V12.3.1 covers all connections broadly, this one targets the east west HTTP calls between your own microservices.
Why it matters
Internal calls carry user identifiers, tokens and business data. A single compromised pod can read every plaintext call on its network segment.
How to implement it
Pick one mechanism and apply it everywhere.
- A service mesh with mutual TLS in strict mode, which encrypts pod to pod traffic without changing application code.
- TLS in each service, using certificates issued by an internal CA.
- Encrypted overlay networking, if it is the documented design and you can show it covers every path.
Istio strict mode example:
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: prod
spec:
mtls:
mode: STRICT
STRICT rejects plaintext. PERMISSIVE accepts both and is meant for migration only.
How to test it
From a pod outside the mesh (or with the sidecar bypassed), call a service by plain HTTP:
curl -v http://orders.prod.svc.cluster.local:8080/health
It must be refused or reset. Also check mesh policy status for any namespace still in permissive mode.
Common mistakes
- Leaving the mesh in permissive mode after the migration.
- Excluding "legacy" ports from the sidecar and forgetting them.
- Encrypting service calls but not the calls to sidecars, probes or metrics scrapers.
Quick check
Is a private cluster network a replacement for TLS?
No. The requirement is transport encryption between the services themselves.
