Dr. Stephen Magill

Welcome to the Sonatype and MuseDev 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&A starts.

I'm Stephen Magill. I'm CEO of MuseDev. 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 developer point of view. That's my focus now at MuseDev.

Brian Fox

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.

Dr. Stephen Magill

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, some of the factors of what DevSecOps is not, and some of the misconceptions around that term.

I want to start with an analogy. Just like DevOps is a philosophy and a cultural practice more than any particular tool or technique, DevSecOps is also a philosophy: a philosophy of having security really top of mind during development, so that security is just always being attended to.

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. It has the same advantages in terms of efficiency and freeing developer headspace that other things like continuous integration and continuous deployment do. 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.

That's really been our focus at MuseDev: 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 developers.

Brian Fox

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 will cause you lots of challenges and friction in this new environment.

Another dirty truth: just like DevOps doesn't eliminate the need for ops professionals who really understand how to keep things running in production, DevSecOps doesn't eliminate the need for a security team. However, if you do it 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.

Dr. Stephen Magill

Why are we coming together as part of this Vendor Dome? Sonatype and MuseDev focus on complementary parts of the application security space. MuseDev focuses on the application code that your developers are writing. Sonatype's 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 part of your own products. These dual perspectives, looking at the application and then at the libraries the application uses, really let us explore a number of interesting things when it comes to the security space.

One of those we'll actually be giving a talk about later on at the summit. This 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 in those components, and trends over time in how those vulnerabilities are addressed and how those fixes flow down through the software supply chain, and then the impact that has on everyone's 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.

Brian Fox

One of the common mistakes I see pretty often is that people confuse continuous for DevOps. As I mentioned before, merely taking a non-DevOps-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, DevOps is about breaking down the cultural boundaries between these tribes. There's a lot of historical baggage that comes with the typical relationship between dev 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 AppSec comes asking for a change for a security vulnerability, then we see lots of excuses of 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 and a history of bad tools, and it needs to be broken down to be effective.

We've done many roundtables with CISOs that have provided me an interesting ability to see how people think about this. We've seen many times the conversation center around the CISO being unable to convince the CEO to spend more money to hire more security folks. In the typical model, 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 contrasted example I've heard was a CISO 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. 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 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 opposing approaches that we see. The first one avoids truly rethinking the process and culture and tries to just do more of the same. The second really embraces a new model and provides exponential benefits via a cultural shift.

Dr. Stephen Magill

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.

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 has. That's very much our focus: building tools that fit this new paradigm where security and developers have a different, better working relationship and a more efficient relationship.

Brian Fox

We're looking at using Muse's technology in a slightly different context. Many people want to prioritize remediation 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 are 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. We're really excited about that.

Dr. Stephen Magill

Now we're going to hand off to Derek. We're going to have a Q&A session on the topic of DevSecOps and practices and tools in that space. Really, we want to make this a conversation. We want to hear from all of you about what are you doing, what have you found that works well, and what challenges are you facing. Let's have a conversation about how we can work together to help push this philosophy forward and some best practices and learnings that we can all take back with us.