James Brotsos – Checkmarx Integration with GitLab

As we've seen, bridging security and development is really important to merging security with dev ops, many of our customers have their favorite scanning vendors that they like to use, and we've recently made it easier for them to integrate those scans into the GitLab workflow. James Brotsos is here from Checkmarks to show you the integration work that Checkmarks has done so that their users can get the checkmark scanning results to the developer within the GitLab CI pipeline. All right.

Hello. In a spirit of shifting left, I like words that checkmarks security platform and how we integrated with GitLab to provide security results sooner in the security software development lifecycle. Quick introduction.

My name is James Brotsos. I'm a senior solutions engineer with checkmarks. I have 15 years experience as a developer doing network protocol and personal development work.

Last five years I've spent as a solutions engineer and overall I have about 10 years experience with application security testing tools, five years as a developer and five years as on the solutions side. A shameless plug. I actually run the Checkmarks User Group on Meetup.

So if you're interested in any kind of cool work that I'm working on, please join me. And my true passion. My hobby is I'm an active maker.

I love building and breaking things actually to. So this is the agenda for my presentation. It's meant for deaf engineers interested in security, is meant for application security engineers and also just developers in general as well.

If you want to check Marxists, I'll dive in to give a brief overview of checkmarks. I will do a deep dive into the integration that I performed. And I will show you a workflow from MIT Lab to check marks and back to get that on the whole on the whole end to end with them.

And lastly, I'll show you an actual live demo as well. So what is checkmarks? So Checkmarks is in application, security testing platform, so we are known for a static analysis, but we actually perform security types of reporting on different levels.

We do a software composition analysis which tells you all the open source packages that you have you bring into your application are the version numbers of those sort of packages and all the known vulnerabilities for those open source packages. We have an interactive application security testing platform, which is an agent that runs on a test server that's running. You're running from your code.

It monitors traffic driven from functional test and it can run security types of queries on top of that. And we have an application security awareness program. So we provide you with all these types of vulnerabilities and we train you on how to fix them.

It's an eight to 10 minute game outside interactive way of learning what security type of vulnerabilities are. So key to a successful security program is really having automation and integration into the software development lifecycle. We give you the ability to determine when you want to scan, you might want to scan on Commis, you might want to scan emerging quests, you might want to scan on a nightly or weekly basis.

Different people have different ways of wanting to see these results. They might want to log into the check March platform, they might want to get Jarett tickets automatically created. They might want to get an email or a message, or they might want to stay within the ecosystem and consume the results inside.

And that's where we see most of our customers buying their checkmark results inside of the GitLab's platform, inside the inside the eco system. CX flow, CX flow is a spring boot application that our R&D maintains is a scan and sort result orchestration so it can initiate scans and also pursue the results. And that is the main driver behind the Gitlab integration that I will talk to you about into detail.

So CX flow can be configured in two different ways, either using CX flow from a command line or having to explode work as a server and listen for the defense. The scam is initiated by integrating with labs, tool, tool, quest, or even pushes the source will trigger an already existing pipeline and the existing pipeline just needs to have one at it to include at the stage to execute the checkmark scam. And this will either create a new project if it doesn't exist or it will update an update.

Current one. Team management said flow can create teams based off of the first control management structure. I mean, it's very highly customizable.

Resource management, so as far as results go, the scan results are filed based CFP or JSON or XML, making it really easy to import into defect tracking systems or dashboards. CX flow also drives a result feedback loop, eliminating how to do manual intervention, meaning basically that defects are automatically opened and closed if they have been fixed. You can always filter the types of defects created based on any kind of filtering criteria, and the results are easily consume in a way that developers want to.

That results and most importantly, actionable defect tracking so we can solve the issues of the same vulnerability type in the same file instead of having multiple issues. It's just one issue. Once all the references, the barbecue type of that issue was fixed and that ticket will automatically close and you can base you can base this on different types of policies, severity, e the vulnerability type or even the state.

And Treki is also supported for the soccer competition analysis results as well, and feedback channels. So not only does the explosive sport get lab security dashboard and get lap issues, but also sports JIRA or email ServiceNow and. All right, so it's pretty it's a pretty effortless option for the development teams to do to scan projects quickly.

There is no overhead line configuring and managing to build. You can quickly automate the scan of multiple repositories, and again, there's no overhead and configuring and managing all these different reports that you might have. So in this case, the automation of the developer is common tools that we're talking about, get lab, you want to get the details of those issues to those who want to address them.

The developers, obviously, you want to drive security testing based on lab activity, publish those issues and the existing into the existing backlog and keep developers within Getler. And this really does free up time to focus on things that actually matter to developers, which is writing code. With this mythology, we are sitting in a Starbucks again in the software development lifecycle.

We still are providing governance and data and capabilities, constantly getting scanning the latest code. It really replaces the need to scan it in the. I want to talk to you about the integration steps that it took to get to the final integration that we had, I think it might be interesting, just kind of my learning process of, you know, kind of the trials and errors I went through.

So the first first step I really did is I really want to get scans done inside the lab. So I had a very simple initiation that scans I learned about Gett Labs pipeline and specifically the lab file. By adding a stage, I was able to just make a rest API call, check checkmarks, the full suite with all its end points that can initiate the scan.

The biggest problem with this was that there was no interaction with the results. So this can be automatically initiated and scanned. And developers or dev ops engineers, we even know that the scan actually had finished.

So that led me to my second stage, which was a more of a full and robust integration. I had a lot of custom scripts that were not only initiate that scan, but then passed the results and push it into the security dashboard. And that was a step or actually learned about the security dashboard, which is a feature that I'll walk it through through a little bit more.

But it gives you a high overview of vulnerabilities from SAS tools. Are DAS tools over time allows you to try and create new issues and psych lab issues as well. The biggest problem with this was the maintenance of all the scripts and you had to put these scripts in each individual repo.

Every time I made the scripts, I had to edit each repo and and I had to use a lot of variables and scripts I had to manually edit, which led me to my final solution, which is probably the solution to start off with. But and that was the containerize everything. So with get lab you without it allows you to use an image.

And we maintain checkmarks, maintains an image that has the six steel I built into it. So not only does this initiate all the scans, but then also we added to the explode application to actually report the results and put the results into the issues and also the dashboard as we learn about using global variables here instead. So when you kick off this pipeline, you can be a global variables that allows you to manipulate the scripts in the way you want to.

So I want to show you what end and workflow of how get that in check checkmarks integration works. So, again, the I have global variables that are set up. We're mostly used for authentication and check mark server check server is usually on the same network as the server.

So it's always on premise. So no data is ever leaving your on premise environment or network or nothing going back to checkmarks itself. So once the authentication variables are set, then a pipeline could get kicked off in many different ways.

So think of it as a push event or a merge request and it reads this file. A. file lays in the root directory of of your get that repo.

And what I did was I. I separated the checkmarks stages from the file, so I don't actually pollute the already existing Getler file that your dev ops might have already set up. So all I have to do is include another YAML file with this stage or with this extension, and it allows you to have the check my specific information which kicks off the flow.

Seelie. So once the flow starts to run inside that container, it will initiate a scan inside check marks again, check marks is always on the same network as GitHub, and it will send the results back to the flow. And that's where we pass the scan results.

And depending on how you want to consume those results, we can update the security dashboard, we can update the issues, we can update the merchant class, or we can update all three of them at the same time. So different ways we integrate is through the Mirja quest to issues and to security dashboard, so inside the merge request that there was a merger request performed, we will put a high level summary of the sassed and the FCA. The software composition analysis results inside the merged Quest overview.

If you want to have trade issues automatically, it will create issues inside of issues and you can then charge it to to the right epik or assigned to a user and treat all your vulnerabilities as you would any other de facto, any other kind of issue. And the importance that the security dashboard so scary dashboard is a feature for gold and ultimate get lab members or if your project is actually public. So if you have those features, if you have that tier level at Kulab, you should take a look at the security dashboard.

It's either per project or per group. All right, so before I jump in the demo, I'll give you some references if you want to see the step by step integrations done for lab and check marks, I've got to check marks, dot com sites, get Lab.. I also have my demo code that I showed to you.

If you want to take a peek at what the files look like, if you have any questions for me, I'll be in the chat as well. And my contact email is James Prothesis at Checkmarks dot com. The architect of the explo is Ken MacDonald at checkmarks dot com.

He can ask any questions you might have on the architecture of Explo. And we have a full set of documentation to read about six explosion and all the options it has if you want to check out the wiki page listed here. All right, thank you and I will show you the demo now.

So first, I'm going to show three different immigration points, I'm going to show the quest and I show the security dashboard, I'm also going to show the issues as well. So to kick off Immerged Quest, I am just going to edit this source file. This is a source that has known Scorpion inside of it, and I'm a target this branch to a security branch, which will then start a new quest of these changes.

And submit this merger request. So right now, you can see that it's basically had detached a pipeline here and it will you can merge it when the pipeline actually succeeds. Just take a look at the pipeline.

Looks like you can see that in this section here, that this pipeline is currently running in the way it runs and the stages are determined to get that YAML file. So let's take a peek at what that looks like. So this is the file you can see on line one, I'm including the dot checkmarks dynamic file.

This is not so, as I mentioned before, this. So I don't do this already existing file that maybe your dev apps have already set up and has stages already built in. You can see that the checkmark is actually on.

On line number seven is for a stage test. This is recommendations from get them to have any kind of security type of checks or scans be done at that stage, protests, that stuff at stage, but also the default stage. So if you do not have line seven, this will kick off during the test stage anyway.

You can see that limit to the master branch and the merge request. And let's take a look exactly with this. Check marks that YAML file, but it does extend the check marks test.

So I take a look of that. Looks like. So you can see here, this is extends that stage that we had before, that that checkmark steps, I'm using a container that is supported by checkmarks.

You can see I have two different. Scripps one is for a merger type of movement and one is for just a normal pushy bent, a main reason is, is because I do leverage the get labs epis that has the merge merger request update. And so I do need to have that merger request.

ID, I think is a good time to give a lot of kudos to the GitLabs documentation team. Everything I've done, I've done by myself by reading the documentation and it's by far without doubt the best documentation I've ever experienced. So kudos to that team.

And you can see that I just have a normal thing by and invoking the sixth load jar file, which is located inside of that checkmarks container. You can see that this is the CheckMark's Queue, this has a CX demo app that security does as right on the security branch, you can see it's finished now, but this was a Q four for the for the checkmarks. So now it should be done.

Let me take a look at the request. All right, so you can see that this is updated to say that a scan was submitted to check marks and then you can see the full scan, a summary coming from checkmarks, very high level. It will tell you the violation of summary on the high medium on loans and info were found.

You can see that I have different lines of different end. So there's 11 everyone's different 11 different profits could be found and there's 11 different sources. And I click on each of these ones.

It will take me into the Gett Labs interface of the actual source code. I can I can also go into checkboxes and see the full flow. A lot of our customers really enjoy the experience of going to check Checkmarks UI and be able to see that source to sink and file the whole data flow from a security type of vulnerability.

And also get the software companies analysis results as well. So usually when you do a merger with a best practice would be that during this type of scan, you're doing an incremental scan or a Delta scan. So you're only scanning the code that's actually been changed since the last full scan.

So this is actually a done in an incremental scan. Now, if you were to do a merge into the master branch and I'll click on this merge, this will now initiate a new scan, which is actually a scan, the master branch with the that are coming from the security branch. So now that this has been merged, I can actually take a look.

Another pipeline gets kicked off. It's picked up here and then the check, Maskew, instead of being accidental at that security, it'll be six Demel X, Dasch M.. So this is running.

I do want to show you what the security dashboard looks like. So the security dashboard. It gives you a high level summary per project on the critical high and medium type of vulnerabilities that were found in the scan.

Now, this security dashboard has a lot of different types of scanners that can be enabled. You can have the container scanning. You could have dast dependancy that the secret detection and coverage fuzzing.

So you can actually have something like Szostak and probably have Breckman enabled as well to get some groovy results. You can see here the type of scanner. Right now it's a get lab, but they're working on changing this to checkmarks for the specific type of scanner that's being used.

You have the ability to actually do some triazine. So I want to dismiss this. Dismiss this.

I can dismiss it for if I think this is a false positive or I don't accept this risks or I don't give a reason either. If I want to take a look at more information about exactly what this mobility is, I can just click on this link here and it will give me a summary of the severity where the scanner came from, the file location. So if I want to take a look at what file it came from, I can click on that link and it will point me to the source of this.

Give me some identifiers or some links back into public humiliation type of pages, and it gives me a solution. Right now we have a link back and a check my platform, but we plan on having a small resolution here that could give you a little bit more insight on how to fix it without having to go into checkmarks. So this is per project.

We can also do it per person group. So if you click on the more up here and go to security, you can add in more projects into the security dashboard that you want and it will give you a vulnerability over time. You can see this 30 days, 60 days, 90 days.

But this is a collection of all the projects. Something pretty cool is that you can have a little grade on it as well. So you can see now that the demo that master has finished, so now the security issues should be updated.

So they're coming in now, you can see that to avoid being to avoid being treated so seven 1/2 and created. And now the final nine is the greatest. You can see that we had a letter findings and actually we only created one issue, so that's a really good picture of the explosion, said Krien.

11 different issues is creating one issue that has the same type of bullying really coming from the same file. And again, you can now assign it to assign you can do it for an epic story you can charge of in here. To myself, I can see that we also have software competition analysis results as well.

So I thank you for your time again, I am in the chat room, if you have any questions, I can address them there. Thank you.