| title | description | date | thumbnail | layout | authors | |
|---|---|---|---|---|---|---|
Introducing the Serverless Snyk Plugin |
Using Serverless is a boon for security, as it greatly reduces the risk of unpatched servers. In this environment, vulnerable open source packages become the primary security risk. The new Serverless Snyk plugin addresses this issue. |
2016-11-03 |
Post |
|
Serverless is a powerful new approach that enables developers to focus on building features instead of having to focus on the underlying architecture. From a security perspective, it takes away a significant source of security risks - mismanaged servers. However,
While the servers still exist, using Serverless means they are now managed by the platform provider (e.g. AWS). These providers can afford to spend far more effort and manpower on managing these servers, and are therefore less likely to have unpatched servers, leave opened ports or use a root user to run apps.
Handling server management better, and notably patching vulnerable binaries on the servers, is a very significant security boost. Most sucessful exploits in the wild are caused by such unpatched vulnerabilities. In fact, Symantec estimates that "Through 2020, 99% of vulnerabilities exploited will continue to be ones known by security and IT professionals for at least one year".
In other words, moving to Serverless can help your security posture substantially, but it doesn't fix everything.
Since you no longer manage servers, the security threats in a Serverless focus on three areas: network, third party services and third party code.
On the network front, the risks relate to who can access your systems, as well as who can see or tamper with your data.
Access is controlled through proper VPC controls, as well as using secrets to authenticate between services. Rafal Gancarz and Ben Kehoe provided great examples of how they've implemented those controls at the latest ServerlessConf London.
Anti-tampering is achieved primarily by using HTTPS. While being on the same VPC contains access, any extended use of serverless is bound to start spanning multiple VPCs if not multiple clouds, exposing internal communication. Investing in using HTTPS between services, likelyk using free certificates from Let's Encrypt, dramatically reduces the risk of wire tapping or tampering.
Since Serverless implies stateless, such applications rely heavily on surrounding services to provide DNS, storage, monitoring and many other capabilities. Increased use of services means increased exposure to security flaws in those systems, which may translate to vulnerabilities in your own system.
The first step in reducing this risk is awareness. Consider the services you use, and assess their security posture. This doesn't mean you shuldn't use startup services or services that aren't widely used, but it may change how you approach them. The more you trust their security, the less effort you'll need to put into ensuring your application remains safe even if the service is compromised.
The second step is to try and protect your systems from a compromised or malicious service. If your DB server is compromised (or the communication to it is), would that compromise your data as well? Would communication from that service now be able to take down your servers or run code on it? As mentioned above, this type of thinking is especially important when dealing with less tried and true services.
Lastly, the biggest security risk remains your own application and the code within it. As in any other architecture, vulnerabilities in your own code can get your system compromised. However, the risk of attack is far greater in open source code packages you consume.
The remainder of the post explains how to deal with this risk, using the newly launched Serverless Snyk plugin!
Open source software is increasingly consumed in the form of packaged code dependencies downloaded from repositories, such as npm, RubyGems, Maven, etc. The use of these packages continues to grow, and already the majority of code deployed in your app is most likey open source.
The Snyk team approached serverless security with the following premises: The security vulnerabilities in these open source packages are typically known, and logged as GitHub issues. Many of these open source packages are downloaded millions of time each month, making exploits of their vulnerabilities highly reusable. Further, tracking these packages is difficult considering that any developer can add a dependency that includes lots of other indirect dependencies along with their security flaws.
The new Serverless Snyk plugin was created to address these issues allowing you to ship securely and focus on building your app.
The Serverless Snyk plugin helps to prevent vulnerable packages in your Serverless application, using Snyk.io. It does this by focusing on four stages: find, fix, prevent and respond.
With the Serverless Snyk plugin installed, each time you deploy the plugin will scan your dependencies and test them against Snyk's open-source vulnerability database. Serverless Snyk can either stop the deploy at this point (the default behavior), enabling you to address the issues, or continue on, simply noting the vulnerabilities for you to return to.
With Snyk GitHub integration a PR can be submitted to your repository with any updates or patches needed to secure your application. You can also fix the issues by installing and running snyk wizard locally. In either case, Snyk will create a .snyk policy file to help guide future Snyk commands. If the Serverless Snyk plugin sees that you have a policy file in place before your application is deployed it will apply any of the updates and patches you have specified by running snyk protect.
Security is a continous process. As your application continues to evolve the dependencies it uses may change. Snyk runs everytime you deploy to help identify and preemptively fix any new vulnerabilities.
You're given an API token when you sign up for Snyk. By including the API token in your Serverless project (using a .env file to ensure it's not mistakenly published), the Serverless Snyk plugin will take a snapshot of the current state of your dependencies and save it to your account. Whenever a new vulnerability is released that impacts your application, Snyk will notify you, and anyone else in your Snyk organization, by email or Slack so you can address the issue right away.
With the Serverless Snyk plugin in place, you can now let everyone know about your newly improved level of security by including a badge in your repository. Here's what the badge looks like right now for the Serverless Snyk plugin itself:
You can find more information about how to include the badge for your GitHub repository in the Snyk documentation.
Serverless is gaining momentum as an approach that enables developers to focus on building features instead of focusing on the underlying architecture. From a security standpoint, it reduces security issues due to unpatched servers. When paired with the new Serverless Snyk plugin, you can ensure your dependencies will also be secure — automating security so that you can focus on building your application.