Cloud-Native and Serverless Security: The Misconfigurations Traditional Scanning Misses

Serverless and cloud-native architectures were supposed to shrink the security surface, no servers to patch, functions that spin up and disappear, infrastructure entirely managed by the cloud provider. In practice, they moved the risk rather than removing it, and traditional vulnerability scanning, built around long-lived hosts with a fixed IP and an OS to check patch levels on, is structurally bad at finding what actually goes wrong in a function-based or container-orchestrated environment.

Why traditional scanning misses so much here

A vulnerability scanner is built to enumerate hosts, check their exposed ports, and match installed software against known-CVE databases. A serverless function doesn't have a persistent host to scan, it exists as code and configuration, and its real risk lives in things a network scanner never looks at: the IAM role permissions attached to the function, the trust boundaries between functions, and the specific event sources (an API Gateway route, a queue, a storage bucket trigger) that can invoke it. Our piece on AWS IAM misconfigurations covers the identity side of this in more depth, and identity is disproportionately where serverless risk actually concentrates, because a function's permissions define its entire blast radius far more than any network-level control does.

The misconfigurations we keep finding

Overly permissive execution roles. A function given broad, wildcard IAM permissions "to make development easier" and never tightened before shipping is the single most common serverless finding, a function that only needs to read from one specific storage bucket, provisioned with permissions to read and write across an entire account. If that function is ever compromised through any other means (a vulnerable dependency, an injection flaw in the code itself), the attacker inherits every one of those excess permissions immediately.

Event-source injection. Functions that trust the structure and content of whatever triggered them, a message from a queue, an uploaded file's metadata, an API Gateway payload, without validating it the way a traditional application would validate user input. The trust boundary moved from "the network perimeter" to "whatever can publish an event this function will process," and that boundary gets tested far less consistently.

Secrets and configuration sprawl. Environment variables holding API keys and database credentials in plaintext, visible to anyone with read access to the function's configuration, a much softer target than a properly managed secrets store, and one that's easy to overlook specifically because it doesn't look like a traditional "hardcoded secret in code" finding (see our piece on hardcoded secrets in code for the broader pattern this is a variant of).

Missing network policies in orchestrated environments. The same problem shows up in Kubernetes and container deployments generally, where a missing or overly permissive network policy lets any pod in a cluster talk to any other pod by default, see our dedicated piece on Kubernetes and container security misconfigurations for the fuller picture there.

What catches this

None of these are things a port scan finds. They require someone who actually understands the specific cloud provider's IAM model, reviews the real permission policies attached to real resources, and tests the trust boundaries between services the way an attacker who's already gained a foothold would try to move laterally. That's the manual review our Cloud Security and AWS Security services are built around, reviewing the actual configuration and permission graph, not just checking whether known-CVE software versions are present. For the broader case for why manual review consistently catches what scanning tools structurally can't, see our piece on what automated scanners miss.