This article is based on findings from the ESG study “Security for DevOps – Enterprise Survey Report,” commissioned by application security company Data Theorem and originally covered by SDXcentral.
Why Enterprises Are Racing to Serverless
Enterprises are adopting serverless computing at a rapid pace, driven by three key priorities: improved security, faster delivery of new applications, and reduced operational overhead. But moving to serverless does not automatically eliminate security risk—it shifts and, in some ways, expands the threat surface organizations must manage.
That is the central finding of a study titled Security for DevOps – Enterprise Survey Report, conducted by Enterprise Strategy Group (ESG) and commissioned by application security vendor Data Theorem. ESG surveyed 371 IT and cybersecurity professionals at organizations across North America who are responsible for evaluating, purchasing, and managing cloud security technology. Critically, the study targeted organizations that were already mature cloud users—participants had meaningful experience with public cloud services and/or containers before serverless entered their stack.
Survey respondents came from a broad set of industries including manufacturing, financial services, healthcare, communications and media, retail, government, and business services.
The DevSecOps Coverage Gap
One of the study’s starkest findings is the gap between where organizations are today and where they need to be with DevSecOps. DevSecOps refers to the practice of embedding security controls and automated security testing directly into the CI/CD pipeline, so that security scales alongside development velocity rather than becoming a bottleneck.
The numbers tell a sobering story:
- Only 8% of organizations are currently securing 75% or more of their cloud-native applications using DevSecOps practices.
- 68% of organizations say they plan to reach that same threshold within two years.
- 82% of respondents report that different teams are assigned to secure cloud-native applications, creating organizational silos.
- Of that group, 50% plan to merge those responsibilities in the future, while 32% do not plan to consolidate at all.
“What we found in the study is that organizations are starting to implement DevSecOps processes, but they are not yet covering a lot of their applications,” said Doug Cahill, senior analyst and group practice director of cybersecurity at ESG. “When that number jumps so dramatically in two years, what I see happening is repeatability with security as code.”
Security as Code: The Path to Scale
The underlying driver for the shift toward DevSecOps is a structural one: there are not enough skilled security professionals to manually review and harden every application a modern engineering organization ships. The talent shortage is particularly acute in cloud security specifically.
“The challenge then is: if I have a business with multiple project teams, how does the security team keep up with the rate at which the project teams are moving?” Cahill said.
The answer is automation—embedding security checks, policy enforcement, and vulnerability scanning directly into the CI/CD pipeline so that every code commit, build, and deployment is evaluated consistently without requiring manual intervention from a security engineer.
“That’s how you get repeatability, that’s how you get scale, vis-a-vis security as code that can be replicated and repeated across multiple projects,” Cahill said.
Practical implementations of this approach include:
- Static application security testing (SAST) integrated into pull request workflows
- Software composition analysis (SCA) to flag vulnerable third-party dependencies at build time
- Infrastructure-as-code (IaC) scanning to catch misconfigured cloud resources before they are provisioned
- Runtime application self-protection (RASP) or runtime controls that enforce security policies during function execution
- Policy-as-code frameworks that define and enforce security guardrails consistently across teams and environments
Serverless Adoption: The Numbers
The survey data makes clear that serverless is no longer an emerging experiment for most enterprises—it is already in production for a majority of organizations:
- 52% of respondents said their developers are already using serverless functions to some extent.
- 44% are either evaluating serverless or planning to start using it within the next two years.
When asked why they chose serverless, respondents cited:
- Improved security – cited by 73% as the primary reason
- Agility and faster time to market – cited by 57%
- Simplicity of operations – cited by 56%
The top-ranked motivation—security—reflects a genuine advantage of serverless architectures. Because the cloud provider manages the underlying infrastructure, server patching, OS hardening, and network-level controls are handled outside the organization’s direct responsibility. There is no persistent server to compromise at the OS level.
However, reduced infrastructure responsibility does not mean reduced security responsibility. It means the security responsibility shifts to the application layer, the function’s permissions, and the APIs that functions expose and consume.
Serverless Security Threats: What to Watch For
The ESG study identified the specific threat concerns that emerge as serverless adoption grows. The top finding: API-related vulnerabilities are the number-one threat concern for 63% of respondents when it comes to serverless usage.
This is not surprising given how serverless architectures work. Functions are stateless, event-driven units of code that are typically triggered by HTTP requests via API gateways, queue messages, or storage events. APIs are the connective tissue of any serverless application. A misconfigured or poorly authenticated API endpoint effectively becomes an open door to your function execution environment.
Key Serverless-Specific Threats
- API abuse and injection: Attackers probe poorly secured API gateways to trigger unauthorized function execution, pass malicious payloads, or extract data from downstream services the function connects to.
- Over-privileged function roles: Serverless functions that have been granted IAM roles or permissions far beyond what they need to operate create significant lateral movement risk. If an attacker can execute a function with broad permissions, they can access storage buckets, databases, or other services across the account.
- Event injection: Because functions can be triggered by a wide range of event sources—S3 uploads, SNS messages, DynamoDB streams—attackers who can inject malicious content into those event sources may be able to influence function behavior.
- Dependency vulnerabilities: Serverless functions still use third-party libraries and packages. A vulnerable dependency in a function’s deployment package carries the same risk as in any other application context.
- Insufficient logging and observability: Short-lived, ephemeral function execution can make forensic investigation after an incident significantly more difficult than in traditional server environments.
Old Attack Vectors, New Environment
Cahill made an important observation about the nature of serverless threats: the attack methods themselves are not new. “Even though we are talking about something new,” he said, referring to serverless, “the attack vectors and methods are old methods applied to a new technology.”
A concrete example is privilege abuse. An attacker who gains access to a privileged account—through credential theft, phishing, or leaked API keys—can invoke serverless functions and use those functions to access whatever resources the associated IAM role permits. The attacker does not need to compromise infrastructure. They just need credentials and an API endpoint.
The defense is equally familiar: implement a least-privilege model. Each serverless function should be assigned an IAM role that grants it only the exact permissions required for its legitimate purpose—nothing more. Regular audits of function permissions are essential, particularly as application logic evolves and functions accumulate permissions that were once needed but no longer are.
Practical Security Controls for Serverless Environments
Based on the study’s findings and well-established serverless security guidance, organizations should consider the following controls as they scale serverless workloads:
- API discovery and inventory: Maintain an up-to-date inventory of all APIs your serverless functions expose or consume. You cannot secure what you cannot see.
- API usage inspection: Monitor API calls for anomalous patterns—unexpected callers, unusual invocation rates, or requests from unfamiliar geographic regions.
- Runtime controls: Use runtime security tooling that can observe function behavior during execution and alert on or block activity that deviates from a known-good baseline.
- Least-privilege IAM: Define fine-grained execution roles per function. Avoid shared roles across multiple functions with different data access requirements.
- Secrets management: Never hardcode API keys, database credentials, or tokens in function code or environment variables in plaintext. Use a secrets manager service.
- Dependency scanning: Scan function deployment packages for known-vulnerable libraries as part of your CI/CD pipeline.
- Centralized logging and tracing: Aggregate logs from your function invocations, API gateway, and downstream service calls into a centralized SIEM or observability platform to support incident investigation.
Key Takeaways
Serverless computing offers genuine security advantages over traditional server-based architectures, particularly by offloading OS and infrastructure management to the cloud provider. But those advantages can quickly erode if organizations do not adapt their security programs to address the threat model that serverless introduces.
The ESG survey data shows that most organizations recognize they need to close the DevSecOps coverage gap and understand that automation is the only realistic path to doing so at scale. The two-year outlook—with 68% of organizations targeting 75% or more coverage of cloud-native apps with DevSecOps practices—suggests that security as code is moving from aspiration to execution plan across the enterprise.
The organizations that will navigate this transition most successfully are those that treat serverless security not as a new discipline to be figured out from scratch, but as a familiar set of principles—least privilege, API security, secrets management, dependency hygiene—applied rigorously in a new execution context.