Our name you. Hi, my name is Joylynn Kirui. I'm senior cloud security advocate advocate in Microsoft. And today I'll be taking you through the art of defensive programming. So a little bit of stats here. We are seeing that around 68% of companies say that their ceos demand DevOps and security teams not to do anything that's slows down the business. So this leads to around 52% of companies sacrificing cybersecurity for speed. 57% of Ops team pushing back on security best practices 44% of developers are actually not trained on coding securely. And this also comes from a result of having adopting a lot of open source code as well, because you're seeing 80% to 90% of the code in your application comes from open source. And if you don't take into consideration the amount of security vulnerabilities that is in the open source software that we are using, then we are introducing security vulnerabilities into our coding environment. So a little bit of test as well there. We are saying that we have around 570 times more developers than security researchers. In that case, it's almost impossible to have one to one equivalent in terms of pushing and evaluating security, all the code that's actually being built by developers. That's why it's quite important for us to go in and do a lot of automation as well. So other sources of security vulnerabilities that we are seeing are unchecked dependencies. And then we have also employee errors. This includes exposed access tokens and safe code patterns. One thing that I have learned from this journey as well is that in most cases, developers actually push code and they know that they're actually pushing vulnerabilities code. In most cases, they already know that there's a vulnerabilities in their code. As we had earlier, we have 570 times more developers than security researchers. And damage is usually exponentially greater when it is found in production than in development during the development lifecycle. So why do we have to shift security left? So the importance of shifting security left is because to get the developer cloud against new threat types, the answer is always to shift security left and to leverage cloud native security as well. So shifting left helps enterprises find and remediate vulnerabilities earlier and across the development lifecycle. In this case, enterprises that extend security to development reduce security instance by 80%. And this is not just a reduction event. There's also a financial component. It costs 60 times more to fix a security defect in production than in development. So blending security and development together within the development workflow remains a challenge for many enterprises. So while more enterprises are starting their transformations, there are still 62% of enterprises that have yet to integrate security into the development phase. So let's dive into how security fits into the development lifecycle. So each stage of the development lifecycle has unique security components that when used together help prevent threats at all critical junction. So for the commit stage, it's important to start with a focus on threat modeling and understanding the threat landscape to grasp the overall risk of what you are looking to bring to execution in code. So in the thought of having defensive programming, the first component is usually that's very important, especially during the commit is doing threat modeling. It's trying to evaluate and see, okay, what threat vectors can be used by a hacker to compromise your system during the design stage. So at least you can scope out and say okay, so these are the areas, these are the endpoints that would be public facing and these are the threats that would be faced in this API that's actually publicly exposed. And then you can be able to now think of ways of defending against those threat vectors from being exploited. So you need to employ a range of IDE security plugins as well and pre commit hooks to make sure that the code you're generating adheres to security standards. So during the pre commit stage, you also have to make sure that you have secure coding standards in place for your organization that your developers are adhering to. So I'll give a brief about some of the secure coding standards that should be adhered to in a defensive programming environment. On basis this ten would be equated for an environment for any developer where we are always talking about input validation. Make sure that you never trust what a user is inputting. That's why we're looking at checking the data length, validating the character sets, using restrictions as well. Another security coding standard that we have to make sure that we are checking is managing authentication and passwords. We are making sure that least you're using TLS client authentication, you're using the correct authentication and authorizations as well, and you're not transmitting passwords in the clear, you're making sure that you're transmitting passwords securely. So this is a key concept that should be followed by all developers in terms of managing authentication and passwords. And for passwords, make sure that you're using a secure vault like Azure key vault to store your credentials as well. So a third security best practice that you can follow is to make sure that you're always sanitizing your data fast, and then you send that input to other systems as well. So you can use a whitelist to allow a particular data is actually allowed, or a blacklist, or you can use escape inputs to keep things safe as well. Another concept that you should follow for secure coding is adopting the principle of least privilege. If someone should not have access to something, they should not only have access to what they are required to have. So this is where we need to validate permissions as much as possible. Another concept for secure coding that we have to follow in the art of defensive programming is to make sure that you have an architecture in place where you have to make sure that you're using secure architecture. We have several like the OWaSp secure architecture practice that are available for you to view. So you need to make sure that for every organization you have secure architecture and design that all developers follow. The 6th that I would say is to deny access by default for all systems. These are talking about zero trust in almost all levels of your infrastructure as well. And we also have to make sure that we are keeping that you have very many layers of defense. So this is where we're talking about adding several layers of protecting your application, protecting your data, protecting your APIs, protecting your containers, making it very hard for hackers to actually compromise your system in terms of also natural segregation, in terms of the kind of environment that you are building, that the developers are building is also secure. Another concept for secure coding that we have to follow is make sure that you secure the kind of environment and working communication that you have. So you have to make sure that you're using strong encryption. You protect your databases as well. We make sure that you sign your code before releasing it. And another one that we have to follow is to check the quality of your code and follow coding standards. We have to make sure that you have a good peer review of your code before pushing that code, before you commit the code as well. So this is quite an important concept in terms of defensive programming, whereby you take into account threat modeling, IDE security plugin, precommit hooks, security coding standards, peer review as well. So for today, we are actually going to go through a way of you as a developer integrating Codeql as an IDE security plugin and identifying security vulnerabilities on the go. Another key concept that we follow is running static and dynamic analysis. So another aspect of securing the developer workflow is through assessing our own created code. So one of the ways to check our code is with static and dynamic analysis. So it is best to use a combination of these techniques to make sure that the findings are prioritized in the right way. So static analysis examines the code base and finds potential vulnerabilities that may be present in the code being created. And dynamic analysis reviews running code and runs simulated attacks on the code base itself. So that's why we talk about SAS as well as DAS. And I'm sure we have several other sessions that are covering on SAS and DAs. But for today our main area of focus will be on code scanning using CodeqL. CodeqL allows your team to treat code as data and it enables them to create their own queries in addition to the standard community powered queries. For today we are going to see how we can be able to use the community powered security queries on your code to find security vulnerabilities when you are using your IDE. We'll dive right into the demo. So I will practically show you how to use CodeQL on your ide to identify security vulnerabilities using the community built queries for security, which I will just show you here. So you can see we have all these security cwas and they're named coding to the particular ids. So you can go in and query any of these available queries against your code base to see if it's actually vulnerable. So CodeqL is an open source static application security tool. It allows users to also write queries to find bugs not only for security vulnerabilities, but also any kind of bug from their source code. So how do you get started with CodeQL? So when you are in your ide you can go to your extensions, go to your marketplace extensions and search for CodeQL and make sure that you install the plugin. In my case it's already installed, but it's as simple as that. Going into the extensions marketplace and making sure that you have the extension installed. And then the thing with CodeQL, it analyzes your code in terms of a database. So you need to generate a database for your code. So the way I usually do it is through since I'm using Windows operating system here you can go to GitHub and then there is a folder that is zipped for CodeQl which you can extract for your windows, for your Linux, for your macOS as well. And once you extract them, you can be able to add them to path and make sure that you are able to run CodeQL CLI from your machine. So once you're able to run CodeQL CLI, you just clone the code that you want to review or to research on. It might be from GitHub as well. And then what you do, you build a database for that particular project. So you run a code like CodeQL database create, and then you give it a database name and you specify the language of that particular project that you're using. So in this example, if we are using Java, so it will be CodeQL database create. Then you give it like Webgood language Java. So it will take a bit of time just for it to build a database. And then once it creates a compressed file like it's database, what you do, you come back to your visual studio. There will be this extension for CodeQL. You come there and then you add a database. You add the database here. So I had already added this particular database. We've already mentioned before that CodeQL will analyze your code in terms of database. So if you're running like marketing application that's based on Java, so what CodeQL will do, it will wrap that up and present it in terms of a database. So you add it here under databases. And then what you do, because you want to use the community built queries, you go to GitHub repo and then you use that code already. You clone that into your visual studio and then you can be able to run all those queries that are already built from the community against your code. Remember, in this case, your code is in quotes database. So in this particular instance, what I wanted to run against my code was to check for cross site scripting vulnerabilities. What happens is I had this open already. So you will find that you have this particular file, this particular query for SQL injection that's already available, but also have all these other queries that check for particular common weakness enumerations. So for today we will cover CWE 79. So we want to see if our code is actually vulnerable to cross site scripting. So it's as easy as going into that folder and checking for the query language for XSS. So what you do, you go to XSS query language and then you right click and run the queries in the selected files. So it will take some bit of time just to scroll through all your lines of code to check for this particular cross site scripting vulnerabilities. And then what it does, once it's finished, this is what it will give. It will give you all the lines that are actually vulnerable. So let's run that once again. So right click and say codeql run queries. So you'll give it a few minutes just for it to scroll through and see which particular lines of code is actually vulnerable. So remember, you don't have to only use this security queries, you can build your own as well. So you might be coding and then you notice that I actually did something wrong and then you want to see okay, what other code have I pushed that actually has this running or has this particular vulnerability? So as you can see here, there will be a pop up on the bottom right, just checking for running the queries. So after a few minutes the XSS query will have run through your whole code and given you the lines of code that are actually vulnerable. So as you can see here, it tells you that cross site scripting vulnerability due to a user provided value. So when you go to that particular line, it will tell you that you need to change this. So as you can see, it's very important to make sure that you're using IDE security plugins whenever you're coding to make sure you identify the security vulnerabilities as early on as possible, even before you commit your code. And as well as having secure coding standards set in place. I've seen events whereby you only have a checklist only for the developers to follow four lists to do or to adhere to whenever they're coding. But it's also important to have regular security training for the developers, as well as having security champions among the developers who will advocate for the others to take security seriously, and as well as being quite intentional about training them. Every so often in the past, what I've done is at least once a month you have all hands for developers to make sure that they are up to date with security best practices. And every so often for security champions, at least you have them on a more regular basis as well. So maybe some call to action as well. You can go to aka Ms devsecopsolutions and get to know some of the solutions that are available on Azure as well as GitHub for your complete end to end Devsecops journey. We have very many tools there available, including Microsoft Defender for DevOps, also some tools available for container security as well in terms of infrastructure as code, and a lot is available there as well. So if you want to learn around Codeql you can go to codeql GitHub.com. There are very many docs that are available. You can see ways of integrating or installing the codeQL extension by yourself, and how you can go about and querying the community security queries against your code to make sure that to find out if you're actually vulnerable. So on top of using CodeQL on your IDE, you can also use it as part of GitHub advanced security in GitHub. So this is available as well for both public and private repos. So if you have your public repo, you can go to the security tab and make sure that you have security scanning enabled and as well as dependable enabled dependency scanning enabled. So GitHub advanced security will cover your code scanning and as well as your credential scanning and as well as your dependency scanning, and it will still use CodeQL to scan for your code security vulnerabilities. That's it for the day. You can catch me on Twitter at Jolene Underscore kirui. In case you have any questions, you can link with me on LinkedIn as well using Joylynn Kirui, and I'm very happy to answer all your questions. Thank you very much.