 All right. For the last talk of the day, it's all about detecting security issues as fast as you make them. Please welcome Pavel Bansky. Thank you. Thank you for staying so long. So my talk, as I said, is about detecting security issues ideally as fast as possible. It's pretty much, so who am I? Who am I? I work for Microsoft. I'm working mostly on static analysis tools most of the time. I'm also avid motorcyclist, so if you want to talk something about them and computers, you can do it. Attending to work on since 2012, however, this is my first time talking here. So speaking of static analysis, what's the problem with static analysis and finding issues in your code? We usually run the static analysis at the end of the development cycle. So all the issues we found, we find them in a bulk at the end of the game, and often there's no time to triage it, or if you triage them, there's no time to fix it. So things get postponed and the fixes get postponed, and everybody's praying that nobody else is going to find those issues. So what would be the better way to do it is if it worked like this, like you make a mistake and you know right away that you made it as you type in your code. So think about it as a static analysis, as an intelligence. So you're working your IDE, you're writing your code and as soon as you make some potential security misstep or issue, you're going to be notified. That's how our team come up with the idea to build this open-source tool called DevSkim. It's an open-source intelligence extension for IDEs like Visual Studio, VS Code, which is a Microsoft multi-platform editor, and also Sublime. It gives immediate squiggly line feedback just like IntelliSense whenever you introduce something that it's considered insecure or potentially threatening. It provides, although for both information about the issue, as you will see in the demo, so not just the squiggly line, but it also give you feedback on where exactly the problem is, not where, of course, where, but what the problem is and how to fix it. It also recommends the fixes and fixes the code if you choose to do so. So I skipped the demo, hopefully, the screen will still work and it's not working, of course. Okay. I will be typing like this. Sorry for the technicalities. We'll try and then I'm going to have to type on the big screen. Ah, here we go. No, you don't. I don't see it here. Oh, well. I will do my best. Can you see the text? Is it big enough? Perfect. So right here, I should have some C++ code. So let's say I type string cat destination, I got the squiggly line and I know there's something wrong. So string cat is considered band API according to Microsoft SDL. You get some information what's wrong. You get a little bit more info on how to fix it. We also have these GitHub pages where you can see more information. What's interesting that you can go and click on this light bulb and replace it with one of the recommended fixes, in this case, string cat S. And the code is automatically fixed to secure version of the API. This argument is, of course, could be resolved. So you have to put some constant or size up or something like that. Sometimes what can happen is that you have code like this, which is, of course, not ideal either. But you want to keep it for some reason, because maybe the secure version of the API isn't available yet for your project or for the platform you're working on. And so you can choose to postpone the issue. And then you still see what the issue was and the date until it's been postponed. That's, again, maybe you're waiting for the secure version of the API to be released, but you don't want to lose the track of the issue being your code. So once this date is expired, the code, the problem is reintroduced back again. So similarly, we have a few script to JavaScript code. No, that's not it. Yeah. So for issues like timeout in JavaScript or Eval, it's another set of API's that might not be necessarily insecure on its own, but oftentimes are insecure, because you can have a code that could be injected. And so what you can do is, in here, you can just say, reviewed. And now we can see that I was looking at the code and I reviewed that issue, which still is marked. And you know who reviewed that issue. So basically that's what the code reviewers to go over the code and see, yes, the set timeout or Eval is something that can be potentially threatening. But review this particular line, we know about it. And so you put the mark in your code. I can show you how it looks in Visual Studio. I think it's acting very same. So if you do var and say md5, then immediately have the same, this is a little bit more colorful, a little bit more UI friendly. And you can choose whatever you want to do about the problem. We also, not just looking at the APIs itself, we also look into, for example, comments. So whenever you have a comment like this, we again flag it for you to tell you, hey, this is something that we potentially sometimes leads to a problem. Someone forgets something in the code. Maybe we're looking at it. There's a bunch of other things like that. We look at, for example, we try to learn from all the comments we found in the source code and that typically may lead to some insecurities later on. Also, some people complain that it can be too noisy and gets too much information, especially on these low level issues like the comments. So you can always go to the settings and change the severity of the, you want to be reported about. There's one thing to point out is the rules, default or custom, I will be talking about it a little bit later. But basically, we provide a set of rules for security detection algorithms, so to speak, that comes with the tools. But you can also write your own if you have some specific needs for your particular framework or language you are using. You can point Visual Studio to your custom folder with your custom rules. So I'll go back to presentation. So how does it work internally? It's pretty much based on regular expressions right now. But this is the preview version, but the public version that it's coming pretty much very soon is already has some really more advanced detection algorithms, not just the rejects. We can just do a little bit more. All is written in C-Sharp and .NET for Visual Studio. We also have a standalone NuGet DLL. So you can just integrate this tool into your own project or your static analysis tool. For VS Code and Sublime, we have JavaScript and Python engines, but those are integrated with the plug-in. So you can still, the source is out there, so you can still take it out and use it for yourself. But it's not exposed, like in a C-Sharp or .NET version, where the whole API is exposed. In terms of languages, we support many, however, the strongest, the richest amount of rules we have for C, C++, JavaScript, and the usual suspect. We also understand files like WebConfig for those who work in ASP.NET or package JSON. Again, that sometimes can contain vulnerable versions of libraries, so we can flag those as well. This is example of the rule file. As you can see, it's JSON. It describes all the textual information, what issue it is, how to fix it, what this rule applies to, which language is C, C++, Objective-C. Here is the regex pattern we are looking for, what scope is in if it's in the code or comments. The underscore comment, just commenting for the particular block. And this is for the fix-it. So as you can see, as you saw in the demo, we offer some options for you to fix the code. So this is the description of it. And so contribution. It's all open source under MIT license. We are always looking for more rules and more languages. So if you have some knowledge of Go or other language that we don't support currently or frameworks, sometimes .NET Core or some ASP.NET or PHP frameworks that could have some potential security issues or known security issues that we should be able to detect and please contribute those informations. Also, we're looking to extend dev scheme to more IDEs. So again, just either shoot us an issue on GitHub. Let us know what is your favorite IDE, whether it's NetBeans or you name it. So we can prioritize which one we should focus more. Or ideally, if you can contribute your own extension, it will be even better. And that's pretty much all from me. So here are the links. Here are the links if you want to contribute or download. And I'm open for questions. If there's no questions, then I'll see you at the closing remarks. Oh, sorry, that was a question. We are looking at things like we try to understand the code a little bit better. So for example, one of the things if you flag is use of HTTP. But the problem with HTTP is that if you have XML file and you have the XML namespace, it also comes HTTP. So we don't want to flag that. So if it's the header of XML file, we don't flag it. Same thing for PHP. If you use the dollar, try to get the arguments right away, we're going to flag it. But if you have them sanitized, then we won't flag that. So we try to understand a little bit more about what's after or before your code before we flag the issue. So that's kind of what we are doing. We have a lot of questions regarding why we're not using Roslin and other technologies like that. The reason is that Roslin is right now tight only to, right now, it's probably will be always like that to manage languages. So for things like CC++ or Python, it would just not work. That's why we choose the regex approach. And also we try to, it's always, we want to be fast because it's part of the IDE and also reasonably effective. And so it's always a trade-off. So we cannot detect, we don't have the understanding of the flow as the other static analysis tools have. But we try to be fast. So that's the limitation. There are ways, I think we could do that. But again, we try to cover, the idea is that we have more engines and the same set of rules. And it's hard to interpret the same set of rules on, if you have, sometimes you can have the more information, like the whole tree of the code. And sometimes you just have the full text search available. And while we're trying to be in as many platforms or many IDs as possible, then, yeah, we are kind of limited with the scope of just the full text search, pretty much. Yes. Yes. Yes, we have, yeah, we get that comment a lot that people are like, I don't want this to touch my source code. And so what you can do, you can turn off the specific issue in the config file, for example. So you can say, hey, I don't want to see this issue, because for some reason, maybe we are using MD5 for some big compatibility reasons. So instead of putting comment on every line like that, you can disable that particular rule for your project. So you can do that. But then you are losing the track of the issue, right? Because if you have it always turned off, then you will, again, it's, yeah, you can turn it off. You can turn it off. It's, yeah, I mean, this is not meant to replace static analysis completely. We never shoot for that. The idea was just, let's try to find out what we can while the developers are making the problematic code. So that's like, you still should use your static analysis tools at the end of the development cycle. This is just try to make it a little bit more educational for developers and also catch as much possible issues as soon as possible. So, but yeah, I agree. It's always, we have that same comment. Like, we want to, here it makes sense. Here it doesn't make sense to flag this issue. But we don't want to, yeah. It's always a trade-off. Any other, OK. OK. I never heard of it, but I definitely will write it down because that's where to look at. Do they support other, do they support IDEs like this, or is it? OK, that's perfect, yeah. Yeah, OK. I never heard of it, so I cannot, OK. Yeah, we look into it. There's different linters. Definitely, for JavaScript and others, so they do something similar. Our team in Microsoft is, we are working a lot of work with the SDL team. And so we kind of try to, yeah, we are just leveraging the knowledge of the issues that people are introducing most often in their code. And that's how this project came up, so we didn't do any market research what else is out there. But yeah, definitely a good point. I will write it down. Any other questions? All right, well, thank you very much.