Category: Cloud Security

Serverless Security

Also known as: Function-as-a-Service Security, FaaS Security

Simply put

Serverless security is the set of practices and technologies used to protect applications built on serverless computing, where cloud providers run code on demand without the organization managing the underlying servers. It focuses on securing the individual functions, the data they handle, and the managed cloud services they connect to. Because these functions often run only briefly, they introduce protection challenges that differ from traditional always-on servers.

Formal definition

Serverless security is the discipline of protecting event-driven, function-based workloads (such as Function-as-a-Service deployments) and the managed cloud services they invoke. It encompasses the practices, programs, and technologies organizations deploy to secure serverless computing architecture, including checking for vulnerabilities and attacks against serverless applications, hardening configurations, enforcing data separation, and using controls such as API gateways as security buffers. The model must account for the short-lived, ephemeral nature of functions, which advanced attackers have been observed abusing as temporary infrastructure, for example, using serverless functions as command-and-control (C2) servers precisely because functions operate for very brief periods.

Why it matters

Serverless computing shifts the operational burden of running servers to the cloud provider, but it does not remove the organization's responsibility for securing the code it deploys, the data those functions handle, and the managed cloud services they connect to. The security model differs meaningfully from traditional always-on servers because functions are event-driven and often run only for very brief periods. That ephemeral nature reduces the attack surface in some respects, but it also complicates monitoring, forensics, and detection, since a function may execute and disappear before conventional tooling registers it.

Attackers are aware of these characteristics. Advanced adversaries have been observed abusing serverless functions as temporary infrastructure, using them as command-and-control (C2) servers precisely because the functions operate for such short intervals, making the malicious activity harder to trace. This means serverless security is not only about defending an organization's own applications from vulnerabilities and attacks, but also about recognizing that the same properties which make serverless attractive to developers can be turned to an attacker's advantage.

For security leaders, serverless security underscores that governance and risk management must extend to architectures where there is no server to patch or harden in the traditional sense. The relevant controls move toward securing individual functions, enforcing data separation and secure configurations, and placing buffers such as API gateways in front of exposed functions. Treating serverless as inherently secure because the provider manages the infrastructure is a common and consequential misunderstanding.

Who it's relevant to

Security Leaders and Virtual CISOs

For a virtual or fractional CISO advising an organization that builds on serverless, this topic belongs firmly in the governance and risk conversation rather than being dismissed as a purely technical detail. A vCISO typically helps define which serverless controls, such as configuration hardening, data separation, and API gateway buffering, should be required, and clarifies that accountability for these decisions remains with the client organization. Hands-on tasks such as configuring gateways or administering the functions themselves are generally outside a vCISO's scope unless explicitly contracted.

Development and Platform Teams

Teams building Function-as-a-Service applications are directly responsible for securing the code within each function, enforcing secure configurations, and managing the permissions functions hold over connected cloud services. They must design with the ephemeral nature of functions in mind, since that behavior affects both how attacks unfold and how activity can be monitored.

Cloud and Security Operations Teams

Operations teams face the challenge that functions may execute only briefly, which can undermine conventional always-on monitoring approaches. They are relevant to serverless security because detection, logging, and response strategies must be adapted to transient workloads, including the possibility that adversaries abuse serverless functions as short-lived command-and-control infrastructure.

Compliance and Risk Stakeholders

Stakeholders responsible for risk and configuration governance need to understand that using a managed serverless platform does not transfer responsibility for the organization's code, data handling, and configuration decisions to the provider. The value of serverless security controls depends on organizational maturity, clearly defined scope, and cooperation between security, development, and operations functions.

Inside Serverless Security

Function-Level Attack Surface

Serverless architectures decompose applications into many small, event-driven functions, each of which represents a distinct entry point. Security must be considered per function, including its triggers, permissions, and dependencies, rather than at a single application perimeter.

Identity and Access Management (IAM) for Functions

Each serverless function typically runs with an assigned role and set of permissions. Applying least-privilege scoping to these roles is a core component, as over-permissioned functions are a common source of risk in serverless environments.

Event and Trigger Security

Serverless functions are invoked by events from sources such as API gateways, message queues, storage changes, or scheduled triggers. Validating and controlling these event sources is part of securing the execution flow, since untrusted or malformed event data can drive function behavior.

Third-Party and Dependency Risk

Functions often rely on external libraries and packages. Because the underlying infrastructure is managed by the cloud provider, dependency and code-level vulnerabilities become a proportionally larger share of the customer's responsibility.

Shared Responsibility Boundary

In serverless models, the cloud provider manages the servers, operating system, and runtime patching, while the customer remains responsible for their function code, configuration, permissions, and data. Understanding where this boundary falls is central to serverless security.

Configuration and Secrets Management

Serverless functions frequently require access to credentials, API keys, and configuration values. Securely storing and injecting these secrets, rather than hardcoding them, is a recurring component of a serverless security program.

Monitoring, Logging, and Observability

Because functions are ephemeral and short-lived, traditional host-based monitoring may not apply. Logging of function invocations, errors, and access patterns supports detection and investigation, though the specific tooling may vary by provider and engagement.

Common questions

Answers to the questions practitioners most commonly ask about Serverless Security.

Does going serverless mean the cloud provider handles all of my security?

No. Serverless operates under a shared responsibility model. The provider typically secures the underlying infrastructure, runtime, and physical hosting, but the customer remains responsible for application code, function permissions, data handling, identity and access configuration, and dependencies. Assuming the provider covers everything is a common and costly misconception. A virtual CISO can help clarify where the responsibility boundary falls for a given provider and service, but accountability for the customer-controlled layers generally remains with the client organization.

Because functions are short-lived, does that mean serverless has a smaller attack surface I don't need to worry about?

Not necessarily. Ephemeral execution can reduce persistence for some threats, but it does not eliminate risk. Each function, trigger, API endpoint, and integration point can expand the overall attack surface, and misconfigured permissions or vulnerable dependencies remain exploitable during execution. Short-lived compute can also complicate monitoring and forensic visibility. Treating serverless as inherently more secure without evaluating configuration, identity, and code is a mistake experienced practitioners would flag.

How should we approach least privilege for serverless functions?

In many engagements the guidance is to scope each function's permissions to the minimum required for its specific task rather than sharing broad roles across functions. This often involves per-function identities, narrowly defined access policies, and periodic review as functions change. A virtual CISO typically advises on governance and policy for this practice and helps prioritize it, while hands-on implementation and tuning generally sit with the client's engineering or platform teams unless explicitly contracted.

What can we do about visibility and monitoring when functions are ephemeral?

Because compute is short-lived, teams often rely on centralized logging, distributed tracing, and event capture from triggers and integration points rather than host-based monitoring. Establishing what to log, retention expectations, and alerting thresholds is typically a governance decision a virtual CISO can help frame. The actual deployment and administration of logging and monitoring tooling is usually an operational task outside a standard vCISO scope unless the engagement specifies otherwise.

How do we manage third-party dependencies and code risk in serverless applications?

Serverless functions frequently pull in external libraries and packages, so dependency management, vulnerability scanning, and update processes are often emphasized. In many engagements a virtual CISO helps establish policy around dependency vetting, secure development practices, and integration of scanning into the delivery pipeline. Executing scans, remediating vulnerable packages, and maintaining pipelines are generally responsibilities of the client's development and DevSecOps functions.

How does serverless security relate to frameworks and compliance efforts like SOC 2 or ISO 27001?

Serverless architectures can be evaluated against controls in frameworks such as SOC 2 or ISO 27001, particularly around access management, logging, change control, and data protection. A virtual CISO can support readiness by mapping serverless practices to relevant control expectations, but supporting readiness is distinct from asserting certification, and outcomes may vary by provider and organizational maturity. The value of this work often depends on client cooperation, defined scope, and access to the relevant engineering stakeholders.

Common misconceptions

Because the provider manages the servers, serverless applications are secure by default and require little customer attention.

The provider secures the underlying infrastructure, but the customer typically remains responsible for function code, permissions, configuration, secrets, and data. Accountability for these areas generally stays with the client organization and does not transfer to the provider.

A virtual CISO engaged for serverless security will implement and administer the security controls directly.

A virtual CISO typically provides strategy, governance, and risk guidance around serverless adoption, such as advising on least-privilege policies and shared-responsibility boundaries. Hands-on tasks like configuring IAM roles, tuning monitoring tools, or remediating function code are generally out of scope unless explicitly contracted, and are often carried out by internal engineering or DevOps teams.

Traditional perimeter and host-based security approaches transfer directly to serverless environments.

Serverless architectures distribute the attack surface across many event-driven functions and rely on ephemeral, provider-managed runtimes. Security often shifts toward identity, function-level permissions, event validation, and dependency management rather than a single defended perimeter.

Best practices

Apply least-privilege permissions to each function individually, avoiding shared or broadly scoped roles so that a compromised function cannot access resources beyond its needs.

Clearly document the shared responsibility boundary for your chosen provider, identifying which controls the provider manages and which remain the client organization's accountability.

Validate and sanitize event and trigger inputs from sources such as API gateways, queues, and storage events, treating them as potentially untrusted data driving function execution.

Manage secrets and credentials through a dedicated secrets store rather than hardcoding them in function code or configuration, and rotate them according to organizational policy.

Establish logging and monitoring suited to ephemeral functions, capturing invocations, errors, and access patterns to support detection and investigation, recognizing that appropriate tooling may vary by provider.

Maintain visibility into third-party dependencies and update or remediate vulnerable libraries, since dependency risk represents a larger proportion of the customer's responsibility in serverless models.