00:00:21

Welcome to the Sonatype and use dev vendor dome. We're going to set the stage and provide some background on the topics we'll focus on here and then kick it over to Derek, to moderate a question and answer session. So as we're talking here, go ahead and send in those questions and we'll be processing them and answering them as soon as the Q and a starts. So I'm Steven Miguel, I'm CEO of he is deaf. I've been working in the program analysis and software security space for over 15 years. First on the research side, doing academic work, building analysis tools, writing research papers, and then more and more focused on practice and really getting advanced program analysis tools into the hands of developers and making this technology much more accessible and much more low friction from a development point of view. And that's my focus now at new step

00:01:07

And I'm Brian Fox co-founder and CTO of Sonatype. My background is in software development for over 20 years. Most of it working on open source Java. I was previously the chair of the Apache Maven project. And for the last 12 years, I've been working with companies grappling with how to use open source effectively to drive innovation while avoiding unintended legal security quality issues that can sometimes follow.

00:01:30

So today we're going to talk about DevSecOps and just really have a joint conversation around the best practices in that space, what you can achieve with those practices, but also some of the myths, right? Some of the factors of what is dev sec ops, not, and some of the misconceptions around that, but I want to start with an analogy. So just like dev ops is a philosophy and a cultural practice, more than any particular tool or technique dev sec ops is also a philosophy of philosophy of having security really top of mind during development. So that security is just always being attended to, and we like to talk about continuous assurance as the term for this practice of just always, really ensuring that you're above your security bar. And it has the same advantages in terms of efficiency and freeing developer, Headspace, that other things like continuous integration and continuous deployment.

00:02:25

So just like continuous integration means you never have to think about setting up integration environments or worry about whether your code will run well with the rest of the system. And continuous deployment means your deployment workflow and testing is fully automated. Similarly, continuous assurance means you don't have to think about your security tooling and which errors are being addressed when it just happens as an almost transparent part of the development process. And that's really been, our focus at muse is developing tools that support this seamless continuous assurance process and bringing security into development in a manner that doesn't get in the way of,

00:03:03

And that gets to one of the dirty truths of DevSecOps. It's not sufficient to simply take a legacy tool and bring it forward with you into a new process. You need to rethink the tools you're using and look for ones that are designed to make their findings more accessible to the entire team. An example would be a legacy security tool that required somebody with deep application security knowledge to simply configure or use the tool and interpret the results. This won't work well when you bring that forward into development doing so because you have lots of challenges and friction in this new environment and then dirty truth, just like dev ops. Doesn't eliminate the need for ops professionals who really understand how to keep things running in production. Dev sec ops doesn't eliminate the need for security team. However, you do have properly bringing tools that are accessible to the entire team. It allows the security team to focus on other parts of the system like identity management, malicious data, et cetera, where they can be even more productive. In other words, by shifting part of the application security problem into development, it can level up the entire team, allowing them to focus on the parts that may not be natural to solve in the development context alone.

00:04:09

So why are we coming together as part of this vendor DOE well, Sona type in music, we focus on complimentary parts of the application security space news dev focuses on the application code that your developers are writing. So in our types tools, help address open source security risk, as well as licensing and compliance concerns that exist whenever you're bringing open source components in and making those parts of your own products and these dual perspectives looking at the application, and then at the libraries, the application uses it really let us explore a number of interesting things when it comes to the security space. One of those will actually be giving a talk about it later on at the summit. Um, let's talk focuses on the open source software supply chain and some research that we've done jointly with gene Kim that looks at open-source components, security vulnerabilities, and those components and trends over time and how those vulnerabilities are a trot addressed and how those fixes flow down through the software supply chain and then the impact that has on everyone security. It also suggests some guidance on what to consider when you're making choices about what new open source dependencies to pull into your applications.

00:05:24

One of the common mistakes I see pretty often is that people confuse continuous or dev ops. As I mentioned before, merely taking a non dev ops native tool and just making it run more often might feel like progress, but it likely doesn't achieve the effect that you actually want. The challenge with that is, as you know, dev ops is about breaking down the cultural boundaries between these tribes. There's a lot of historical baggage that comes with the typical relationship between them and security. This tribalism manifests itself in weird ways. For example, it's pretty typical for developers to upgrade dependencies when a new version fixes a bug provides a new feature, or sometimes just because it's new. However, if apps have comes asking for a change for a security vulnerability, and we see lots of excuses and why this doesn't need to be done, why there isn't time, et cetera, that disconnect has been built up over years of mistrust in history of bad tools.

00:06:13

And it needs to be broken down to be effective. We've done many round tables with CSOM that have provided me an interesting ability to see how people think about this. We've seen many times the conversation center around the CSL being unable to convince the CEO to spend more money, to hire more security folks. And the typical model, the security is a cost center. So they're asking for more money to do more inspections, which looks a bit like buying insurance at a macro level. The contrast that example I've heard was a CSL who said they use their own budget to actually fund the software supply chain for development. This would be the continuous integration, the SCM, et cetera. And they did this because they realized that by upleveling the entire process, not only were they able to actually save the company money by making development more efficient, but that by enabling development to quickly turn around a change like a bug, it also allowed them to quickly turn around a component upgrade, which might remediate a security vulnerability. This is a great example of the two approach opposing approaches that we see the first one avoids truly rethinking the process and culture and tries to just do more of the same and the second, which really embraces a new model and provides exponential benefits via cultural shift.

00:07:28

Yeah. So when you think about tools that enable this shift into a DevSecOps mindset and culture, it's really about breaking down those barriers and enabling security and development to have a different working relationship, providing tools that help security run the scans that they care about, find the issues that they care about as part of development, but don't get in the way of developers. You know, I hear a lot about this perception of security, imposing tools on developers and just sort of laying down roadblocks and things that slow down development and deployment. So when you think about bringing new tools into that process, it needs to be focused on tools that can integrate in a way where that doesn't happen, where they're seamless from a developer's point of view, but they're still addressing some of the concerns that security hats. And so that's very much, our focus is building tools that fit this new paradigm, where a security and developers different, better working relationship and a more efficient relationship.

00:08:29

And we're looking at using muses technology in a slightly different context. Many people want to prioritize or mediation using static code and call flow analysis to determine vulnerable method usage. In other words, they want to understand how likely a particular vulnerable method is to being used in their code. But we're also trying to see how we can leverage that same technology to provide benefits even further left into development. For example, to see if breaking API changes in a component would complicate the upgrade based on understanding which APIs are actually used. This would allow us to make even more precise, upgrade recommendations that informed by your custom code. That's just an example of how we're trying to take some traditional code analysis techniques and make them relevant in a modern, continuous DevOps context.

00:09:15

And we're really excited about that. So now we're going to hand off to Derek, we're going to have a Q and a session on the topic of DevSecOps and practices and tools in that space. And really, we want to make this a conversation we want to hear from all of you about, you know, what are you doing? What have you found that works well? And what challenges are you facing? Let's have a conversation about, uh, how we can work together to help push this philosophy forward. Um, and some best practices and learnings that we can all take back with us.