More than 20% of open-source serverless applications contain critical security vulnerabilities, according to an audit by PureSec.
An evaluation of 1,000 open-source serverless projects revealed that 21% of them contained one or more critical vulnerabilities or misconfigurations, which could allow attackers to manipulate the application and perform various malicious actions. About 6% of the projects even had application secrets, such as application programming interface (API) keys or credentials, posted in their publicly accessible code repositories.
According to the audit, most vulnerabilities and weaknesses were caused by poor development practices, lack of serverless security education and the copying and pasting of insecure sample code into real-world projects.
"The results of PureSec's audit are jarring but not surprising, as organizations adjust to the unique challenges of serverless application security," said Ory Segal, PureSec CTO and co-founder. "The traditional models of application security and cloud workload protection solutions aren't effective for serverless architectures.”
Responsibility for the security of the serverless infrastructure, such as physical security, network security or operating system patches, falls on the serverless provider. The application owner, however, is still completely responsible for application logic, code, data and application-layer configurations, ensuring they are secure, hardened and able to withstand attacks.
The percentage of vulnerabilities discovered was consistent across runtime languages. With the choice of runtime ruled out as a factor, human error was left as the cause for the vulnerabilities. DotNet runtimes were the exception. Those projects experienced significantly higher levels of vulnerabilities.
“The core concept of functions-as-a-service (FaaS), or serverless functions, is to define an API for consumption,” explained Tim Mackey, technical evangelist for Black Duck. “These APIs can provide basic services intended for integration into a larger application. By decoupling the API from the core business logic, security paradigms which would normally apply to a discrete application at a higher level now need to be implemented in the API function.”
For example, a discrete user-facing application will often implement its input sanitization routines at the point of user input. The sanitized data is then freely manipulated within the application to return a result to the end user. If those internal data manipulation routines are broken out to become discrete API services, the input sanitization rules could easily be omitted when the API was refactored.
“The net result being unexpected data could be presented to the function – with correspondingly unexpected results,” Mackey added. “If that API function proves valuable to others, those new consumers may not be aware of the lack of input sanitization and the associated security risks.”
Also, the risk potentially exists in any API – regardless of whether it’s considered serverless, he added.
“Application owners should pay attention to any API they consume and assume that without independent validation any number of security issues may be present,” Mackey said. “In addition to the security nature of API execution, recent media coverage of data breaches also demonstrates that anyone consuming an API should be aware of how any data presented will be used and potentially stored.”