How can security teams detect serverless execution?

What security teams should look for first

Detection starts with the execution plane, not the application code. In practice, that means correlating function invocations with the identity that triggered them, the API calls made around the same time, and any deployment or configuration changes that landed outside the normal change window. A single signal is rarely enough, because legitimate serverless workloads can be bursty and highly distributed.

The most useful starting point is to establish a baseline for who normally deploys, what regions or accounts they use, and which upstream events typically invoke the function. Once that baseline exists, deviations become visible: new callers, unexpected invocation sources, altered environment variables, or a sudden spike in short-lived compute activity that does not match the release calendar.

Serverless Security Guide covers the execution roles, event injection paths, and logging patterns that help teams distinguish normal function activity from abuse.

Execution patterns that usually expose abuse

Serverless abuse is often visible in the shape of the workload. Functions that appear only briefly, then disappear, may still leave a clear trail in logs, billing, and control-plane telemetry. Watch for functions that make outbound connections to unfamiliar destinations, especially when the destination is unrelated to the expected business flow or appears only after a code or configuration change.

Unexpected API activity is another strong signal. That can include a function reading secrets, listing resources, creating permissions, or calling services it has never used before. The question is not simply whether the function ran, but whether the surrounding actions make sense for that function, that identity, and that event source.

Teams should also treat function creation or modification outside change control as a detection priority. If a new handler appears, an existing one is repointed, or a deployment arrives from an unusual location or principal, the most likely explanation is either operational drift or unauthorized access. In both cases, the control objective is the same: prove who made the change and whether the triggering permissions were valid.

Why the permission trail matters as much as the function trail

Serverless execution is easy to miss if defenders only inspect the code layer. The more reliable view comes from linking function behavior back to the caller, the upstream event, and the permission set that allowed both the deployment and the runtime action. If the caller should not have been able to create, alter, or invoke the function, detection should move from anomaly spotting to compromise assessment.

This is especially important when a function is triggered by another cloud service, because abusive behavior may look like normal automation unless the identity chain is examined end to end. A valid invocation from a compromised or over-privileged identity can still be malicious, so the decision point is whether the access path and resulting behavior match the expected trust boundary.

MITRE ATT&CK Enterprise Matrix is useful for mapping the surrounding behaviors, including credential access, lateral movement, and execution patterns that often accompany cloud compromise.

Risk and Threat Considerations

Serverless environments compress attack time. A malicious function can run briefly, touch multiple services, and leave behind only a narrow log window, which makes poor telemetry or delayed review especially risky. The same elasticity that helps defenders scale can also hide low-and-slow abuse, unauthorized data access, or short-lived infrastructure used for exfiltration.

Failure mechanism: Adversaries abuse trusted execution and event-driven triggers, then use legitimate cloud permissions to blend in with normal function activity while making unauthorized API calls or outbound connections.

Impact: Teams may miss code tampering, secret access, data movement, or privilege misuse until after the function has already completed and the evidence trail has thinned.

Practitioner Guidance

What to verify: Confirm that every function modification can be tied to a known identity, approved deployment path, and expected change record. If you cannot explain the trigger, the caller, and the deployment source together, treat the event as suspicious rather than merely unusual.

What to measure: Track invocations that arrive from new principals, new regions, or new event sources, and flag any function that suddenly expands its outbound destinations or starts calling sensitive APIs. Those are often the earliest practical indicators that execution has shifted away from the intended use case.

Practitioner takeaway: Serverless detection works best when you reconstruct the full execution story, trigger, caller, deployment, and outbound behavior, instead of relying on function logs alone.

Related resources from NHI Mgmt Group

• How do security teams detect Python supply chain malware that uses obfuscation to hide import-time execution?
• How should security teams detect auto-execution risks in AI data processing pipelines before an attacker pivots deeper into the environment?
• How can teams tell whether their serverless security model matches the real Lambda execution model?
• How should security teams detect and prioritize LOLBAS activity in Windows environments before attackers turn trusted tools into delivery and execution paths?