GitLab GitLab Group Kickoffs - Secure:Fuzz Testing, 17 Nov 2020

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: GitLab Fuzz Testing 13.7 Kickoff

Description

Sam Kerr walks through fuzz testing group's areas of focus for GitLab's 13.7 release.

Product direction page - https://about.gitlab.com/direction/secure/fuzz-testing/fuzz-testing/

A

Hi there I'm sam kerr, I'm a principal product manager here at git lab and today I'm going to be talking to you about what some of the items we're going to be focusing on in gitlab's. Upcoming release are going to be for the fuzz testing group. So let me share my screen and we will walk through what we're going to be focusing on.

A

So one of the areas that we've become aware of is that, when you're using get labs coverage, guided fuzz testing is that managing your corpus and your input seed corpus can be difficult because of the way it works. Today you have to commit files directly to your git repository and manage them as artifacts in some cases, which can be some extra steps and we thought there could be a better way. So one of the things we're going to be focusing on 13 7 is what we're calling the corpus registry- and this is really designed to.

A

Let you easily manage these corpus files that you would provide to the fuzzer in a single place without having to make commits to your git repository or manage any sorts of artifacts.

A

So if you want to read the full details on the issue, it's issue 235 484 in the gitlab project, but I want to walk you through a couple of the designs to show you what we're thinking so we're going to be implementing a new set of screens for the corpus registry, and these are really going to be all about. Where do your corpus objects live? How can you get information about them and how can you update and create new ones, so I'm showing a mock-up design here?

A

The final version might look a little different, but really the the key points that I want to highlight here are all of these different corpus objects are listed here. You can see information about each individual, one such as the size of it.

A

The latest job that used that corpus object when it was created, you'll also be able to download these corpus objects. If you want to look at them locally, you can delete them or you can add a new corpus object.

A

If we look through some of the other screens on here, you'll be able to get to that screen that I was just showing from the security configuration page.

A

So if you go to configuration under security and compliance, you'll go to coverage, guided fuzz testing and over here on the left under that in under that manage button, that's going to be where you'll find a link to the new corpus registry, and we think this is going to be a great way for you to be able to manage those corpus objects, because you can work in a more visual ui based experience, rather than having to commit those files to your git repository directly and have to go through potentially reviews or potentially adding large binary files to your repo.

A

So if you'll recall from the first design that I showed each of these corpus objects is going to have a name associated with them. So in this case it's corpus example 1-5830. But you can name these whatever you like.

A

I might name mine sam's corpus, for example, once you've gotten that name using this corpus inside of your, your pipelines is going to be very straightforward as part of your fuzz testing job you're, just going to have to define two keys to say, use the corpus registry, and then corpus name, and then the name of that corpus object that you defined.

A

So this example, it's my corpus object, but this would be the corpus example two one or what have you, and we think this is going to make it a lot easier to use corpuses, which are very important for coverage, guided fuzzing to help you get the best fuzzing results when you run those jobs.

A

Another area that we're going to be focusing on in 13-7 is how do we get our api buzzing results out of the junit style test results that they're in today and into the security dashboard alongside all the other security scanning results that you're used to seeing, rather than walk through this issue, I'd like to show you what I'm talking about so, if you're familiar with our api fuzzing today, the screen that I'm showing now this is an example pipeline.

A

Api fuzzing results will be reported under this test tab and you can click on those to get all the details about what's going on, and this is great to be able to consume these results, but notably, none of the other security results are next to this tab.

A

So what this effort is really going to be all about is how do we go from this screen that I'm showing right now and making it so that those api fuzzing results show up in the vulnerability dashboard that I'm showing on this screen that you're, probably familiar with so once this effort has been completed?

A

All of these api fuzzing results are going to be alongside all the other scanning results that you're used to you'll, be able to filter them to look at just api fuzzing or any of the other scanning type results that you like, and that way you'll be able to use the same workflow, whether it's for api fuzzing or any other scanner. That gitlab offers and another effort I wanted to highlight that we're going to be focusing on is: how do we publish integration for api, fuzzing and junit?

A

uh We know that one of the difficulties with getting started with api fuzzing is how do you find the the specification files or how do you create the recordings needed to inform the fuzz testing engine on how to do its job?

A

But we also know that many of you already have existing tests in the junit format as part of the api fuzzing technology that we have we're actually thinking about how we can leverage those tests that you already have written.

A

Look at the way that they're defined and be able to generate the necessary api fuzzing harnesses directly from those test cases- and this is going to be a great win for usability, because it means you won't have to either create a specification file. If you don't have one, you won't have to do an extra step to create those recordings to pass to the api. Fuzzer you'll be able to use the existing test cases.

A

The existing test, suites that you already have in that junit format and be able to point the fuzzer at them and that be all that's needed to inform the fuzzer on how to start doing api fuzzing against your applications.

A

Stop sharing, and so those are a few of the things that we're going to be focusing on in our upcoming 13.7 release at gitlab. We plan ambitiously, so not everything I walked through will necessarily be delivered in 13.7, but it is good to give visibility, and I wanted to share some insight into what we're thinking about is some of the priorities for this upcoming release cycle with that. Thank you. So much for your time again, I'm sam kurt. I would love to engage in a discussion with you on any of these issues.

A

If you want to ping me or anyone else in the team directly, we love feedback, whether it's good bad or ugly, um because it helps us make sure that we're building the the best product for you and and the rest of the teams that use gitlab. Thank you. So much have a good day.