Serverless Execution is the running of code in a cloud function or similar managed compute service without administering the underlying server. Attackers use it to hide infrastructure, automate abuse and complicate attribution, so defenders should monitor function creation, permissions, triggers, outbound traffic and unusual runtime behaviour.
What Serverless Execution Actually Changes
Serverless execution changes the operating model, not the security problem itself. Code still needs to be deployed, invoked, monitored and constrained, but the cloud provider handles server provisioning and much of the runtime administration, which shifts attention toward function-level risk rather than host-level hardening.
This matters because defenders lose many of the familiar server-centric control points. Security teams must reason about code packages, event sources, permissions, outbound calls and runtime behaviour as the primary attack surface, especially when the service can scale quickly or be triggered automatically.
Why Serverless Execution Is Attractive to Defenders and Attackers
For defenders, serverless execution can reduce patching burden and narrow the scope of infrastructure management. For attackers, the same abstraction can make malicious activity harder to attribute because the visible layer is a managed function, not an easily inspected host.
That creates an asymmetric environment. A small amount of abusive code can generate significant activity, while the underlying compute layer remains opaque. Monitoring therefore needs to focus on invocation patterns, permission changes, trigger configuration and unusual egress rather than waiting for traditional server indicators.
Core Security Controls Around Serverless Runtime
The most important control themes are least privilege, strong invocation boundaries and visibility into what functions can reach and do. A function that has broad permissions, permissive triggers or unrestricted outbound network access becomes a high-leverage point for abuse.
Operationally, organisations should treat each function as a distinct trust boundary. That means mapping who or what can invoke it, what data it can touch, which secrets it can read and which external services it can call. The same discipline applies to temporary resources such as event queues, API gateways and managed identities attached to the function runtime.
Good serverless security also depends on knowing which functions exist in the first place. If inventory is incomplete, orphaned handlers, overly broad event rules and shadow deployments can persist unnoticed, especially in fast-moving development environments.
Detection, Investigation and Recovery After Abuse
Detection should correlate code creation or update events with permission changes, trigger edits and unusual runtime patterns. A suspicious function is often easier to spot through behaviour, such as unexpected outbound traffic, sudden invocation spikes or access to data the function does not normally need.
If abuse is suspected, teams should review the function package, configuration, execution logs and any linked secrets or tokens that may have been exposed. Post-incident review should also confirm whether the function was used as a staging point for further cloud abuse or persistence. Defensive monitoring can be aligned with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where audit logging, access control and configuration management are central.
Risk and Threat Considerations
Serverless execution can reduce infrastructure burden, but it also concentrates risk in code, permissions and event-driven trust relationships. If those controls are weak, an attacker can hide abuse inside a legitimate managed service, use over-privileged functions to reach sensitive data and make investigation harder because there is no server to inspect in the usual way.
Failure mechanism: Excessive permissions, exposed triggers or compromised deployment paths allow a function to be used for hidden execution, automated abuse or unauthorised access to downstream services.
Impact: The result can include data exposure, credential theft, cloud resource abuse, persistence through misconfigured automation and slower incident attribution and containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Serverless needs function and control-plane audit trails to detect abuse and investigate changes. |
| AC-6 — Least Privilege | Serverless risk rises when functions have more permissions than they need to run. | |
| CM-2 — Baseline Configuration | Serverless security depends on controlled, reviewable function and trigger configuration. | |
| Recommendation — Log function lifecycle, invocation and configuration events to support detection and forensics. Restrict each function to the minimum permissions required for its event-driven task. Establish and maintain secure baselines for function settings, triggers and runtime options. | ||
| CIS Controls v8 | 5 — Account Management | Serverless access is governed through identities, roles and service permissions attached to functions. |
| Recommendation — Review and remove unnecessary function-linked access paths and permissions. | ||
| MITRE ATT&CK | T1583 — Acquire Infrastructure | Serverless can be used to conceal attacker-owned infrastructure and stage abuse. |
| Recommendation — Map serverless-hosted abuse to infrastructure acquisition patterns and hunt for related staging activity. | ||
Practitioner Guidance
What to watch for: Treat every new function, trigger or permission expansion as a security-relevant change, not just a developer convenience. The most common operational mistake is assuming managed compute removes the need for strong access governance, when it actually shifts the burden to runtime permissions and event hygiene.
Practitioner takeaway: Serverless security is largely a problem of control plane discipline, know what was deployed, who can invoke it, what it can reach and what it emits.
Related resources from NHI Mgmt Group
- How can teams tell whether their serverless security model matches the real Lambda execution model?
- How should security teams protect serverless functions without slowing execution or driving up cloud costs?
- Why do serverless workloads create more privileged access risk than ordinary application execution?
- Why can serverless execution create unexpected cost and access risk if teams do not control invocation patterns carefully?