Does Size Matter? The Difference in AppSec Strategies for Small DevOps Teams vs. Large Enterprises – DevSecOps: Cracking the Code EP2

Hey everyone. I'm Alan Shemel, CEO of Techstrong, and you're watching another episode of Cracking the Code, our podcast devoted to DevSecOps. Uh, before we get started, this is only our second episode.

So let me do a little housekeeping. Uh, cracking the code is a joint production between our good friends at Check Marks and us, their tech strong, and we're gonna be exploring relevant topics, and DevSecOps will include platform engineering, DevOps, AppSec, anything that touches on how are we securing code as we move, as it moves along the software, uh, pipeline, all, all the way through to deployment and even beyond. Um, I mentioned it's a joint production with Check Mark, so if you're not familiar, is one of the leaders in the AppSec market for a long time now, and we're thrilled to have them producing this with us.

Uh, we have an exciting episode to talk about today, but before I get into that, let me introduce you to our panel for today's show. First of all, he's a long time friend. com, probably for the 12 years I've been doing it.

Uh, our friend Brian Dawson. Hey, Brian, how are you? Hey, I am doing well.

Good to be back on with you. And yeah, it's been, uh, it's been, uh, easily pushing on 10 years, so, uh, great to be rejoining the gang here for a bit. I, I think it's every bit of 10, 10 years.

Yes. Um, also joining us from, I guess it looks like she's home in New Mexico. She's the Yeah.

Of Deploy Hub, as well as sort of an open source ambassador extraordinaire involved with several different open source projects and foundations, including Aurelius, the which of which she is the founder of that as well. And she's a regulator on Techstrong, our friend Tracy Reagan. Hey, Tracy.

How are you? I'm doing great, Ellen. Thank you for having me.

And check Mark. Thank you for having me. It's a pleasure being on a discussion that is so near and dear to my heart.

Absolutely. Then last, but not least, is my new co-host for, for, uh, cracking the Cody. He's new to check marks.

We're gonna give him a chance to introduce himself. He's not new to us here at Techstrong, though we've had the pleasure of working with Aaron for years and years. It's Aaron Kids Brenner and Aaron.

Welcome. Congratulations. Tell us what's going on.

You're now a check marks. What's the role? Thank you so much for having me.

A I'm excited to, uh, together with Check Max to sponsor this, uh, uh, podcast. Uh, I have been with Check Max, uh, for, uh, almost a month now. Uh, I, I'm the vp, uh, of portfolio marketing, uh, and also doing a lot of, uh, evangelizing, uh, with the AppSec in the AppSec domain.

So, uh, I'm, uh, I'm not working on a new book as of today, but, uh, who know, who knows? Yeah, That would be great. That would be great.

And of course, you've written books as well. So, Aaron, it's a pleasure to have you on here, and I know you'll bring a lot to our discussion. You, let's jump into today's discussion, if you don't mind.

com 2013, March, 2014, I first published, um, there was a, a raging debate in the community about is DevOps better for large teams, or is DevOps really a startup game? Right? It's great for small teams where everyone's wearing a lot of hats and, and you do kind of do DevOps organically, if you will.

And is there a difference in the DevOps that you do at large organizations versus small organizations? Well, the same kind of arguments in the same sort of divisions, if you will, seem to apply to AppSec and DevSecOps in small versus larger organizations. So, no pun intended, and don't take it the wrong way, but does size matter, right?

Does the size of your team, does the size of your organization dictate a different strategy for what type of AppSec you and AppSec kind of, uh, policies and processes and tools you're going to use? Aaron, I know you're only there a month, but you've been around this game a long time, so I'm gonna, if you don't mind, you are the OPSEC vendor to hear, you've gotta lead us off. What do you think?

So, I think that's a great question, and, uh, actually, I have a lot of insights about it. And you mentioned, you know, uh, a word about scale and stuff like that. Uh, when you're a small startup, and by the way, I'm joining check marks from being, uh, over two years at a startup, right?

Startup is very much focused on a specific software development lifecycle methodology, uh, call it DevOps, it's fine. But when you are at a small startup, we have 7,100, uh, developers, uh, it, it, it's fine. You know, it's good, right?

But let's take, uh, one step, uh, forward and look at an enterprise. I recently engaged with a large financial enterprise, and he told me, you know, our bank is like a museum of software, right? And the museum consists of things from a legacy, uh, perspective, like a huge monorepo of a billion lines of code and different technologies that they still need to maintain and support.

And also modern technologies, microservices, serverless architecture, software, a lot of open source, uh, libraries and the likes. So, uh, it goes with scale, but also maturity, number of customers, different geographies, different compliances that you need to consider when you are obviously, uh, going, uh, big. And then, you know, the number of the development teams that you need to multiply your AppSec program, because within a small organization, you don't need to call it the startup, but with a small organization, you have one dev team, okay?

And this one dev team mostly use one runtime language or two line runtime languages. When you scale to a large enterprise, you can have 100 development teams across a thousand pipelines, across 10 different random languages, Java and Python and JavaScript, and you name it and go, right? So it's definitely the size matter here because you need to support a large, uh, uh, set of development teams, large set of pipelines that are running, and you need to make sure that you're supporting them and also reducing the noise as you shift left your app security, uh, you know, practices, program methodologies.

So, just in the nutshell, uh, that's my thought, Tracy, I'm hesitant to ask you, but what's your take on this one? Everybody needs to do some level of security. It doesn't, I don't think that that the, the size of the organization matters.

We all have to do some level of security, but what does impact us is the size of our budget authority. And not every organization has a massive budget that they'll put into security. And unfortunately, you know, you know, I'll say the, you know, I'll, I'll say what we don't wanna hear, testing and security get put on the back burner when the budget gets cut.

Um, and as you know, you know, we may be headed into a recession. We don't know what our economy's looking like, uh, directors and, and CTOs wanna start cutting back on, on, on technical debt, as we call it. So, what happens is the smaller companies tend to do less te less testing and less security scanning and security practices, regardless of how much they may want to or know that it's important.

So that, this is why I'm so happy to be a part of the open source communities, because we're talking mainly about, many of these problems come from the open source community packages that we're consuming is what's bringing in these, um, bad actors and allowing them to get into our back door. So open source has to fix this, to be quite honest, uh, because every single organization should have the ability to do some basic level of scanning, generating SBOs, and tracking these components as they move into your production environments. Signing, there are so many open source tools right now that you can implement.

The only thing then that becomes an issue is do we have the resources in smaller companies to implement? Because we know a larger company will implement open source tooling. If they don't have budget authority, they'll, they'll go down the open source route to implement as much as they can, but they'll have somebody assigned to do that.

Smaller companies struggle even with that. Um, I'm right now working, um, as much as I can with, uh, satellite companies. I'm really fascinated with the, the satellite market, and you'd be surprised how, um, I don't wanna call it immature, but basic, their software factory floor looks like mo many of 'em are just doing check-ins and then builds, and they don't even have a Jenkins workflow.

So they, they're not gonna be able to do a whole lot in terms of security scanning across the pipeline if they don't even have a pipeline. So it, it's the size of the budget and the team that matters, and what they can achieve with, with very little cash and very little, um, help. And unfortunately, that's what we're looking at in terms of the DevOps pipeline right now and adding security tooling into it.

So size only matters when it comes to budget. Budget matters. You heard it here first.

Go ahead. I'd challenge you through in the only, right, and I, and I'd say it's not only budget absolutely matters. Um, but again, I'll start to frame my background, right?

I've, um, you know, built out software processes for CO with companies of less than 10 companies that were 50 to 150 or, and or have done consulting with companies that were thousands of devs. And yes, budget is a key thing, but there's also, um, capacity and, um, and, and, uh, sort of what I'd say the size of the network of developers that have to communicate and coordinate. So in a startup, it's always a catch 22, right?

I got more work to do than I have resources. I have the same, nearly the same, um, uh, sort of security risk as the largest companies in the world, but I have fewer resources and I have more to do. So, yes, is automation of your app sec, posture of your advocacy, security, posture management critical?

Yes. But how much can you infor afford to invest into getting the optimal, most robust pipeline? Um, and when I say afford, I don't necessarily mean budget.

I mean, in terms of time, not a lot. Um, but what you can and need to do is ensure that you have a base level of automation in place, so you can do more with less. You can forgo some of the, your network is smaller, so you can forgo some of the tools that facilitate knowledge transfer, centralization, cross team coordination.

Meanwhile, you take your larger companies, you arguably have all the resources in the world in terms of capacity, right? You have hundreds, if not thousands of deaths. But the problem is, is, um, you still need to be fast and you need to control spend.

Um, so you're really about overcoming the com, the complex developer network effect, and ensuring that you have, um, central systems, a central source of information. And one of the challenges enterprises struggle with today in terms of AppSec is how do I, at any given time, um, gather a snapshot of the security posture of hundreds, if not thousands of systems that have been deployed? Interestingly, here's what I didn't hear all three of you say that security or AppSec specifically AppSec requirements are different, whether it's a bigger or small organization.

I, as a matter of fact, just the opposite, I think I hear you all say that, you know, there's a baseline of security, which is absolute across regardless of size, right? And, and, you know, there's just no getting around that, if you will. Aaron, you've, I, I've known your career a long time and we know, you know, a lot of kinda where you come from.

Is open source an equalizer here, or are there, can, can the small guy have good security without open source or good AppSec rather? Um, definitely not. Uh, I think open source is key for, uh, putting a security aside.

Open source is, uh, like 70, 80, some would say 90% of our software that we're building is based on open source, okay? Ware checkbox contributes to open source, uh, and does a lot with open source. But the reality also shows, right, that, uh, with the entire software, uh, security supply chain or software supply chain, uh, you need to have a proper security, uh, program that can protect the business.

And going back to, uh, Tracy, you mentioned about, you know, uh, the budgets and stuff, at the end of the day, the budget is one thing, but the business risks, when security impacts the entire organization, uh, whether it comes from open source or other, uh, security vulnerabilities, uh, that's, that's a huge impact, which sometimes might be bigger than the budget savings, uh, that you would consider, uh, putting on an app security platform. Uh, but, uh, with regards to, you know, uh, open source and requirements, you know, at the end of the day, and in the current reality especially, you want to make sure that, uh, and we see it, uh, not just within insecurity, right? You see this shift left thing, you see the power moving more and more towards the developers.

This podcast is even called like DevSecOps, right? The developers today, which by the way, are the ones owning, maintaining, using open source libraries and, and, uh, solutions, they need to be better empowered within their environments, within their ideas. So they can control what they're consuming, uh, per each pool request recommit.

They need to be able to automate, going back to Brian, right? They need to be able to automate this entire security journey from code to cloud, so, uh, everyone is protected and to do so, right? They need to have not just the, the static coordination scanning, they need to have, uh, SCA, they need to have repository health, uh, uh, checks.

They need to have secrets. Detection, secure up. Security is a wide thing, right?

And with open source, you have all these, uh, security vulnerabilities can, that can be exposed to your, uh, repository, right? All the seekers that you're dealing with, all, uh, the, the, uh, software compo composition analysis within check marks. We have analyzed over 400,000, uh, malicious packages that we detected over the past years, right?

So it's all comes to culture, it all comes to this shift, left and empowerment. And also going back to Tracy, also looking at the production, right? What happens when the code is being deployed with the open source components and the likes, right?

How do you manage, uh, and get this A SPM view also within your development environment, so you continue moving on fast? Absolutely. Aaron, You So let me respond to that too, Alan, what you just said.

Okay, so everybody has to do security, right? But how much security do you need to put in if you are a small company versus a large, we have to think about it in terms of the attack surface, or what I like to call the blast radius, which I've said many times, and no, we're not gonna toast every time I say blast radius. Sorry, You did that.

No, sorry. You remember, Because when you're talking about a, you know, a modernized, um, application, a cloud modernized application, you are going from one binary or a one build that's building all your binaries. And you might even generate a single s om for all of this, that you're building 'em at one build to a decoupled environment where a single package vulnerability could be living in literally thousands of containers within your environment.

So you're not just fixing one binary, you're gonna have to fix every single container that has that, that, that, that, that vulnerability in it. When you're a smaller company, your blast radius is smaller. When you're a larger company, you have a lot to do.

You have a lot of places to update that, and it becomes more impactful. Um, a smaller company can be more agile. They can fix this, uh, quicker.

Larger companies aren't as agile, they're gonna take longer. Right? Now we're looking at a, a good example is according, I think Sonatype, uh, state of, uh, software security report indicated that we have 185 days for the government to remediate a vulnerability, a hundred days for private sector and 10 days for a a, an attack, a, a, a hacker to exploit that attack.

Yeah. So the small company can, if they know that they have the vulnerability running in production, right, they can, they can get it fixed, the larger company can too. It's just gonna take them a a lot longer to do it.

So that is why they need to make sure that they're spending money on SaaS and das and hopefully understanding what a, uh, uh, evidence catalog is and being able to continually scan for vulnerabilities after production release. Because we often think, well, we're gonna fix everything and shift left, but we do all this work, and then tomorrow there's a new vulnerability in something that we just released, and sometimes we're completely unaware of it. 'cause we're not be able to, we're not able to map that low level package to an endpoint.

So we have the situation where small companies have less exposure because they have, they, they're pushing it out to a, maybe a smaller group of, of end users. Large companies have more containers to manage, and their, and their impact, their blast radius is far wider, far wider than a small company could ever experience. So we do have a difference.

So size does matter when it comes to remediation. So, But I, I, you are right. It does, and I think to not acknowledge that it's wrong, but it also depends, A small company in, in finance or healthcare probably has a higher profile to be attacked security wise than a manufacturing company or some other run of the mill kind of company.

So I think there are mitigating factors beyond just beyond just size, if you will, right? Beyond just this, how many developers you have, or how big a company your revenue is, or employees or what have you. Aaron, you, you started something in this, in your last comment.

You started naming some specific AppSec tools. And it's funny because look, I, I've been in security since before there was a thing called AppSec, right? Mm-hmm.

And, um, originally AppSec was just sort of doing, you know, the, the, uh, the, the A scan das, you know, no, excuse me, not das static scan, not the dynamic scan. Yeah. Right?

And, and, and, you know, white Hat Security, my friend Jeremiah Grossman first started doing it as almost like a SaaS model. Before that you would come in and, you know, HD Moore and the guys. But the, the bottom line is today, AppSec is, so, there's so many different aspects and different tools within each specialty of AppSec.

AppSec has become an umbrella, right? Even just scanning, for instance, as I mentioned, it was static scanning, then we had dynamic scanning, then we had SCA software composition analysis to open source comp scanning. And then every company has their own little take on I SaaS and this SaaS.

And that sa you know, you know, Aaron, you've been in this business. Um, and that's just the scanners. Let's, if, if you don't mind, we'll put together a list of the different AppSec tools, and then we could talk big org, or is it really geared towards a little org?

Now, Tracy, I, I know, you know, you'll work with the OSSF and so forth. So beyond the scanners that different kinds of scanning that I mentioned, what else falls under this AppSec umbrella today? Waf?

Is WAF still a thing, Aaron, or has it gone away already? So, uh, from, from what we are seeing in the market from check marks, uh, we are focused on, uh, you know, the most advanced engines for scanning. So you mentioned SaaS dust, uh, like quantum security.

Uh, we are looking and very much focused on software supply chain security, which include, you know, uh, also SCA under underneath, but also secrets, detections, uh, malicious packages, repository health and these kind of things. And then you also have, uh, what we call AI security that, uh, yeah, that there wouldn't be a show without mentioning ai. But, uh, AI is not new, you know?

But it definitely starts to penetrate, uh, within the AppSec, uh, umbrella of tools. And that's exactly, you know, to the points of, uh, Tracy, you know, we talked, we talked about shift left, but definitely making sure that whether you are a small organization or large, you know, your developers can, uh, find and also fix security vulnerabilities as soon as they're writing the code. And if they're not trained, we know that developers are not security experts, and they're sometimes using either AI security generated code or, uh, you know, other open source libraries being able to meet the developers where they are and empower them with AI as well.

What, that's exactly what we are seeing nowadays is something that, uh, we see a lot and contribute a lot and plan to do a lot, uh, in, in the future. So, uh, it's a mix of the traditional, which are very important tools, stress and dust, and, uh, SCA, but also a SPM, uh, with dashboards and correlation from runtime production and ai, uh, security remediation, and, uh, even guidance, you know, uh, education for the developers as they're writing the lines of code Fair. There's, then there's a lot there, right?

There's this, there's A lot there. Tracy, what, what's your take on that? Well, So you, the first question you ask is, what else do you need, right?

So I'm gonna, I'm gonna plug, um, in one of the special interest groups that the Continuous Delivery Foundation is currently working on, in fact, their meeting is happening as we speak right now. Um, it's called the CICD Cybersecurity sig, and it's with the Continuous Delivery Foundation. It's not a best practices.

It's basically the process of going through some of these, uh, defined frameworks. We're starting with the Secure Software Development framework, and we're going through each of the tasks associated to the, uh, the secure Software development framework. And we are assigning to that task, open source tools that can be used to achieve it.

This allows, uh, anyone who wants to, uh, build a DevSecOps pipeline to do so with open source tooling and be able to achieve, as, you know, a secure software development framework. The next step will be to start looking at, um, the, uh, uh, cybersecurity framework, the CIS cybersecurity, the security framework, and cross reference it over to the software, the Secure Software Development framework, and also identify what you need to do in order to achieve that. So there's quite a bit, let's just talk about SBOs, right?

SBOs are really, are needed, but, you know, I wrote a blog once called SBOs. So far so good. So what, because if you're not consuming 'em, they don't do anything for you.

And that's what Orillia is about, is consuming the SBOs and aggregating it up to the higher levels when you're in a decoupled architecture. And then I'm gonna do one more call out, and this is to all the developers out there who are writing open source packages, the spring people, you know, um, all, all of these open source packages that we rely on, every single one of you need to be able to show an open SSF scorecard value. Because if you're not, what you're saying is, I'm not interested in being compliant, and we know that you are.

So let's start. We, we need to have those open source packages. Have an open SSF scorecard value, because me, me, as a consumer, I wanna know that you're doing at least signing right?

I wanna know the basic level that you've achieved, get to get it to a level five if you can. I know it can be hard, but it's so important, and it just means you're using open source tooling to protect the open source packages that you are delivering to thousands and thousands of consumers worldwide. Yeah.

I, I, I'd like to jump in, uh, there, shoot, there's a number of things I'd like to jump in on, but, but sort of trailing off of, uh, you, Tracy is, you know, or this question that we started with a bit ago. How important is open source? Um, uh, not only do we already know that open source is, uh, critically important to us being able to build and deliver the software that we do today, but in terms of using open source tooling, um, to improve and maintain your AppSec posture, it is also critical.

Again, when we talk about small teams, a number of the tools that they build, that they, uh, put together and they bring into their DevSecOps pipeline, they automate within their orchestration process, are going to be based on open source, um, tools. Now, one of the things that I would say open source tools do at this stage in terms of open source security tooling standards and frameworks, and let's be clear, um, uh, you wouldn't have, uh, your CVE databases, you wouldn't have of, of, of, um, of, uh, proof of concepts. You wouldn't necessarily have, uh, many remediations if it wasn't for open source software, open source, standard buddies.

Um, but, um, look, there are attackers up 24 7 and now accelerated with AI today, um, that are trying to attack a small company with 12 developers and 80 employees overall. Um, uh, I cannot rely on a small set of developers with a commercial tool to do that. I need open source that has the expertise and input of, uh, decades of experience and experts, right?

Um, I would also extend that becomes even more important for small companies when, um, uh, you realize that look, today, um, attackers don't have to necessarily pick their highest value target with the acceleration and speed of AI to quickly identify what vulnerabilities are out there, have AI craft exploits for them, and then have AI go out like a bunch, you know, AI bots just go out and attempt to attack places, right? Attack people, compromise them. Um, um, you no longer as an attacker have to, uh, uh, prioritize a large company versus a small company, right?

Yes. A small company may be more aware, they may be able to respond faster. Um, but I'm gonna attack my 200, 300 person software technology company, um, uh, uh, uh, across the board of the long tail, um, just as vehemently as I'm going to attack our big mega Fortune 1000 companies.

Absolutely. You know, Brian, I I remember back to your CloudBees days, one of the interesting things about CloudBees is back then, you know, they were the Jenkins company, right? People who were using Jenkins, which was probably the most popular CICD tool, and still is.

Yeah, I was gonna say, our friend Mark, wait, would say they still are, right? They still Are. But CloudBees had figured out when was the time to move from the open source Jenkins to the CloudBees enterprise, right?

Yes. Was based upon how many pipelines you had, how much, you know, you were publishing in instances of Jenkins and so forth. Yeah.

And it really was a size issue, right? How many developer teams you had. Yeah.

Right, right. Can't we come up with some sort of formula like that for, for some of this AppSec stuff, or is it, 'cause it, I get, I appreciate Aaron, everything you've said, Chay, you, you're an expert on this. There's no, I think I'm afraid people listening or watching this at home or saying, my God, that's a lot of tools, what my, if I'm a, do they really expect a small organization to have all those things?

I was, I was kind of saying, yes, we do sort, at least on the scanner side of things, yes, we do expect small organizations to have them. But, uh, go ahead, Eric. Sorry.

No, I, I I'm just saying that, uh, the number of tools doesn't need to scare anyone as long as they're kind of unified under a single platform that allows you to automate and Buddhist, uh, shift left, serve both the developers and the CSOs within the organization with A SPM dashboards and the likes, then it's baked into the process. You mentioned Viss, you mentioned CICD, you know, you have all the, uh, SCM tools, right? If as a practice within your software development organization, developers are, you know, uh, plugging this engines, does this, scan engines upon each commit pull request that they're doing, you know, then everything aggregates, uh, and everything being propagated to the same dashboard, to a single dashboard to unified view, which gives you kind of a risk mitigation dashboard.

So at the end of the day, uh, as an executive, as a cso, as a decision maker, you don't really care. Yeah. Wow.

I've learned 10 different tools. You can run 20 tools as long as they can, you know, give you a single, uh, pane of glass, a single point of view of your security posture. How is your, uh, you know, open source components?

How is your entire, uh, software portfolio, uh, secured when it be, when it's being deployed to production, deployed to the market on a continuous, uh, you know, manner? Because, uh, Alan, you might know from my previous books, I was always saying software quality and software security is always a moment in time. Today you are safe, tomorrow you aren't, okay.

So it's, in my mind, doesn't really go down to the number of tools. It goes down to the culture, to the process. How can you automate, how can you, uh, present, you know, your current status, uh, at any given point on demand?

Well, And, and if I, if I may jump in and add, I'd say this is the point though, where we talk about, again, a 50 person development shop, um, doesn't have the necessary or cross team communication, um, uh, coordination complexity, right? So, um, they oftentimes you can focus more on integrating the scanning tools and standard security tools into your delivery pipe delivery pipeline. Don't try to do everything everywhere, all at once.

Rather, prioritize and stepwise integrate these to fortify your delivery pipeline. Now, did they have the same need for an enterprise grade, um, dashboard, right? Or organizational view?

No, not necessarily. They may be able to pump the results into Jira or Confluence, and everybody has a standard dashboard they can read there. Um, I'd also say, for example, to get in vulnerability patch management, right?

Um, that is a great, we've done scans, we've shipped software or vulnerability is discovered after it's shipped. We one gotta find that vulnerability. But as Tracy said, how the heck do we figure out where it's deployed and fix it?

Not the same level of problem at a small company. So they may be necessarily, don't they need, uh, vulnerability detection tools. They don't necessarily need management and remediation, for example.

And, uh, Alan, your point is well taken though. Um, and I'm gonna, I'm gonna harp on something I've been harping on for the last several years, and I'm so frustrated we haven't fixed it yet. And that is that our pipelines are very brittle.

And in order to implement this, we have to visit thousands, literally thousands of workflow files, Jenkins workflow files, you know, whatever, you know, harness whatever you're using. And that is cumbersome, and it takes a long time. So if you wanna add, you know, something as simple as an sbo, you've got a lot of work to do to generate an SBO for every container that you have in your workflow.

Um, we, we should have several years back, uh, we as the industry, um, the CD foundation was working on something called CD events to get rid of plugins and be able to have a more streamlined workflow process so we could add these tools in a much more efficient way. The, the CD events team did amazing work on defining requirements and the, um, kind of what the payload looks like, the inputs and outputs. But we didn't, none of the giants, none of the, I call the, you know, the IBMs, the Apple, the Google, the Microsoft really embraced it and w and put enough money into it to make it real.

But now maybe it's, maybe there's a reason for it. There always is. Uh, we have AI now and in the Textron gang, um, last, uh, I think it was, um, would've shown yesterday, I think we talked about, uh, model context protocols, which is a way for you to, it, you know, it's anthropic developed it, and it allows these models to use, um, data coming from multiple locations, you know, context from multiple locations.

When I, when I learned about that, all I could think about was how appropriate that would be for a DevOps pipeline, because it allows us to see in a better way what that pipeline is doing and how mature it is. If, if it gave us a way to automatically update that pipeline to include SBO M generation, at minimum, we would be making huge strides in solving this problem. So maybe there's a future for us that's not quite so brittle.

Um, and that, that part of being brittle is what keeps larger organizations from achieving a strong security profile. Um, because they've got millions, literally, they've got thousands at minimum thousands of workflow files to fix. Fair enough.

Aaron, I've got the last topic I wanted to discuss, and it's really things at you and check marks. I know check marks a long time. Check Marks prides itself on being an enterprise solution for AppSec deal with some of the biggest enterprises in the world.

Does size matter to a security vendor, right? Is your solution so tailored to enterprises that the smaller guys don't benefit from it, or does it fit all sizes? That's a good question.

Uh, so, uh, as, as a general statement, uh, checkbox fits every size of organization, specifically with enterprises in mind, going back to the, uh, beginning of this, uh, session, I think that, uh, they care a lot about what we have to give them because of, you know, the different scales that they're hoping with the amount of developers that are sometimes putting Dell business at risk. Okay? Thousands of pipelines, multiple applications, different cloud providers, right?

At any given enterprise, uh, application might be deployed on a Google Cloud, Azure, uh, AWS, uh, different deployment engines, different tools, different runtime languages. So the, the portals that we, uh, talked about earlier, which are maybe, uh, small, within a, a small organization, you can multiply them by a thousand or even more. And that's kind of the headache.

Uh, recently we have, uh, done a, uh, a webinar with Michaels, Michael Stall, uh, stall in, in the us right? Large retailer, everyone knows them. And the CISO over there, going back to your point and told us, you know, that he believes, uh, in the trinity of architects, that's how he thinks about a good software security program in which, uh, a tool or a platform like check marks can serve both the developers early in the cycle, the security engineers, the security analysts, as well as him as the cso.

So each gets what they need from an objective perspective when they need it. Okay? So definitely, and enterprises care about, uh, platforms such as check marks, because again, the scale of problems, the risk that is, uh, you know, in front of them is huge.

And they need also to be able to gain trust, uh, in the swap of the, uh, development lifecycle, but also noise we haven't mentioned, uh, in this entire discussion, the word noise, we didn't mention asbo. Sometimes people would say, yeah, ASBO might create too much noise, more false positives, uh, and, and the likes, right? So, uh, think about this size or the, the, the, uh, uh, let's say size of noise, because we are talking about the size in this chapter.

So the, the noise within a larger enterprise when it comes to so many different pipelines, so many different ASBOs, so many different, uh, deliverables, you know, that's the headache that these C-level executives need to cope with. And that's why they need this single pane of glass, this, uh, enterprise grade architecture platform, uh, uh, et cetera. So I hope I addressed the, uh, the question.

Ellen, I think you did, you, and good work with that, Tracy. You know, you sit on these open source councils and Aurelius and SBOs and so forth. Does the size of the vendor matter?

That's a good question. I think, uh, uh, I mean, from being a small company, I can tell you yes, it does, because they wanna take, they don't wanna take a chance on a small company, even though you might have a superior product. So the size of the vendor can, And you know what, Aaron, Aaron has been on both sides of that fence, right?

Yeah. He's, he's one of the big boys, and he's done the startup. I don't mean boys, the big companies and the startups.

Yeah. And he confirm and, you know, just, just, just, uh, just, uh, branding and awareness, right? How do you get that out when you're, you're a small company, so it kind of does.

Um, but in terms of the product delivered, um, I'm not sure, because you can have a startup that has a really devoted, hardcore team that's solving problems that maybe a larger company hasn't seen. So I think you should always keep an open mind. Small companies can do some amazing things.

Oh, Yeah. Yeah. And I, and I, look, I think sometimes if you're a small company looking to engage with a vendor, you may have a harder time, and I know this wouldn't be the case with check marks getting the attention, um, that you need from a large vendor.

So there's gonna be times as a small company that you're better, um, engaging with a software security vendor that can act as your partner, which, you know, when we go back to one of the roles CloudBees played it mm-hmm. Um, in, in, in its early days, was they were a small company that became a partner of our customers. And just remember, log four J was managed by one person, and everybody who had a Java application in the world used it.

So there you go. That's funny. Yeah.

Well, you know how that turned out. Yeah. One way to end it.

Tracy. Bryan, thank you so much for being our guest on this episode of Cracking the Codes. Aaron, I am thrilled to have you on here.

You know, it's good to have, actually, it's good to have someone who has the experience comparable to mind, and, and you know, we booked it through the, the block a few times, so this is gonna, we're gonna have fun times here. I'm looking forward to it. Likewise.

Thank you so much for having Me. Thank you. If you've watched, if this is the first time you've watched Cracking the Code, it's available.

I don't know where you're listening or watching it, but it's on YouTube. It's on all of your favorite podcast channels, apple, Spotify, Stitcher. It's on Techstrong tv, social media.

Uh, there'll probably be cuts of this available as, uh, on various platforms as well. The most important thing is subscribe and watch it. We'll be doing it every other week religiously.

And, uh, we're going to, we've just scratched the surface. We got a lot to go into. Thank you all.

This is Alan Hummel for Techstrong. We're out.