Rhys Arkins – In-Context Security: The Destination for DevSecOps

White Source was one of our first security partners to integrate their software composition analysis into GitLab CI. With White Source you can scan more languages and enjoy many other benefits that they bring while seamlessly providing actionable results to the developer through the get large request pipeline. White Source also integrated into GitLab's security dashboard.

Here, the security team gets much earlier visibility into application risk while also getting on the same page with the developers. For details, check out the White Source web page on GitLab Integration. Now welcome Rhys Arkins with White Source.

Hi, thanks, everyone, for joining us. Let's continue the security discussion today by talking about deficit jobs and reducing context, switching in open source security. Now, as many of you hopefully saw, maybe even participated in GitLab released its 20 20 dev ops survey results recently.

And I was interested in this question, particularly about how nearly half of the respondents were not willing to classify the current security efforts as good or better. This is perhaps a good thing, though, because it's never a good idea to be overconfident with security. But it does raise the question of what does good security look like?

What would it take to answer good or strong to that question? So today I'm going to dive into that topic while focusing in particular on open source security. So first of all, when it comes to security, I want to make it really clear that it's never a good idea to neglect parts of it.

However, I do want to emphasize the importance of open source security in this discussion, and this is because of the so-called iceberg effect in the typical application. This might be your website. It could be an API server.

In your typical application, the majority of code that you ship is actually open source code that you have imported into your project one way or another. Now, with open source code to you, it might seem like, of course, someone else's code and therefore maybe someone else's responsibility. But to the end user, the end customer, everything you ship is yours and it's your responsibility.

So what that means is that security problems in open source also become your responsibility. Now, if it wasn't for that, there's one thing that also makes it particularly important, and that is the effect that happens when security problems are discovered. Now, if you make a mistake or an accident in code that you write, you might even be so lucky that neither you nor any of your colleagues ever discover it or anyone who wants to do something bad.

e. mistakes and open source code that may lead to exploitable problems once they are disclosed publicly, you really have no choice because the bad guys out there are already looking for ways to exploit it and potentially even scanning websites and APIs and so on. So open source security is something that you can't choose just to opt out of.

So in general, this concept of open Social Security falls under a category known as software composition analysis or C A for short. So SCA is fundamentally about knowing exactly what open source components go into the software that you ship and also being confident that you will be alerted if there are any security or, say, licensing problems with the open source dependencies that you're using. This is the core of C, a now at White Source would proud to be a market leader in SCA.

We're a big believer in open source and our goal is that everybody can use open source freely and fearlessly. However, we don't mean the type of naive fearlessness that a toddler has walking into traffic. We're talking about a mature, informed fearlessness to ship code that depends heavily on open source and be confident that you are on top of your security and licensing issues.

Now, in this Forrester report, you'll also see GitLab already making waves in Q2 last year. Now GitLab as a full Devolites platform is uniquely positioned in many ways for SCA and its capabilities. GitLab's capabilities combine extremely well with wide sources to present a joint solution that benefits users of both solutions.

So this is what we're going to focus on today. Now back to this term, dev ops putting the security in devils, now the mantra of this DevSecOps, which you've no doubt heard before, is shift left. But what does shift left really mean?

Now, the theory of shift left is that developers are taking over responsibility for security. But the reality is, if we don't change anything except for our mantra, then nothing of reality will change. So in practice, what this really means is that we need to equip developers with visibility and tools in full security that they need in order to adequately take over that security role.

All right, so if we look at shifting left, drilling down a bit more traditionally ship left came from the software development lifecycle idea that the earlier you catch something, the cheaper it is. You may see people sometimes say it's like a 10 x 10 X cheaper in development than testing, 10x in testing rather than production. I mean, obviously this varies a lot.

But with SCA, we have a little bit of a conundrum here because most of the problems in open source security actually occur in dependencies that you're already using, which actually usually means in production. So no amount of shifting left in the development lifecycle can kind of prevent those types of problems from happening. So we know that there will be production vulnerabilities almost for certain.

And we know that developers are best positioned to own that process, to upgrade or roll back or even potentially remove vulnerable dependencies if there's no other choice. So in that context, shifting left means visibility and tooling to developers in order to be able to do that as quickly as possible. So the White Source and GitLab integration takes that a step further, which I call or I like the term in context, security.

So what this means is that these tools that developers need to be responsible for security are not just available, but that part of the day to day workflows to avoid context switching. And for a developer, that day to day workflow is in giftwrap. So let's center this discussion a little on the GitLab platform first, again, you've probably seen this graphic I included here, because I think it's fundamentally important that GitLab sees security is a first class component of the dead Democratic platform.

And in fact, GitLab was the pioneer in elevating security in source control. So let's zoom in on that GitLab secure category. All right, so here you can see the details of that category that I show and you see those around seven or eight security categories of security components, some of which fall under this category of software composition analysis, but also some which annunciate like sassed DAST and fuzzing.

So this holistic coverage of security capabilities is very important. But today I'm going to focus on two. Here is dependancy, scanning and vulnerability management, because these are the focus of White Source's, integration with GitLab.

First, the little side analogy, I think that personal health is a great analogy for software security now, people are not unhealthy in life because they lack awareness of the benefits of being healthy, nor even of the broad steps required in order to be healthy. After all, we all know that healthy food and exercise is a really good idea. Being unhealthy, though, for many of us, is also not about a lack of intention either.

I mean, most of us want to be healthy. So the main challenge for people in terms of healthy versus unhealthy is whether we've adapted the practices we need to remain healthy into our daily routines. Now, Safi's security is very similar to this because these days developers know the benefits of secure software.

I'd say most developers even know a lot of the specifics about producing secure software and especially about open source security. So the big missing link is security being part of a software developers routines and the day to day workflows like we've been saying that it's in context for them. So one of the biggest problems facing security adoption today is that security is not integrated enough into how developers build software.

And so with the White Source and GitLab integration, we want to make that not the case. We want to bring open Social Security deeply in to the developer workflow. So, you know, as you know, we can we can with a siloed security solution, like the top White Source could build on its own, we can do many things.

So, you know, we can scan repositories, we can match against vulnerabilities, we can even create alerts. But what we can't do is make sure that people look at them, care about them or take action on them. So, you know, if your approach and it's a mistaken approach, if your approach is to try to like lead developers to security, especially siloed security, to lead them to security, it will be like leading a horse to water.

You can't necessarily make the horse drink and you can't make people care about security or pay attention to it if it's not part of the daily workflow. So with that. White Source shifted, left, partnered with GitLab.

So what this means from our point of view is that we bring our Lurdes and our remediation capabilities for open source vulnerabilities inside GitLab. We want to bring actionable data in line with workflows developers already use, or if it can't be in line, then one click away. And also, we want no context switching.

We want to reduce ultimately the time to resolution for for open source vulnerabilities. So, like Gitlow itself, White Source capabilities can somewhat be split between the dev persona and the security professional persona. So first up, let's dive into the details of White Source, developer tools, integrations with giddyap.

So the first point that we wanted to achieve was automated scanning, we don't want developers to need to think or remember about security, it needs to be automated. So, for example, having to remember to insert a manual pipeline for white Source into every new project is something that can be forgotten and it's friction. So the goal is to have white Source automated and ever present within the lab deployment.

Now, we do this by listening to system hooks. This allows us to know every time code's been committed and to scan on every commit. So we call this part of our white Source for developers solution, and it runs in containers, including Kubernetes.

I want to point out, because sometimes people get confused that the white Source for developer solution runs side by side or independently of lab and not in pipelines, as I mentioned before. This way it can queue up scanning results and and report those results when they're ready. We leverage White Sources Cloud Database, which contains terabytes of security and licensing data about open source.

And this is ultimately how White Source for developers integrates in with Gittleman received system hooks performace. Now the next the next thing we wanted to achieve was continuous real time monitoring. Now, of course, we want to be able to run every time there is a commit because that might mean new dependencies and new vulnerabilities.

But also there are times in a software project where there can be a long time between permits. It might be it might be week nights and might be weekends. So in order to combine the best of like pipeline scanning with wide sources, real time, alerting the way our combined integration works is that cross referencing is done in real time.

So therefore, yes, results are scanned every time there is a commit and reference against the database, but also the OneSource database. Every time it receives a new vulnerability, it cross references that against the metadata of every project. So what this means is that if you don't have permits on a weekend, but a very nasty vulnerability is disclosed, you don't have to wait until the next commit on a Monday to receive it.

Instead, that vulnerability will be reported in real time. So all of this can be achieved without any changes to the workflows or pipelines for existing Ghil'ad users. The next point is in line feed feedback now if you give security feedback in a separate, siloed system, it'll often get forgotten.

It also is an unnecessary friction caused by that context switching. So our goal was to display white Source data and alerts in line whenever we could, especially in places where developers are already looking. So in this screenshot here, you can see there is a red comet on top and a green comet below that.

This represents, you know, pass or fail, just like usual. And if you drill down into the failed chat check excuse me, you'll see the report below that. And what this does is gives quite detailed information about CVD and severities and so on.

Now, the idea of this is that if a developer makes changes, particularly in a merge request, that introduce vulnerabilities into the system, that they'll be alerted immediately and can one click get the rich detailed information that they need to hopefully correct that mistake? OK, now you may recall I mentioned earlier that with open source vulnerabilities, you almost certainly going to end up with production vulnerabilities no matter how good your practices are. What this means is that we can't be sure that every vulnerability enters our system through a merge request and can be caught in a pipeline.

Many of the vulnerabilities are going to be independence's we're already using in our base branches. Now, what this means is that we need another way to alert GitLab users to security issues that are found asynchronously or unrelated to pipelines without real time alerting. So for this, we adopted confidential issues to again mean that there's no context switching required for developers using using the GitLab system.

So this means that for if there are 10 outstanding vulnerabilities, we can create 10 confidential issues, giving great detail on all of the things wrong caused by that CVE. Something I'd like to point out as well is that the issue creation is optional. I know that some people don't have issues enabled on projects.

It is possible to disable them and even to use other issue systems like JIRA. But for the ideal lo lo no context switching GitLab issues of the best way to raise awareness to developers. OK, so alerts and issues are great, but resolving the problem with one click is even better.

So I can't. Hanson a White Source solution is extensive remediation capabilities for open source vulnerabilities. So why tools for developers can raise automated merge requests that provide the exact change required to remediate vulnerabilities that are found in a base branch of a project GitLab hosted project.

So this means that instead of developers having to read reports and it says, OK, update to version one point or two point one point six or something like that. Instead of that, you actually get a merge request almost immediately that you can, of course, run through your regular pipeline checks and merge with one click assuming that it passes the language support here is quite extensive JavaScript, Java, dot net, python, ruby and go length so far. And another nice feature is that if you're using both merge requests and issues is that the merge request will confirm to you which issues that the merge request fixes or closes.

Now, as a final step in and our developer focused tools, we leverage a feature of gold and ultimately a pipeline security. And what this does is this gives positive feedback on the merger request that we create, enabling developers to have like a double confidence in the remediation merge requests that white Source creates. So, of course, in the first instance, it's an automated merge request and lists which CVE's and issues are being resolved.

But also to give you additional confidence, the scan is rerun on the new branch and it is confirmed using the pipeline, scanning that the that the vulnerabilities are indeed resolved. So, again, we want to reduce that time to resolution. So making it one click and a very high confidence is the best way to achieve that.

OK, so continuing into gold, ultimate discussion, I want to talk now about the security dashboard of GitLab. So, again, as I mentioned, it is almost guaranteed that any medium to large software project is going to have open source of vulnerabilities in production. OK, so the dashboard, therefore, the security dashboard, I mean, is additionally useful for open source security, because what this does is allow security teams to coordinate this quite pressing issue of vulnerabilities in production.

So one of the key things about when vulnerabilities are in production and the publicly disclosed is that urgent action is often necessary. So security teams need the ability to coordinate. They need to make sure the right people are notified.

They need actionable information about this security threat. And finally, they need to be able to work with developers in order to remediate these problems. The security dashboard is a really great one, stop all inclusive security dashboard, including for non SCA, as I mentioned earlier, the SAS Dast token scanning and things like that.

So the security dashboard provides security professionals with a great view into all of the projects they have access to. This doesn't require them, for example, to be logged into multiple security products, including Weitzel, as well as not needing to watch individual product and project issues. So one of the key things that white Source brings into the security dashboard is as much actionable data as we can into the alerts you can see here screenshot of that.

Now, if you've looked into security before, for example, if you browse the national vulnerability database, the MVD, where most vulnerabilities alerts come from, you probably would have been pretty surprised at how unstructured and confusing that that data can actually be for the national vulnerability database. So why outsource? We work to enrich as well as clarify every issue we can, every vulnerability we can.

And although we provide links to many external sources such as the MVD, such as potentially to the issue of the merger request where the issue was resolved, our goal is that the data that is is provided to the security dashboard is both succinct as well as complete, allowing security professionals to make informed decisions without having to context switch out into multiple tabs, multiple sites and so on. So wrapping up, here's the core of the GitLab in white Source, better together story, so shifting left, it needs to be more than just words or mantras. If developers are to take responsibility for security, they need the necessary data and tools in the context they operate, which is GitLab and for GitLab users.

The benefit of white Source integration is they can get market leading open source security capabilities without the need for context switching or breaking with the SinglePlatform approach that makes it Ladd's dev sic ops. Great. And finally, for white Source, users get less innovative security dashboard and pipeline security improve the experience even further.

So thank you very much for your time today. I look forward to any questions or feedback you want to give will be in the chat and you can give those now or in the future.