There are clear benefits to serverless technology with many enterprises already making or planning to make the change. Physical infrastructure and systems software are seemingly no longer issues that developers have to deal with, serverless applications are extremely elastic and easily scalable, and companies only have to pay for the resources they actually use.\r\n\r\nWhat\u2019s more, <a href="https:\/\/resources.whitesourcesoftware.com\/blog-whitesource\/what-risks-does-serverless-computing-pose-to-your-application-security" target="_blank" rel="noopener">as Ayala Goldstein points out<\/a>, going serverless is another example of how developers can leverage third-party services\u2014much like smart open source code usage\u2014to outsource work that isn\u2019t core to the product they are building and release to market faster.\r\n\r\nLike any paradigm shift, however, serverless technology introduces a new set of issues and application security challenges.\r\nIn this article, we\u2019ll explore how serverless can improve security, where it can introduce risks, and how it changes traditional threats. The aim here is to give you a broad understanding of the advantages and disadvantages of this technology where security is concerned.\r\n<h2>Serverless Technology: Too Good to Be True?<\/h2>\r\nWhen you\u2019re developing a product or service, you spend a great deal of time building and deploying apps\u2014and a lot of time managing the servers and resources they use, too.\r\n\r\nServerless technology, with its abstraction of operating systems, servers, and infrastructure, solves this problem, eliminating many of the issues associated with provisioning or managing physical servers. This allows developers to get on with what they do best\u2014writing code.\r\n\r\nIn a lot of ways, going serverless alleviates security concerns associated with managing your own servers and resources because you\u2019re handing over much of the responsibility to your cloud provider.\r\n\r\nThis isn\u2019t such a bad thing. In fact, it\u2019s particularly reassuring since the big names in serverless technology\u2014Amazon, Microsoft, Google, and IBM, which run popular serverless architectures AWS Lambda, Azure Functions, Google Cloud Functions, and IBM BlueMix Cloud Functions, respectively\u2014take security very seriously.\r\n\r\nBut developers are still responsible for building robust applications and making sure that application code doesn\u2019t introduce application layer vulnerabilities. Moreover, any configuration related to the application itself or to cloud services it interacts with still need to be secure\u2014again, the responsibility of the developer.\r\n\r\nIn the serverless world of Functions as a Service, the developer and the cloud provider share security responsibilities:\r\n\r\n<img class="alignnone wp-image-368 size-full" src="https:\/\/northstack.com\/wp-content\/uploads\/2018\/08\/serverless-security.png" alt="Serverless Security Model" width="714" height="631" \/>\r\n\r\nSecurity experts at Snyk highlighted this recently in an analysis of the world\u2019s top 50 breaches. They found <a href="https:\/\/snyk.io\/blog\/owasp-top-10-breaches\/" target="_blank" rel="noopener">12 of the breaches were caused by components with known vulnerabilities<\/a>. This means that application-level vulnerabilities\u2014including cross-site scripting, SQL injection and CSRF\u2014are just as bad, and attackers will just move up the stack.\r\n\r\nFurther, AWS Solutions Architect Justin Pirtle advised in a <a href="https:\/\/www.slideshare.net\/AmazonWebServices\/security-best-practices-for-serverless-applications-july-2017-aws-online-tech-talks" target="_blank" rel="noopener">presentation on security best practices for serverless applications<\/a> that application security best practices (i.e. mandatory code review, static analysis, input validation\/sanitization, SQLi) still apply in serverless architectures.\r\n\r\nPirtle\u2019s presentation is well worth a read. So, too, is Protego CTO Hillel Solow\u2019s article on the <a href="https:\/\/www.protego.io\/9-serverless-security-best-practices\/" target="_blank" rel="noopener">9 serverless security best practices<\/a> developers should adopt as part of the shift to serverless.\r\n\r\nBut let\u2019s take a look at the broader serverless security picture and how things are changing.\r\n<h2>Serverless Security: The Good, the Bad, and the Changing<\/h2>\r\nThe reduced cost and simplicity of serverless technology is not without its drawbacks. Serverless introduces a new set of challenges that should be taken into consideration.\r\n<h3>1. Provider Takes Care of Operating System Patches<\/h3>\r\nLet\u2019s start with one of the biggest advantages that\u2019s often touted by proponents of serverless: you no longer have to deal with operating system patching.\r\n\r\nSince most malware tries to compromise systems by using known vulnerabilities that operating systems have already patched, it\u2019s best practice to apply OS patches as soon as they become available and actively monitor your system for missing patches.\r\n\r\nWith serverless, gone is the time spent worrying about patching because your provider takes care of it for you.\r\nTake the recent <a href="https:\/\/meltdownattack.com\/" target="_blank" rel="noopener">Meltdown and Spectre attacks<\/a>, for example. <a href="https:\/\/www.serverlessops.io\/blog\/serverless-devops-security">As Tom McLaughlin points out<\/a>, <a href="https:\/\/aws.amazon.com\/security\/security-bulletins\/AWS-2018-013\/" target="_blank" rel="noopener">AWS Lambda customers weren\u2019t required to do anything at all<\/a> during these different attacks. AWS assumed responsibility for testing and rolling out patches.\r\n\r\nCompare this to enterprises that spent time tracking patch announcements, testing, and rolling out patches (and rolling back in some cases), and the overall cost incurred as a result of the disclosure. A month after the attacks, just <a href="https:\/\/blog.barkly.com\/meltdown-and-spectre-patching-statistics" target="_blank" rel="noopener">one-third of companies had patched over 25% of their hosts<\/a>.\r\n\r\nAccording to a <a href="https:\/\/www.verizon.com\/about\/news\/verizons-2016-data-breach-investigations-report-finds-cybercriminals-are-exploiting-human" target="_blank" rel="noopener">Verizon Data Breach Investigations Report<\/a>, known security vulnerabilities in unpatched servers and apps are the primary vector through which systems are commonly exploited. This is due to their frequency and board deployment, and the fact updating servers and apps at scale is hard.\r\n\r\nWhen you switch to serverless, you immediately solve this headache and become significantly more secure.\r\nIt's worth pointing out that <a href="https:\/\/pagely.com\/plans-pricing\/enterprise-wordpress-hosting\/">enterprise managed WordPress hosting<\/a> solutions like Pagely also take care of OS patching and actively monitoring for vulnerabilities so you don't have to.\r\n<h3>2. Denial of Service Becomes Denial of Wallet<\/h3>\r\nAnother big advantage of serverless technology is its extreme elasticity. Its immediate and seamless provisioning of functions means you can quickly scale your application to handle sudden and heavy demand.\r\n\r\nIt also means when there is no demand, you can have no servers running\u2014and pay nothing.\r\n\r\nBut this elasticity introduces a new problem: Denial of Wallet (DoW).\r\n\r\nConsider Denial of Service (DoS) attacks, which often try to take down systems with large volumes of compute or memory-intensive actions, maxing out server capacity and locking out legitimate users.\r\n\r\nWith serverless technology, you could potentially scale your way out of a DoS attack. More requests, whether they\u2019re from an attacker or a genuine user, would simply make your provider provision more ad hoc servers so good users wouldn\u2019t be impacted. However, it would cost you\u2014you would still have to pay for the extra resources, which is why this new kind of attack has been labeled DoW.\r\n\r\n<a href="https:\/\/www.infoq.com\/articles\/serverless-security" target="_blank" rel="noopener">Snyk\u2019s co-founder and CEO Guy Podjarny writes<\/a> that while serverless can help mitigate DoS, it doesn\u2019t completely eliminate it. Platforms don\u2019t really have infinite capacity and some types of DoS, like Distributed Denial of Service (DDoS), target the network bandwidth or DNS and not the application. To handle these issues, it worth considering a DDoS protection solution, such as those offered by web hosts and some cloud platforms.\r\n<h3>3. Greater Dependency On Third-Party Services<\/h3>\r\nServerless functions often include dependencies pulled in from npm (Node.js), PyPI (Phython), Maven (Java) or other relevant repositories. Depending on the language you use in your apps, it\u2019s important to keep in mind that libraries and packages are prone to security vulnerabilities, whether they are deployed manually or in a sandbox.\r\n\r\nThe nature of serverless makes managing third-party dependencies manually particularly challenging. So it\u2019s important to follow best practices in your code so as not to leave your application open to traditional vulnerabilities like DDoS attacks and SQL injection.\r\n\r\n<a href="https:\/\/www.twistlock.com\/2018\/03\/05\/serverless-changes-security-paradigm\/" target="_blank" rel="noopener">Christopher Shoe, Director of Data Operations at Ease Inc., says<\/a> static and dynamic security testing, input validation, and whitelisting should be favored whenever possible.\r\n\r\nSecuring application dependencies, <a href="https:\/\/www.protego.io\/9-serverless-security-best-practices\/" target="_blank" rel="noopener">writes Protego\u2019s Solow<\/a>, requires access to a good database and automated tools to prevent new vulnerable packages from being used and so you can be alerted about newly disclosed issues.\r\n\r\nSolow also recommends minimizing the impact of vulnerable libraries by ensuring proper segmentation of your app into disparate services, and carefully applying the principle of least privilege.\r\n\r\nUltimately, each third-party service you use is a potential point of compromise. To control this risk, <a href="https:\/\/www.infoq.com\/articles\/serverless-security" target="_blank" rel="noopener">Podjarny suggests following these steps<\/a>:\r\n<ul class="ul1">\r\n \t<li class="li1">Require a valid TLS certificate to validate the service you\u2019re using is indeed the one you think you are using<span class="Apple-converted-space">\u00a0 (not to mention actually security data in transit).<\/span><\/li>\r\n \t<li class="li1">Apply input validation on responses from third-party services. Such responses are often processed blindly, even when user input is tightly managed.<\/li>\r\n \t<li class="li1">Minimize and anonymize the data you send the service, keeping it to the information it needs to receive to properly operate.<\/li>\r\n<\/ul>\r\n<h3>4. Increased Attack Surface and Complexity<\/h3>\r\nFunctions pull data from a broad range of event sources, including HTTP APIs, cloud storage, message queues, and IoT device communications, which increases the attack surface dramatically especially when messages use protocols and complex message structures, many of which can\u2019t be inspected by web application firewalls.\r\n\r\n<a href="https:\/\/www.infoq.com\/articles\/serverless-security" target="_blank" rel="noopener">As Podjarny explains<\/a>, while functions are technically independent of each other, most are only invoked in a handful of sequences within serverless apps. As a result, many functions start assuming another function ran before them and sanitized the data in some way, i.e. functions start trusting input, thinking it\u2019s coming from a trusted source.\r\n\r\nThis is harmful for your security because:\r\n<ul class="ul1">\r\n \t<li class="li1">Functions may be invoked directly by an attacker;<\/li>\r\n \t<li class="li1">Functions may be added to a new flow, which won\u2019t sanitize the input; and<\/li>\r\n \t<li class="li1">Because an attacker may compromise one of the other functions then have easy access to another poorly defended function.<\/li>\r\n<\/ul>\r\nOn top of this, given the newness of serverless architecture, the attack surface can also be complex to understand. Many developers are yet to build enough experience with the security risks and appropriate protections required to secure serverless applications.\r\n<p class="p3"><span class="s3">To avoid being as strong as your weakest function, <a href="https:\/\/www.infoq.com\/articles\/serverless-security" target="_blank" rel="noopener">Podjarny recommends making sure you treat every function as an independent entity with a secured perimeter<\/a>.<\/span><\/p>\r\n\r\n<h3>5. Cheap and Easy Deployment Leads to Explosion of Functions<\/h3>\r\nAs I mentioned earlier, one of the benefits of serverless technology is that you don\u2019t pay for functions when they\u2019re not being used. On top of this, deploying them is fairly easy and automated.\r\n\r\nWith such low thresholds, developers tend to take a fairly casual approach to deploying new functions, even if they\u2019re not absolutely needed. The problem is, these dormant functions still exist as an attack surface and actually become more of a problem because they\u2019re less likely to be updated and patched.\r\n\r\nOver time, <a href="https:\/\/theburningmonk.com\/2017\/08\/many-faced-threats-to-serverless-security\/" target="_blank" rel="noopener">as engineer and AWS Lambda enthusiast Yan Cui writes<\/a>, these unused functions can become a hotbed for components with known vulnerabilities that attackers can exploit.\r\n\r\nDeployed functions can be hard to remove unless you track them well since it\u2019s difficult to know who maybe be relying on their existence. On top of that, excessive permissions that are also hard to reduce result in a mess of functions galore that are tough to remove and contributing to an ever-growing attack surface for hackers.\r\n\r\nThis isn\u2019t a difficult one to combat\u2014just keep in mind that each new function you deploy represents another security risk rather than a low-cost addition to your application. To avoid future problems, make sure you monitor all functions for security risk and track their deployment.\r\n<h3>6. Better Data Security Need for Stateless Servers<\/h3>\r\nDue to the ephemeral nature of serverless functions, all your functions are likely to be stateless. This means states are stored in external systems (e.g. <a href="https:\/\/aws.amazon.com\/elasticache\/" target="_blank" rel="noopener">Amazon Elasticache<\/a>) and you need to secure them both at rest and in-transit.\r\n\r\nStoring sensitive data outside the server has significant security implications. For one thing, the data is at risk when transferred. It\u2019s also likely to persist longer and be accessible to more machines. Plus, if the data store is compromised, more users will be impacted.\r\n\r\nWhile serverless isn\u2019t the only example of technology that uses external storage, it certainly increases the frequency and importance of security such data.\r\n\r\nTo combat this, <a href="https:\/\/www.infoq.com\/articles\/serverless-security" target="_blank" rel="noopener">Podjarny recommends<\/a> encrypting data stored in session stores, using short-lived caches, carefully managing who has access to these repositories, and encrypting data in transit.\r\n\r\nObviously (though it\u2019s not always obvious), keep tabs on opportunities for leaked credentials, compromised developers, or any other means for database compromise that could lead to problems for your application and users.\r\n<h2>Conclusion<\/h2>\r\nServerless technology offers enormous benefits for enterprise as we\u2019re explored above, including extreme elasticity and scalability and relatively low cost, with the biggest advantage being that it allows you to take your mind off infrastructure issues and focus on your business goals.\r\n\r\nDespite its significant adoption over the past four years and constantly growing interest, it\u2019s important to recognize serverless technology is still in its infancy. With new security challenges and changing traditional threats, stringent adherence to best practices will boost your security posture.\r\n\r\nWhile we\u2019ve covered some negative aspects in this article, don\u2019t let them scare you off serverless technology. Ultimately, its security advantages and disadvantages are comparable to other approaches, especially given the early stage of relevant security tools. It\u2019s important to understand the risks and challenges before making the switch.