 Hi everybody. Good morning, good afternoon, good evening, wherever in the world you are and welcome to OpenJS World. My name is Justin Dolly and I'm the Chief Security Officer at Sauce Labs and I'll be joined momentarily by Christian Broman. We're here, it's a pleasure to be here and exciting to be sharing with you some of the innovations that we're working on to be able to give you and our customers more insights and a deeper understanding of your software. Why am I standing in front of you as a security professional? Well, I'm standing in front of you because I'm responsible for the security of Sauce Labs, which includes not only our company and our users and our networks, but also the platform and services that our customers use 24 hours a day. I've been leading security at public and private companies for more than 20 years, but I have something to admit to you and that is I am a tester. I've always regarded myself as a tester. If you think about it, the act of testing is a pretty big important part of any security program because it provides you with results and those results, if they are treated in the right ways, can provide deep insights to be able to allow you to make risk decisions. These signals are critically important and to date I think have been relatively speaking underserved. We aim to change that situation by providing you with security signals alongside all of the rest of the signals that we provide as you go through your current testing routines, so the quality of your software can be as good as it can possibly be. After all, security issues are just simply an outcome due to a lack of quality. It just so happens that these days the security outcome is one of the graver outcomes given our current technology landscape. And now I'd like to pass it over to Christian Broman for more information on why we do these things and to give you a little bit more detail. Christian. Thanks, Justin, and hello everyone. As a DevOps engineer, we are living by three very important mantras which are increased automation within the software development lifecycle, and therefore allow faster delivery of features and software, which is essentially shipped with high quality and therefore contains as less parts as possible. And we see that more and more responsibilities are moved towards the developer. We see that in testing we see that in DevOps. Instead of having one team that builds a feature, one that tests it and one that deploys them, the developers have moved towards a unique delivery team that develops, tests and deploys at once, and therefore takes ownership of the complete pipeline. The advantage, of course, less back and forth between teams, which means less cross-department communication, which results in faster time to delivery. It not only saves time, but also a lot of resources. Now, we see the same desire now happen in the security space, rather than having a dedicated security team auditing software, faithful at the end of the software development lifecycle, we want the majority of that work done in an automated fashion early in the development. It applies to the same shift left principle as we see in other disciplines. Now, as a developer, the question is when and how do I have to test the security of my application? As with all types of tests within security, there are various approaches for different areas within the software development lifecycle, starting from threat modeling, which is a process to identify potential threats such as structural vulnerabilities or the absence of appropriate safeguards way before the development even starts. Then we come into the SAS area, which stands for Static Application Security Testing, which is an approach similar to what we know as code linting, where you scan your code to try to discover problems, in this case, security problems. Like all linting tools, this offers fast feedback and allows to detect a lot of issues. But the value of those signals is often very low and you get a lot of false positives. Lastly, there's security testing in the infrastructure of code and as well as security monitoring and attack detection, which come with their own complexity and challenges. So, from all these stages, which one would you think is part of the developer development lifecycle, but has not really much explored when it comes to tooling? That's right. It's the dust approach. There are plenty of well-working tools in the static security analysis space from starting looking at SAS provider like SNCC or integrated tools in GitHub, for instance, the dependency management tool they have there, or SAML, which is a code analysis platform that was acquired by GitHub in 2019. This, however, is just one way of testing security. Security in general, there's no civil bullet to it. There will be never one single tool that allows you, that can guarantee you the security of your whole application. This is why there are so many stages. Dust in this area is the security end-to-end approach that, as opposed to SAS, provides much more valuable signals for us as developers to act on. Now, why is this interesting for us? We at SAS have been thinking about this over the last couple of months, and we thought that we see in this space that security testing is not really accessible to everyone. At SAS, we are running over 3 million tests every day, which is a very large number. And this gives us a huge advantage compared to any other competitors in the market because we know your application from the in and out. Based on your functional tests, we know where you log in and which credential you may use. We know the process of your checkout flow, which steps and pages are involved, and most importantly, what data is being transmitted from one form to another. All these information help us to properly analyze the application on the test to provide you insightful and meaningful signals. That said, this solution cannot only be applied on SAS Labs. It can be deployed on all running tests across all vendors or even locally. Because one of the big problems we have here in the security space in general in the security tooling space is that people have to implement scanners to understand your application. Those scanners need to be able to go through a login to access a secure area. Running functional tests already solves that problem for you by accessing that through functional commands through WebDriver or newer tools like Cypress. So with your functional tests, you can already prepare everything that you need to analyze the security of your application thoroughly. The question now becomes, what kind of tool would be ideal to build on top of an existing testing infrastructure? Sure, we could implement a new preparatory solution in our company. However, that would mean that we would need to reinvent the wheel. We at Source Steps found that a perfect fit that is also open source and can be used on top of your functional test. This tool is called ORA SAP. ORA SAP is not only open source and part of the OAS Foundation. It is trusted tools by security experts with a long development history. I think its first release was somewhere around 2010. And it has been always developed in the open since then. And there are also some very interesting similarity to WebDriver, which is a protocol that is driving functional tests from the beginning with. Which is, it's built with an API first in mind. This means that you can, that all interactions with the application, with the tool is abstracted into API endpoints. That means that you can deploy that tool similar to deploy a driver anywhere in the cloud and operate to it through API plans. The way SAP works is that you can use it for, for instance, calling your page to analyze what the browser is doing, to analyze what the browser is requesting and receiving during the exploration. There are two types of scanners. One is a headless approach where SAP is doing requests on your behalf and scans the HTML response and parses links and see what's, what's page just next to call. And the second one is an HX scanner, which is designed to operate on top of a browser to allow you to inspect also a single page application, which are not rendered when, not necessarily rendered when you request them from the browser. Another way to explore an application is also by using SAP as a proxy, which is a really fantastic feature here. By automating it through WebDriver using Selenium WebDriver or other tools, you can use them to write automated tests, automated functional tests to explore your application in an automated fashion. So instead of, you know, your browser making requests to the internet, it tunnels all the requests through the SAP proxy and can, and those kind of information can be later used for scanning purposes. Now, if we move SAP into the cloud and connect our functional tests with them, this can be, this can become a very powerful setup. Your functional tests can pull your application 100 times more efficient than every scanning tool would do. So that scanning vulnerabilities with SAP in the cloud can be 10 times faster because you can run them in parallel rather than executing that or scanning manually. So that eventually testing functionality and security becomes almost one single workflow. So let me show you how this workflow might look like in your company. Let me introduce you to Christine Watson. She's leading the QA team in her company. She and her team have been running a lot of functional tests in their Selenium grid that they have deployed in their CI system. And they are now getting the requirement to ensure that they also add security tests to make sure that security bugs are caught early in development. Her tests are written in Node.js. And now she wonders how, what she needs to do to fulfill these new requirements. She finds out about the capabilities that OASlap provides them. So she starts deploying OASlap in the cloud or locally and starts tunnel all the browser traffic through that application. To do that, you need to start SAP as a demon to wherever your machine runs your test. For instance, your CI server. Then you apply the appropriate proxy capabilities in your web driver setup so that the browser is started in a way that it automatically proxies the request through OASlap. The nice thing about this is that you can enable this for all browser tests. Applying proxy settings is part of the web data protocol and therefore works across all the browsers. So besides these small settings, Christine can keep running the test the same way as she did before. Now while her tests are running now and Christine is getting a coffee, which gives me some time to explain the options that you have after your functional tests are done. So many of you will have different kind of security requirements. I had conversation with folks that said, I would never fail my pipeline because of security reasons. Others said that there would be actually indeed interested doing that because they are running and testing a critical security related component in their infrastructure. What you see here that it comes ultimately down to what your team's requirements are and every team's requirements can be different. Adding security tests to your pipeline will have some implications to it. For instance, scanning for vulnerabilities will definitely add some additional time and therefore might be slowed down your pipeline overall. And with that, slow down the time that you can test and deploy new features to production. However, when you run everything in the cloud, you can start analyzing and scanning for vulnerabilities while your functional tests are still running. So our goal should be to always opt in for security tests because we can run them in an efficient manner in parallel while some other checks are still being executed. And security in itself is also very difficult to describe. Security does mean different things to different people, right? Certain vulnerabilities that are critical for one person might not be for the other. And there will be, again, no service that will give you a feature or the assurance that the whole application that you provide or that you want to deploy is secure. The fact here is that by detecting and mitigating common vulnerabilities early in the software development cycle, you give your security engineer more times to focus on the difficult aspects of your overall architecture. In case of Christine's teams, their policy is to, you know, to check after every, before every deployment, how many security bugs exist in their recent tech version of their system. So if you store these up sessions that you haven't been opened during your functional tests and you put them into a cloud bucket, you can always download them at all times and access them through ZAP proxy to use them for scanning security vulnerabilities. So every functional test therefore can now store not only general logs like Selenium logs or WebDriver logs. It will now also store ZAP sessions that include a lot of data on requests and responses that the browser has been made, was making during the functional test. And Christine can trigger these scanning, these vulnerability scans completely automatically by using, by downloading the ZAP session from the bucket and using the ZAP client to trigger these security scans. ZAP as a tool comes with a lot of utilities equipped to give you a nice overview about all the vulnerabilities that are exist in your application. So if you manage this, of course, within a cloud platform, you can make this much more simpler by just having a click on a button or providing a CLI client that does everything for you. Now for the last build, Christine found 10 new vulnerabilities. Some of them are related to things like missing security headers or a secret key in one of the JavaScript files or something really simple and common. These things are really easy to fix. Christine knows her application and she knows how to fix, how to apply patches to fix those issues. However, with, she needs help with one critical bug that she has seen, that she hasn't seen before and nor anyone in the team. With the help of a geo integration that she is using, she is sending that security vulnerability to one of her security engineers working at her company. That security engineer can now download the same Zap session and can use the Zap GUI to inspect what happened during the functional test. So he downloads the session, drags and drops it into the OSAP UI and introspect all the requests and responses, finds the vulnerability and message Christine's back with all the information she needs to mitigate that problem in the future. So with that, Christine and her deaf team are happy because they have shipped the most secure application and the security engineer is happy because he made the internet a little bit safer. Now I said in the beginning that there's no silver bullet for security. Well, the closest thing that gets to it is awareness within developer and QA teams. So to sum up this little workflow example, with OSAP and functional testing using web driver and Selenium, you will be able to analyze the vulnerabilities of your application by using your functional test. With OSAP under the hood, you can create some deep analysis on the most common vulnerabilities that exist. Things like you might have heard about the OSAP 10, which is an updated list about the most common threats of today's modern application that you find on the internet. In addition to that, you can store that data and keep an historic backlog of the information or security bugs that have occurred when you have been developing on that application and learn from the mistakes that you have done in the past to mitigate this happening in the future. Now, while this talk really doesn't provide you any step-by-step guide to install or deploy this in your application, I hope it inspires you to that with just open source and open standards, you can deploy such a system in your organization. We feel like with this approach, you can make security really accessible to everyone and test it early in the development lifecycle. And again, every organization does this differently. We at Source, we have a lot of ideas how testing security and testing the security of your application can look like. And we are interested to talk. So reach out to us. And with that, I want to give it back to Justin for the closing remarks. Thank you so much, Christian. It's very, very informative and very interesting. I think Christian's point is a great one. I can tell you having been in security for such a long time that the silver bullet that Christian's referring to about just the simple awareness and a little bit of education inside of the areas of our companies where the development occurs and where the ideas are spawning, from where the ideas are spawning, is really the silver bullet, is that we're actually aware of some of the choices that we're making and some of the security implications to those choices. I think with everything else, one of the promises of open source in particular and the open source standards is that we can all adopt them and adopt them quickly and they're flexible enough to be able to support our businesses. And any other initiatives we have non-commercial, maybe non-commercial in nature, but this is truly one of those opportunities where a rising tide lifts all boats. That, you know, by leveraging these standards and these initiatives that we can increase the general security across the board of applications and websites and platforms and so on that are attached to the internet, protecting all users of those platforms and those sites. So it truly is incredibly valuable and I would encourage you to investigate these things and see if they fit for you and your organization. And with that, I'd like to thank you all very, very much for your attention. Thanks to Christian for the expertise and the details and we hope you continue to enjoy the rest of the content at this wonderful conference at OpenJS World. Thank you. Thank you all. See you.