In last week’s blog post we discussed how and why serverless computing could take the cloud to the next level. The advantages of serverless for development teams and commercial companies are clear: physical infrastructure and systems software are seemingly no longer issues that developers need to deal with. Serverless applications are elastic, easily scalable, promise high performance, and require companies to pay only for the resources their application actually used.
Serverless computing is another example of a great way developers can leverage third-party services to outsource most of the work that isn’t core or unique to the product they are creating. Much like smart open source code usage – efficient use of existing software components and services help developers to create innovative products that organizations can release to market before their competition, to stay ahead of the game.
Applications running on third-party servers that developers don’t need to manage? Yes, please. Is this dream too good to be true? Adopting and integrating serverless architecture into a product certainly eliminates many of the costs surrounding deployment, but – it doesn’t eliminate security concerns, or the need for application security throughout the devops lifecycle.
While a serverless architecture frees development teams from one set of problems, it does bring another set of problems to the forefront. Since serverless computing is still in its early days, it suffers from many of the issues that concern – or should be concerning organizations that choose to use third party and open source solutions to speed up the application development lifecycle.
Martin Fowler, in his article about serverless, points to two main security issues that developers and organizations should be concerned about:
#1 Larger surface for potential attacks: by using multiple vendors for serverless computing, organizations need to be aware that they are adding a variety of security implementations into their development ecosystem.
#2 Loss of the protective barrier provided by server-side applications, when organizations use a BaaS Database directly on their mobile platforms. Fowler stresses that this will require special attention when designing and developing your application.
Other experts also point to the security issues that arise when developers seemingly relinquish control when delegating server maintenance to third party vendors, especially when data hosting is involved. Lee Atchison, a senior director at analytics platform New Relic, warned in a recent interview: “Each service provides a different and unique method for offering serverless computing. This means that an IT professional who wants to take advantage of serverless computing will find they are locked into a single cloud service provider to a greater degree than if they use more standardized traditional server-based computing.”
This means that developers will need to think about what they are or are not willing to delegate to other services, and how they still track and monitor their product throughout the devops lifecycle.
Many development teams might be tempted to believe that moving to serverless computing relieves them from paying attention to traditional operational or devops considerations: no more stress around infrastructure, operating systems, network configuration, or server patching: all those tasks are the vendors’ headache now. But this is not the case: eliminating much of the infrastructure overhead simply shifts the focus of traditional devops from infrastructure management to other security concerns, like deploying functions and organizing environments.
Deployment is an area that could easily turn into a security blind spot: once the cost of deploying a function plummets, easy deployment could lead busy developers to deploy everything, an issue we encounter often with open source usage: deploying everything leads to “poor code hygiene” which increases security threats dramatically, since the security threat intensifies when it comes to open source, due to the loaded issue of open source dependencies.
As for organizing and tracking environments, no matter where the server resides, application development still requires coding, building, testing, packaging, releasing, and most certainly monitoring and tracking. Developers will still be required to consider resiliency, availability, and instrumentation.
No matter how granular an application is, or which functions developers decide to delegate to third party services, security should never be considered a concern that’s separate from the product. When relying on a third party or open source solutions in application development, the focus on security goes beyond prevention, it is yet another reason for developers to shift left their devops cycle, and automate their devops tools to continuously track and remediate any application security risks. Organizations need to double down and pay attention to detection and correction, if they want to build agile and resilient systems.