 Welcome everyone. This is Jenkins, the Jenkins online meetup and let's take a look and get started. We're delighted today to present a single open source security scanner for most languages on Jenkins with Luke O'Malley. We're pleased that you're here. Thanks for joining us. I would remind you that Jenkins online meetups are community driven virtual meetups. They are intentionally focused on Jenkins but anything about Jenkins they can be case studies they could be success stories they could be things you learned or experience that you would be willing to share with others. We are intentionally looking for speakers who are willing to be voice and present and share their experiences with Jenkins. You can help to us through the advocacy and outreach special interest group on Gitter at this URL. If you would be interested in being a speaker at a Jenkins online meetup. We're very grateful to Luke today that he's willing to present to us grateful for what we're going to learn from this and excited to be here for questions and answers. We encourage you to ask your questions through the zoom question and answer facility or through zoom chat. We'll collect those questions, invite you to gather them together and as we find them will ask questions to Luke and let him answer. Then, after the official recorded portion of this meeting, we will stop the recording and allow everyone to become voice so that we can ask each other questions off the record. We remind you that Jenkins has a code of conduct and we expect that everyone will comply with that code of conduct. We're kind to each other we're good and decent. And we look forward to this presentation by Luke. So this is static analysis and Luke's going to share with us his experiences working with Sembrep and Luke, let's go ahead. Awesome. Thank you so much for the introduction mark and hello everybody. Let me just go ahead and get screen sharing here. And can you confirm that you can see my screen that that is can I can see it just great. Thank you. Fantastic. Well, awesome. Really, really happy to be here. And if you have questions, please feel free to throw them in the chat. It is much more fun to do zoom presentation that is interactive than one that is not. So just quick background. My name is Luke. I'm the head of product and one of the co founders at R2C, which is a software security company based out of San Francisco. So obviously with COVID, what does it mean to be based out of a particular city anymore, but for the most part, we're in San Francisco. And we've got about 20 folks who are working on tools like Sembrep. So today, my plan was to talk about a static analysis tool, which is basically a tool that is used to scan source code and find bugs. And it is a tool that is works across many languages and works across many environments. So if you want to run it in a Jenkins environment during build time. Fantastic. If you want to run this locally. It works locally on Linux based system so Mac Linux Windows subsystem for Linux, things like that. I'm going to show you basically what is Sembrep, what it does well, and then how to actually set it up and run it in Jenkins. So, just at a high level. And I'm curious in the in the chat, who has interacted with or encountered a static analysis tool before is that a new term for folks. I see mark I can see mark on the video raising his hands. So just a quick background static analysis is a field that has been around for a long time. Very simply, the static part means that you take source code, you just take source code files, and you basically look at them, and you try to determine what they do without running. So, just like reading reading source code source code comes in and kind of conclusions about that code comes out but you haven't run it on any kind of system you haven't necessarily compiled it. So that's at a high level with static analysis is and what we're doing with Sembrep is providing a tool that is open source works on many languages so we're up to about 17 languages now and there's more coming every day I'll talk about what those specific languages are. And kind of in the spirit of open source, you know, I think we found that there have been other efforts before us that have kind of either proprietary rules, or maybe like closed ecosystems. And so for some grip there actually is a community registry, anyone can contribute to the registry so you can publish your rules are kind of like your packages to it. And there's so far 1000 plus rules across all the languages that we support. And I think what what folks will see if you take a look, they generally get broken up by language so there's like Python rules you know go lang rules. And there's also rules for specific frameworks. So let's say you're doing in Python Django web app development. There's rules for something like that. And then sometimes there's just things that are more like a topical so cross site scripting is something that security professionals tend to care about. So you can find rules with that. So really, really active community, particularly on slack actually. So folks are interested in getting involved. There's a an active community on slack. It's really fantastic that there are so many rules that are available already. But everyone's environment and code base and company is a little bit different. And so we have focused as a as a project on making it really easy to write rules and so you write rules that look like the code you're trying to match. And so I'll show you what that looks like but you don't have to learn any kind of complicated, you know, domain specific language. And I mentioned this a little bit earlier but it's important that it run everywhere. And so for our project, you can run it in your terminal you can run it in the editor, you can run it in Jenkins. So it's a highly portable tool. And the last piece that I want to mention, this will be relevant I think for all those who are adding some rep to maybe a Jenkins build system is that you can set it up so that it only flags new issues moving forward. And I think, kind of our, our observation our experiences we set up tooling on our projects is that you have really good intentions you want to set up some kind of code scanning. So really, really good intentions and then you're punished by the tool because you have existing violations. And so you can't get your green check mark on your build. And we all know that we love our green check marks up and down so there is a possibility to make it kind of looking forward. So you can start to improve the quality of your project. And I mentioned this already just want to give you a sense of kind of where people use the tool so it is something that you can use locally. I mean, you can brew install it, pip install it. If you use Docker, there's a Docker image that's published. So there's a couple different ways to consume it or get it running. And then, once you have it installed. There's a pretty healthy set of flags that you can pass this command line tool. But the main one that folks use is this dash config flag. And that lets you actually specify things from the registry. So if you there's a rule that you see on the registry you like or collection of rules. You can just do dash dash config it for you downloads the rules from the registry and then runs them on your, your source code. So pretty straightforward to use, use there. And I promise you that it was an open source project so I just wanted to show you a couple stats. It's LG PL to license for those of you at companies that maybe licensing has to be very particular for the tools that you use. We have a growing number of contributors. So if you write Python or you want to learn O camel. There's some really good opportunities there. So we release very frequently. So, since the project's inception and we've had 95 releases we release every one to two weeks. You know, bug fixes improvements new languages and things like that. So there's a really fast cadence, and the project is getting better, better every day. So just to kind of round out. Hey, so there's this tool, it scans code. It very likely runs on your system and the place that you need it to run. It's portable kind of does it actually work for the languages that my organization is developing in. So I'm mostly showing here languages that we call generally available. And so these are ones that the community spent a lot of time to harden. And we mostly look at parse rate so how much code are we able to successfully parse in this target language. And so for these languages, we're at I think it's 99.9% parse rate across really large corpuses of open source projects. So a bunch of stats and dashboards I can show you but we've taken this really data driven approach to like what does it mean to have something that's generally available. So on that list, I mentioned kind of, we'll say modern languages so we've got go. We've had a lot of work recently in Ruby and type scripts. For those of you who are working with configuration file formats, a little bit more experimental but we have this thing called generic, which has been letting us do YAML files. So on config we actually do support JSON natively. So, kind of what this leads to is, it is one tool, it probably works for the majority of the things that, you know, your organization may encounter at least that's what I've been finding so far for the people I've been helping. And you can write rules for these languages to so if you have an idea, I'm going to show you how to do that in just a little bit. So I just want to take a quick pause, because I just went over a whole bunch of what is this tool. Are there any questions so far. So I actually had a question with regard to you said rules that look like my code. So, if I'm a C programmer, I can express rules in in C or if I'm a Python program I can program or I can express rules in Python. Yep, exactly. And I mean, I'm actually I will pull that out, because we'll do what's effectively like a copy paste is the way that all of my rules when I'm starting them. I say, Oh, this is the target code the stuff that I want to match. And I'll actually copy and paste that. And that's, that's the basis for my rule for my pattern. Excellent. Thank you. Okay, and I assume that that you'll some point maybe describe the difference between generic and your generic model and some more specific things that aggressively target YAML syntax checking but for me this one that in my language is is quite interesting and quite important. Yeah, so I and I will I will definitely touch on that and I see that there's a question that you had to about some other tools for instance the SonarCube system. I think I will touch on that a little bit later. So Manuel if you're if you're okay I will delay that question, but keep me honest and feel free to bring that up. I'm like five minutes. Awesome. So real quick, where I switched over to I just went to the SAMGREP website. It got a facelift yesterday so if you've been on this previously we had a different logo for the project different website. And late last night it got updated. So I'm just on the website and a lot of the presentation that I'm giving I've actually pulled from the website so you'll see some some similar content. So what I'm going to draw your attention to, and this is kind of in the vein of making it easier to write rules is that we have a thing that we call the playground. And so I'm just going to click over to that. And the playground is effectively a online kind of we call it the editor or rule editor. So as you're experimenting with rules, you can do that here. So you don't have to run things locally. And maybe most powerfully, the thing that I use it the most for is that I can share rules. So if I write something, I can get a URL to send to somebody else to say hey I have this cool new thing. What do you think. And what's very cool is that SAMGREP the command line tool actually understands these URLs. So if you write a rule in the editor and that's where you're doing your development with there's some nice debugging niceties and things, you can then run it locally to actually see hey with this have caught the bug that I'm trying to catch. So there's some really, really cool stuff there. So what I wanted to show you is I've got a little bit of Python code. And I promise you that rules look like the code you're trying to match. So really, I want to say like trivial use case here is that a print statement makes it into a production environment. And this is actually a rule that we run. We don't want print statements we want to use our logging framework. So how do we prevent print statements from making it in. So I want to show you what it looks like to just try to match this. And what I'm going to do is I'm just going to start by copying and then pasting the segment of code that I want to match. So in this as is, I'll get a basically identical match right so what I copied matches this line. But that is probably it's only useful if someone exactly types out my debugging sky net and it vector a statement. What if I don't care about what's within the print statement. And this is where I'm going to start to draw a bunch of analogies to grep. I have the ability to just like enter in a wild card and say hey I don't care about the stuff that's in between my two parentheses. And so I'm just going to do this dot dot dot, which is equivalent to like a dot star and regex kind of wild card. And that will then match any print statement that has one or more arguments in it. Actually it's zero or more arguments. And that generalizes the rule. So this is what most rules snippets are kind of rule snippets will look like any kind of questions there I just wanted to quickly show you and I'll talk about how this works and why it's not actually text matching and all that kind of cool tech behind it. But hopefully you have a sense of what what a rule would look like. And what it's doing. Luke, you said it's not actually doing regex so it's not as simple as a as a pattern match there's much more going on here. There is a lot yeah there's a lot more going on here, and that is actually a great segue into how it works. So, I'm curious for the group who has used regex to write a basic a code rule or try to find coding issues. It's something that we had done a lot on on the team. And turns out that actually grep is maybe one of the greatest static now still out there. And that's some problems. And the problem is that strings and string searching is not equivalent to what source code actually looks like or how the computer undersigned source code which is as a treat. And so the way that I think about some grip is that it's basically grep but for trees. So that little snippet that I showed you, you know we're not doing a string search on it. That little snippet is going to get turned into basically a tree matcher. And it's going to go look through your source code and navigate that tree and find you know nodes and expressions that match. And some grip, I guess as a term is meant to mean semantic rep. And so it's a tool that is aware of the semantics of the language and the code that you're analyzing. So I can just give you a quick example of that. And that's where maybe grep would have have some trouble. So this is a JavaScript example now, and pretty classically like, you don't want to use exec, you don't want to execute, you know, arbitrary input. And so we just want to find all of the occurrences of that we want to ban it from our, our code base. So if you were to use grep, you'd actually, I think be able to get pretty far here, you know, you could write a pattern that matches the word exec, and maybe includes a left parentheses. And that's probably a pretty good indicator that there's at least a function that ends in the word exec, you know you start you're starting a function call. So you'll run into, I think pain with grep is when it comes to white space so what if someone, you know includes a space before the parentheses it turns out that that is valid, valid JavaScript. What if there are new line characters. That's going to start to be very painful and grep so your, your expression is going to get more and more complicated. What if it's not actually code, it's a comment. You don't want to flag comments because that's, that's not code. And you might actually get people just printing out or logging strings. Right. And so there's all these cases that suddenly you have to think about. Which again, if you're writing a rule for a single file, or like you're trying to grab a single file, probably good enough. But once you start trying to use that rule on many projects or thousands of projects kind of scale it up. You start to get into system pain. So I'm going to type exec here, and very similar to what I typed before I don't just for sake of demo I don't really care if there's any arguments or what comes between the brackets. And so I'll just run this. And what we'll see is that we actually correctly deal with spaces, you know new lines, we don't see the comment. And we actually know that this is a string literal and so it's not basically it's not code that's going to be executed. There's a caveat here where for I think a lot of tools, particularly in the open source domains you think of like ESLint, Bandit, and some others. Sometimes they're used for style enforcement. And so for some grip we've explicitly made this decision that we do not do style. It's not even possible to do style because we remove white space we remove comments, and we are looking at just that true representation of the code so we don't actually have that data styling data to look at. So that is just kind of a comparison to grep and skip ahead quickly. So I have a diagram that came out of Instagram so Instagram does a lot of static analysis and I'm I stole part of their diagram. So they were trying to do a comparison of where tools fall on the spectrum of, you know, easy but dumb code scanning, all the way to powerful but complex code scanning. And on the easy side, this is really where where grep is. And on the more powerful but complex side you get a lot of the proprietary kind of a more expensive options. And so for us with some graph we really wanted to sit somewhere in the middle. So it was said hey we think the opportunity kind of with with the community is that we need an easy tool, but it's smart. It's a powerful tool, but it's simple. And so we're trying to kind of make the right set of right set of trade offs. And so, Mark, this is basically the statement you had made earlier. You know, hey, you're telling me that if I if I can write see, I can write a rule and see. It's basically the case for any of the languages that we support. Thank you, thanks for the clarification. Thank you very much. Yeah, so just looking through the chat, any questions so far my, my thought, just to kind of maybe broadcast where I'm going. I want to talk a little bit about use cases that I've seen for the tool so kind of talk about capabilities. Talk about some use cases and actually wanted to show you how how my team is using some grip in a CI type of setting and the types of things that we check for. And then I was going to go on to talk about Jenkins specific configs. And from the group, are there any questions that I can answer. Well, there was a, there was a question that was asked that I attempted to answer on my own related to coverage, asking, hey, does this report coverage and my assumption was it doesn't report coverage because it's not actually executing the code. Therefore, it really couldn't report coverage. Is there a coverage kind of concept in some prep that is worth discussing I'm not sure I would know what that might be. That's, that's a great question so we don't do coverage reports right now. You know, I haven't kind of I haven't thought too much about what would technically be involved there. I think one of the interesting parts is that because it's an extensible tool, I suspect that you could kind of mix and match some grip, perhaps with this like other approaches or other coverage tools. I didn't mention this early on, but you can use some grip as a Python library as well. And so if you want to basically like natively call some grip from your own code, you can you can do that you don't have to, you know, shell out or try to build a pipeline with the Thank you. Yeah. And then I see that there's a question just on how to get started on the, the website that I was on that some grip web site. If I just click back, there is documentation. So that's a great place and there's actually a big all get started button that just takes you to. Yeah, if I click through that just takes you to the docs and very similar to what I was showing before you get started but basically installing the thing locally. And then there's some sample configs and sample patterns that you can run. And then on the secrets and API key matching. I will talk a little bit about the registry and still like towards the end of the presentation. So there are some rules that I have seen for secret matching. The key out is that they can be noisy, which I think quite a few secret tools can be. And so there's a question on who should run it if you should run it at CI time, and you know break the build, bring it to developers attention, or if those types of rules might be better for kind of like audit type scans that would go to a dedicated team like the security team. Meanwhile, I see you have a question about private private rules. So I'll show when I get to the Jenkins piece we have a basically like a wrapper around some grip. That's called some grip agent, and it understands how to pull in like local config files. And actually when you run some grip locally for the command line tool, you can pass it in. So that's an option for private organizations. And then tell me I won't talk about but there is a basic paid infrastructure on top of this and people host private rules through that paid infrastructure as well. And I see a question about so I'm going to push on I see a couple more questions. I'm going to push on because I think I will answer them over the course of the presentation. Sweet. So just some use cases because when I when I first started using some rep I didn't quite realize all the things you could do with it. So go through some of the greatest hits. A lot of folks when they're looking for static analysis tools. It's usually some kind of compliance, like there's a contractual obligation and we've got to run it. And so there's a bunch of rules for OS top 10. So I didn't really touch on this but you know if you write right rules, grep is really easy. Let's say you want to extend really any other tool that's out there, like yes lint bandit, or even some of the commercial ones. So it's not just like really hard to write rules, because you, you don't get to express the rule. Basically as code. So you have to think of like okay I see source code. What does that look like as a tree, and then you write this kind of complicated what's called like a node visitor. Right and so you start to refer to specific nodes and suddenly you have to have expertise on program analysis and programming languages. And so I think for us really the use case for most folks is that they have a rule that they want to write themselves. And it's just the simplest way of doing it. We've seen a lot of people use this to enforce code guard rails. So the idea here is that you basically ensure that people are using the correct libraries and frameworks. You're kind of default safe. And so really really nice example of this we've probably assume have all run into or heard of SQL injection at some point in our careers. Right so how do we get rid of SQL injection. Well we could try to detect, you know, that there is a user input flowing into a SQL query, or you could say hey I'm just going to use an object relational mapper. I'm going to use one of these many libraries that wrap SQL. And in doing so, you eliminate almost entirely the possibility of SQL injection, because you're actually separating out basically data from control. And so that's like the main selling point of using object relational mapper if you've in the Python world's SQL alchemy. That's a great example. What we're standing is this is actually the approach that Google took many years back, and they've never looked back since. So it's just, you choose the right frameworks you choose the right libraries, your code base will be safer. And so let's enforce that people are actually using them. If you are on the bug bounty crowd you can hunt vulnerabilities. And you can also just standardize library and API usage so deprecated API is a pretty common one. You just want to make sure that people are using the new stuff, not the old stuff. And so you can do that. And I wanted to show you how, how we're using it it's not a security example, but I'm really for us I think most of the value that we get out of some grip, and we run it, you know, it runs on every single commit at R2C. It's really around enforcement of our own, like standards. So if we have a user facing bug security performance like whatever it might be. Oftentimes, as a consequence of that bug report will write a semi graph rule to try to catch that catch or prevent that issue from happening again in the future. And so we're just kind of constantly codifying institutional knowledge. And so as new people come onto the team, you don't have to think as hard about if you're doing something correctly, because other people before you who have seen the consequences of a decision have written a semi graph rule for it. So let me just show you what that looks like. Quick pause, folks still with me still falling. Am I going too fast or is this an okay speed. Your pace is great for me. Thank you very much. Yeah, so if I'm feeling like I've got, I think there are several more questions that will arrive you keep going and we'll keep collecting questions. Thank you. Okay. So I've got the playground open again. And it's a little bit more advanced this time so I've got actual test code down below. And what I haven't mentioned yet, and I showed you these really, really simple snippets earlier in the presentation. So I just wanted to mention that you can actually combine them with a basically a Boolean logic. And this is what gives rules I want to say like, most of their power. So there's a lot of fancy program analysis happening but the fact that you can compose patterns and say the pattern must be this, you know, but not that gives you this ability to create very specific and targeted rules. So we ran into this issue where I guess some browsers as a security security feature, don't allow you to access a local storage. And we wanted to ensure that anytime we try to access local storage for our front end code. It is wrapped with a try catch so that we can gracefully gracefully fail. And this was basically causing issues for us because, you know, a few weeks would go by someone would forget about this you try to access local storage. It would work for you, you know, for other folks or for kind of end users it wouldn't. And so we wanted to catch this. So we look for all the places where there is access to local storage. Again, we don't care about what the, the arguments are. We actually don't care about what method we use and so there's an additional concept that on the website if you go through it, or you go through our tutorial, you'll learn about this meta variable basically named capture group. Convention that we have but we're saying hey find me all the places where you use local storage. I don't care what the, what the function call is, and I don't care what its arguments are. But let's make sure that it doesn't appear inside of code that has a try catch, where we recover browser security error, and there's a couple different variants of that. And so we use this, and it has actually proven quite effective so there's a couple, quite a few test examples here, as we dialed in the rule. But I think this would be a great great use for some graph where it's, it's highly relevant for you, it's highly relevant for the members of your engineering team. And it's something that, you know, probably doesn't generalize because these are things that are specific to R2C, right, and these are these like helper methods that we've written. So you would have to write the rule and it's, it's easy to do so with some grip. And then I'd also mentioned that there was this community registry. So I'm going to quickly click through that. I'm going to mention it that members of the community who have basically specialized knowledge either in security, or go performance, or the OSP ASVS framework, have been willing to step up and make contributions to the registry. And so, clicking through, I'm on time prep again, and I'm just under rules here. So this is the rules registry. And you can go through and you can look at kind of different rule sets. Excuse me, different rule sets that people have published, and I'll just click into one for for go. And anytime you're you're looking for these rule sets, you'll always see that they have this some grip dash dash config line that I can copy so if you want to run it locally, you just copy it that way. You can go through and find the types of things that this will check for. And then you can also browse all of the rules as well. So if you want to kind of filter, you know, look for things that are related to Python, maybe things that are related to Python best practices, you'd be able to do that under the rules tab here. So a lot of, a lot of rules, and definitely more, more every day. So, I would start to transition into what does this look like to integrate into CI. So before I make that transition are there any questions that I can answer about the registry or rule writing, or some group. So I did not see any new arrivals, and certainly there is already a question about how do you integrate with with branch based builds and into your CI server so there are already questions asking about the next step. So it sounds like I should talk about the next step then so let's, let's dive in. I am on the semgrep docs tab. So I've got that open. There's a bunch of different, there's a bunch of information about a different CI providers. And I'm just going to pop down to this standalone providers. Let's talk about how semgrep works. So, in CI, there are folks who are running semgrep, just kind of the vanilla semgrep command line tool that I showed you before. I would say most people though are using this CI wrapper called semgrep agent. And so this is a separate repository on GitHub. I'm showing it here. And some group action is special, because it understands, or has like greater knowledge of get. So it's actually able to, you know, do things like get log it can check out previous commits. It understands .git ignores. It understands it has its own ignore file, a .semgrep ignore. So if you want to exclude vendor code as an example, all of that functionality is going to come out of this thing called semgrep action. And again, it's published a couple different ways. So you can either install it as a Python library so you can put install it. And I would say most people use it as a Docker image, which is what we're going to use in just a little bit here for Jenkins. And what's cool about this, so I'm not showing it here, but there's a couple command line arguments that you can pass specifically to deal with branches where I had mentioned earlier in the presentation, you know, you shouldn't be punished for trying to add a tool for security, right. You shouldn't have to like fix however many issues you had in the past. Let's just get this tool installed and kind of looking forward. So if you're running semgrep and semgrep agent on a pull request, you can configure it so that it will basically do two scans. It scans the latest commit on that pull request. So the latest version of the code. And we'll go back and scan the base commit of the pull request. And so you're looking at, okay, what is the code that's changed from when the person, you know, branch to start their future development to conclusion of their future development. So when we run those two scans, it lets us look at the results and say, okay, well now we know which results are new, you know, as of this base commit and whatever is on on head. And then show your basically the user, the developer in this case, issues that they are responsible for introducing, not all the stuff that came before. It's also faster. So if you use semgrep agent, it won't scan on on pull request so set it up in this this different way. It won't scan the entire code base it will only scan the files that have changed. So you get some interesting performance improvements there. And because you're showing people results that they have introduced the likelihood that they fix those, those issues goes way up. Instead of just showing them, hey, there were pre existing issues please fix them. Well, it's not in code that I touched that I don't want to think about it. This is actually code that they've touched. And so very likely that they fix it. I mentioned a couple of these things here I talked about this baseline breath, kind of a key feature for doing the differware scanning and is what most people are are doing. So, I mentioned that we have an action, I guess publishes a Docker image. Let me show you then what Jenkins config looks like. So this is a friend of mine set up a Jenkins file and he has a sample project. This is a known vulnerable project called let's be bad guys. So, things to know, we're running within Docker. We're using the sun group agent image. So most folks will use this be one tag, which is basically our stable tag or latest tag. Making sure that you get the, you know, the latest and greatest updates to some grip, but it's also well tested and not unstable. And then, when it actually comes to running, running this, the call that that he's making is Python, he's calling some group agent. He's using it in a way that is actually authenticated with the registry. And this is so that you could do private rules or custom rule sets. So that is one way that you can run it. And I believe if I switch over actually to a different branch. Yeah, so an alternative way that he hasn't configured here is just to hard code, which rule set to use. So you could do that as well. So there's no dependency on logging in. There's some benefits if you do. And then in this case, you can also just hard code which rules you want to run the CI. Through this approach, you would also be able to do files that are local. So someone had asked about private rules earlier. In this case, I basically check in those rules to the repository. And then when I actually do my some group agent invocation, I would pass in the path of those those local private rules. So that that should work for you. And there's some other other niceties here so just to kind of point out all of this stuff that's up above all this environment information. This is because. So for for Dahon, who's the name of the person who set this up. This work is that he gets Slack notifications in mind PR comments and kind of like a suite of other things that are not possible just with some group agent. But he's actually has a dependency on our external system and these environment variables become important for that. So just wanted to show you that. And then in terms of it being in action. I just pop out. And so I've got my Jenkins pipeline. And there's a lot of red, because we're doing testing and trying to trigger failures, I promise. But let me show you what it looks like when it actually runs so the most basic output that you would get when you use the same group agent is something that looks basically looks like this. It's just a little bit dense. But if there are issues, you'll get printouts just directly in your your build output. So you can see that in this file, vulnerable views. We found a string comparison using is, and there's some issues in Python, you're doing string comparison is. So we flagged that issue. And then we also flagged an issue with misuse of globals here and so we'll print out a little bit of what the code is kind of give the developer context, and then print out what's designed to be a helpful actionable error message. And then you'll know kind of what your next step should be. And these are rules that are just coming from the registry. Now Luke, those are incremental changes so you did not show me the, everybody else's dirty laundry. That is a great question. So if I go back to the config. And this is something I'll have to confirm with with Dahan. I don't see him using the baseline ref flag. So my thought is on the basis of that. These are actually the issues that are in the project. Okay, so this is project wide unless I use the baseline reference thing. Yeah, exactly. And if I just take a look here. I'm just seeing what some of the other folks have done. Yeah, so I'm looking at different provider. So forgive me, not Jenkins but in Circle CI. I see here that we actually are passing in or the person who contributed this config is passing in baseline ref. And my understanding is that is necessary to do the differential differential work. And there's been, I got to say so I love the Unix philosophy where you have a tool, one tool does one thing well. One tool can kind of mix and match and you know pipeline that that tool. So, someone the other day wanted to scan on every merge to main or develop right so they want to run some rep do a whole scan. But they didn't want to scan all of the code. They just want to scan kind of was recently changed. So I think what they did is they use this baseline ref argument, and they did like, you know, head till the till the to something like that so it's in get they were trying to go back to commits or three commits. And so they were able to actually not do PR scanning but they were doing scanning on man and develop, and they were looking at relatively small change sets. So there's just some cool benefits that both on speed and then really old issues they weren't flagging they were still flagging, you know, issues that had happened within the last couple days. So I was kind of their their hack in their workflow. So yeah so I think you'd want the baseline ref, which I think is not not in this example right now. So pretty basic output. I think what we'll end up doing we'll put a little bit more time into this, the feedback that I've gotten as we've been trying to figure out okay what what tickets do we want to act on and prioritize as a maintainer group. It just turns out that I think most developers don't particularly want to go to build out output to find the issue that they have to fix. The kind of number one there's two, two leading requests one is just give me a comment on my pull request. And so that's a feature that we support. But you have to unfortunately go through the logged in version of some of that debits free, but you do have to go through it. And then the other features I want to just run this stuff in my editor. And so when I look towards okay hey it's a project. What we're doing next is we're focusing on adding support for JetBrains. So if people are running this in CI, let's let them run it in JetBrains as they write their code. And we already do have a VS code integration, but we want to expand support for that. And so the big ask that we've had is, we want to, people want to be able to ensure that what they run at CI time is what runs locally. And there are some improvements that we want to make so that you basically can guarantee that the rules that are running in CI are the rules that are going to run locally. And then we're also working on performance and parsing optimizations. So we're very much performance success. The tools already very fast. It's very, very, very unlikely that it's the slowest part of your test and build system so I think it takes about a minute on average, but we want it to be better. And then we're adding additional languages so there's been a bunch of interest from the community in mobile languages so Kotlin and Swift. Turns out Scala doesn't have a lot of really great program analysis tools so we talked about Scala. And then C sharp has been top of mind recently. Let's see what else can I what else can I show you I think that is basically coming to the end of the prepared content. I would love to answer any questions and click around. If anyone wants to see more. So, so there was a question you alluded to its answer earlier I wanted to see if you wanted to go further on that. Can you can the rules registry be hosted internally you mentioned storing it inside the repository. So also able to get some equivalent to the semgrep.dev site feeling, but on an internal site or is that not allowed. Could you share more about that. Yeah, yeah I can. So the registry. Right now there's not a internal variant of the registry. So the registry code itself is not basically not open source we've talked about making it source code available. There's still some discussion about it if the infrastructure code should be open source and openly licensed. So feedback welcome on that. What we have seen people do is that you can download rules from the registry. And actually there are you basically can curl, and I'm happy to talk through the endpoints but you can curl configuration endpoints. You can just download the raw like rule config. So if you wanted to set up some kind of cron job or something like that just to make sure you have the latest and greatest. You definitely definitely within your ability and we support that. Now on the kind of like playground side. So currently there's not an internally hosted version of that. We have basically once you kick over to, to no longer open source but like paid stuff, there's an enterprise tier, and that's like something we could discuss for that. But there's not something right now you can just go get clone, and then stand up internally. Thank you. Another question this one a little more precise. What's the minimum Python version required to run some grip. That's a great question so I'm going to refresh myself. And I'm hoping it is in our documentation. I think it is, it's definitely Python three. And I'm looking for the minimum version. So I will update our docs that we definitely have the minimum version and quite surprised. Python three, and I'm thinking it's three six, but I forget offhand. I will add that to the docs. Okay, yeah well but so so grateful here it's not Python to where support ended in January 2020. That's good you're you're not carrying along ancient ancient history so very good. Yeah, and worst case I know that Python can be a pain in the butt for everybody, which is why we also have have Docker just that that seems to be the big camera to bring out if your Python environment is not working. So now, are there things that you've learned on this static analysis journey where you'd share with with others. Hey, here are things that static analysis is really good at and other things that it's not as good at. Yeah. So I think the biggest thing earlier I talked about this idea of like code guard rails. So I think so static analysis generally gets this bad rap that it's, it's super noisy and it tells me things that maybe I should fix maybe I shouldn't. SQL injection I brought that up earlier, right it's like well does the the piece of software really understand, you know how you do user input sanitization and all that it's like that probably doesn't. And so, if you you make this switch to code guard rails and you say hey we just we don't use raw SQL here. We use an object relational mapper. I think it's no longer a like well this might be a problem. It's pretty black and white. It's like, we do we do this and we don't do that. And the response I think is that oh this tool is actually valuable it is it's helped me. Because it's just it's less like I can't go and argue with it as much as like oh no I'm just I need to follow our conventions as a company or as a as a team we've agreed to this. So, kind of I think my big learnings actually maybe more like the, like the psychology of static analysis, which is that it's far more effective for you to enforce the use of specific frameworks and apis. And maybe like look for business logic issues, whatever it may be that are specific to your organization, then to have a, well this might be a security issue type of check. And a lot of the rules that that we've written and added to the registry are of that vein and I think the ones that we get the most value out of internally as a company at R2C are the ones that are like, we just don't do it this way. Here's here's what you should be doing. So the perceptions much more positive. Now, are there are there things that you've found where, hey, semantic analysis or static analysis really wasn't doing what I needed I had to do some other technique or there isn't you found it you found in your space it just works well. Yeah, that is, that is a really good question. And I think that it's not the full answer. So like if you're using static analysis that does not mean that your code base is secure. Right. So, I think that's that's my concern is, particularly on the, I'm adding, you know static analysis for compliance and to kind of get my checkbox. And then things start to go potentially off the rails. So, just because you have static analysis doesn't mean you just get to like live, live free and party in your code base all day every day. You still have to be thoughtful about what's the architecture of our system. You know what are the ramifications of how we're deploying it. You get into a whole host of issues right more around kind of your deployment environment and network configuration everything else. So, I love static analysis because it lets you ensure that your foundation is solid right it does help you kind of at the source address security issues. But there are still many other layers on top of that and so you probably have to complement with other tools. And then I'm a big fan of you find the right tool for for the job and so sometimes rules are complicated enough that some group is not the right tool to try to use. You know maybe you should go with one of those tools that is more complicated. So in the sequel injection case right if you absolutely have to scan for sequel injection, you can't do paved road. You might need a tool that does this whole program analysis. You really need to spend a lot more time to figure out how to use and write rules for some reps getting more powerful so I think that we will get there. But as of today if you have to have that, and I would say like this isn't the right tool because we are what I failed to mention is some grip is fast in part because it scans single files. So, it's not trying to compile your entire program. It's looking at, you know, individual files. And that is particularly good for this kind of code guard rails, you know, paint road approach, but it is less good at things like sequel injection. Where's this cross file as a benefit though if there's any Java users out there, you don't have to build your Java code in order to use some grip. It runs on just the raw source so you're, you do not have to have a compilable project to run some grip, which is pretty. So, that there's a there's a different kind of question so we've got a new question just arrived. Do you have support or examples using cloud native build packs and, and I'll, I'll leave it to you to infer the meaning of that is there is there anything special around cloud native here. Not that I, not that I know of that might be. I see that Jeff has that might be a good question on the community slack. And I think what I found is that a lot of people have used some grip and a lot of different places. And so that might be a good basically community question. I was envisioning that okay this is because you've got a Docker image available, but that Docker image could be executed in a Kubernetes cluster or just as readily as it's executed anywhere else in Docker but I'm not sure that that's that's really addressing the specific question that he had so. Any, any refinement. Yes, let us know we can try to answer well and as we get to the end of the presentation here we will switch from recorded mode to go live without recording and Jeff if you're willing to stay online we can then have a conversation about the question. One one closing thought for everybody or two closing thoughts because there are some getting started questions earlier. So go to some grip dev that's probably the best portal and starting point. And you can learn about how to write rules and download the tool all that. And then as a personal favor. I'm very curious how I did. So if, if folks would mind filling out this RTC dot dev slash survey link that that helps me prepare for my next presentation so would be a great gift. I had mentioned that we're on on slack. It's been a really, really powerful community. So as folks have had questions I feel like the community is getting large enough now we're kind of, you know if you want to do something with Jenkins you're probably not the first person. You know if you're trying to do some other interesting use case you may not be the first person so there's other people who are excited about getting this tool up and running and could could help. Thank you, Luke. Thanks very much. So the request was a slack invite so I suspect we may need the slack channel identified there. Yeah, that is a great question so what I'm actually going to do. Let me just go to the homepage. It is it's just an open slacks I'm just going to scroll down the bottom because I think it's in the footer. Yeah, so there's actually just a link to join slack here. It's also linked on the projects read me's and you can just click and sign up right away. Perfect. Thanks. Thanks very much. All right, I think our general questions have reached a pause point. Luke if it's okay with you I'm going to go ahead and stop the recording thank everyone for for participating thanks very much we will remain online after the recording has stopped for at least a period to allow the those who are in attendance to questions. So thanks very much again Luke. This has been a Jenkins online meetup. The recording will be available through the Jenkins YouTube channel. It'll think about 24 hours will also post a link to the recording in the meetup.com site.