Artwork

เนื้อหาจัดทำโดย Datadog เนื้อหาพอดแคสต์ทั้งหมด รวมถึงตอน กราฟิก และคำอธิบายพอดแคสต์ได้รับการอัปโหลดและจัดเตรียมโดย Datadog หรือพันธมิตรแพลตฟอร์มพอดแคสต์โดยตรง หากคุณเชื่อว่ามีบุคคลอื่นใช้งานที่มีลิขสิทธิ์ของคุณโดยไม่ได้รับอนุญาต คุณสามารถปฏิบัติตามขั้นตอนที่อธิบายไว้ที่นี่ https://th.player.fm/legal
Player FM - แอป Podcast
ออฟไลน์ด้วยแอป Player FM !

Shift Everywhere with John Steven

39:06
 
แบ่งปัน
 

Manage episode 284605270 series 2805034
เนื้อหาจัดทำโดย Datadog เนื้อหาพอดแคสต์ทั้งหมด รวมถึงตอน กราฟิก และคำอธิบายพอดแคสต์ได้รับการอัปโหลดและจัดเตรียมโดย Datadog หรือพันธมิตรแพลตฟอร์มพอดแคสต์โดยตรง หากคุณเชื่อว่ามีบุคคลอื่นใช้งานที่มีลิขสิทธิ์ของคุณโดยไม่ได้รับอนุญาต คุณสามารถปฏิบัติตามขั้นตอนที่อธิบายไว้ที่นี่ https://th.player.fm/legal

In this episode of AppSec Builders, Jb is joined by security expert, John Steven, to discuss his BSIMM study findings, the fundamental shifts in AppSec, software-defined security governance, and much more.

About John:

Linkedin: https://www.linkedin.com/in/m1splacedsoul/

Twitter: https://twitter.com/m1splacedsoul

Through his firm Aedify, John advises innovative security product firms as well as maturing security initiatives. John leads one such firm, ZeroNorth, as CTO. For two decades, John led technical direction at Cigital, where he rose to the position of co-CTO. He founded spin-off Codiscope as CTO in 2015. When both Cigital and Codiscope were acquired by Synopsys in 2016, John transitioned to the role of Senior Director of Security Technology and Applied Research. His expertise runs the gamut of software security—from managing security initiatives, to cloud security, to threat modeling and security architecture, to static analysis, as well as risk-based security orchestration and testing. John is keenly interested in software-defined security governance at the cadence of modern development. As a trusted adviser to security executives, he uses his unparalleled experience to build, measure, and mature security programs. He co-authors the BSIMM study and serves as co-editor of the Building Security In department of IEEE Security & Privacy magazine. John is regularly invited to speak and keynote.

Resources:

Latest BSIMM

Aedify Security

Concourse Labs

Transcript

[00:00:02] Welcome to AppSec Builders, the podcast for practitioners building modern AppSec hosted by JB Aviat.

Jb Aviat: [00:00:14] So welcome to this episode of AppSec Builders. Today I'm proud to interview John Stevens. So, John is the founding principle at Aedify where he advises product security firms. John, before that, you led ZeroNorth as a CTO and before that you were leading as co-CTO at the Cigital firm. Welcome, John.

John Steven: [00:00:36] Hello, how are you? Thanks for having me.

Jb Aviat: [00:00:38] I'm great, thanks for joining. So John, another thing that you've done is that you co-authored BSIMM, so could you let us know what it is and how it can be a useful tool to AppSec builders?

John Steven: [00:00:50] Yeah, it's worth clarifying because it's frequently misunderstood. The BSIMM is the building security in maturity model observational study. We went out and over a period of 11 years we've studied about two hundred and over two hundred firms and asked the question, what do you actually do to build your security initiative and to secure your software? And it doesn't prescribe what to do, but you can use it to look at what firms that are within your vertical or that look similar to you in terms of maturity, are doing with their time and money, and decide whether or not you want to replicate those behaviours or cut your own.

Jb Aviat: [00:01:29] So you are interviewing like CISO application security practitioners, developers like every actor of the security game.

John Steven: [00:01:38] Yes. Historically, the list has looked like what you described. What was interesting to us about the last two years of this study is that when we began talking with the CISO, they'd say, oh, you need to talk to the VP of Cloud on this, or actually you need to talk to the SREs and to to delivery or to the VP of engineering. The people we had to talk to fundamentally changed over the last two years. And that was a key finding that we we wrote about this year, that the people doing the work of security were shifting from the security group to the engineering, digital transformation and cloud groups.

John Steven: [00:02:20] And that's a big deal, right, because there's been these phrases that we've held dear for 10 years or more. You know, building security in is something that we've said for two decades. Me and a colleague argue as to who said shift left first and we've ended to like November of 2001 when we first said that. It was a long time ago. The other thing we say is that security is everybody's responsibility. Every developer, every engineer, every operator needs to think about it. And we've been harping on those things forever. And what we see is now that engineers, now that SREs, now that operators are taking a really first class citizen role in security, people are taking that 'security is everybody's responsibility' to heart. And in fact, who makes up a security initiative has now changed. And that's a really big deal.

Jb Aviat: [00:03:08] Yes, it is. And so a trend that we have seen over the past two years is like QA testing moved from dedicated teams towards the hands of developers and they are now writing their own data and then monitoring their own deploy, running back if necessary. And so what you describe about security is following the same trend, right? So the teams are now starting to own security by themselves.

John Steven: [00:03:35] Yeah, and we see what we call engineering-led security initiatives, where engineers are not only acting as security champions and participants in a program, but the owners of practice areas and the drivers of the program. So it's not uncommon in some organisations, particularly ISPs, that are more mature, for them to have a Product Security Lead or a Chief Architect who has full purview and responsibility for security and for those people to do the things that you'd expect the security group to do prior. Pick defect discovery tools, tune those tools and drive to a secure coding standard, you know, generate and administer a training program associated with those standards and those tools, you know, and build security blueprints and so on and so forth.

Jb Aviat: [00:04:22] And so you mentioned shift left. So now what I understand is that you are not like advertising shift left anymore. So, due to this change in the industry, now that security is done to be done by people that are actually conceiving and building the things.

John Steven: [00:04:41] With the benefit of time, anything, anything will look wrong, I suppose. So, you know, when we talked about shift left, we were thinking about all of those organisations that use spiral or iterative development or even worse, waterfall. And, you know, we would talk about, look, you know, we can pentest your software, you can apply testing to your software. But wouldn't it be better if you moved earlier in the lifecycle and found those bugs as you were developing them so that they were easier to remediate? And that was the basis of shift left and everybody cited the rational study and it's cheaper to to fix things earlier and yada, yada. You can see why that's a valuable precept. But think about how orchestration platforms and how software delivery has changed over the last five to seven years. We're using Kubernetes you know we've changed the way virtualization has happened. We're layering on top of Kuberntes things like Istio. More and more of the way we deliver software is becoming code, and the whole infrastructure is code movement and the whole delivery and pipeline orchestration movements. What that means is that more and more of the stovepipes between build, test, deliver and operate are being broken down, so that a DevOps engineer can shepherd a greater percentage of the software lifecycle in self-service mode. I don't have to hand something over a wall to you. I can walk it further down the lifecycle pipeline myself. And even the the bridge between Dev and prod is becoming a softer wall than it has historically been.

John Steven: [00:06:26] Cloud, open-source, all of these are self-service technology stacks that allow you, again, further control over a larger percentage of the lifecycle. And so what that means is that code is creeping right in the lifecycle. When you use Kubernetes Istio configuration files, when you use infrastructure-as-code, cloud service provider configuration, what you're doing is you're driving that code right in the life cycle and saying more and more of the way I build, package, deliver and operate is going to be software defined. So more accurate than shift left is maybe shift to where the code is. And what we're seeing is that the code is shifting right. So your know my keynote of the BSIMM conference two years ago was shift right to do security everywhere. And it was extremely aggravating to the attendees because after two decades of moving to the left and trying to get closer to design and requirements, I mean, Laurie Williams out of North Carolina has published a study that says that as much as 10, 11 percent of your code may be infrastructure-as-code and that 30 percent of the churn, month to month in your code bases, is that code. So there's data based evidence that says that that code is moving right.

John Steven: [00:07:42] And so we must move right with it if we want to get earlier. And so this is really never REST. Your security initiative needs to follow the trends in technology and respond with the same principles, get earlier, re-evaluate how those principles apply to the new tech stack. Does that makes sense.

John Steven: [00:08:04] That's fascinating. So shift left, she right or shift to where the code is but there is not only code, right. At some point we need to go beyond because as careful as you are when you design a system, when you when you write your code, there may still be vulnerabilities left or any flaws of any kind. So monitoring the code is not enough.

John Steven: [00:08:28] That's right. So when you talk about shift left or shift everywhere, you're talking about proactive or building security and telemetry. The thing the capability you're trying to to build for your organization is deliver better software with fewer security flaws. But to your point, you're not, it turns out, I know this is going to shock everybody. You're not going to deliver perfect software. Not the first time. Not the tenth time. I think we can all conclude that software will have flaws in it. And so some organizations are saying rather than infinitely iterating my security practices, taking on cost and taking on complexity, maybe I listen to those people in my organization who are focusing on speed of delivery and agility and apply some of that same concept to my security initiative. What if instead of slowing people down to build better software, I participate in their desire to deliver software faster and build resiliency into my security capability. And that speaks to what you're saying. You not only have to proactively find defects and fix them, you have to observe potentially malicious or vulnerable behavior and do something that will make you resilient against that exposure.

John Steven: [00:09:48] So people are saying, if I can combine a 'building security in capability' with a resiliency capability, I'm going to have a much more robust security program. And instead of my costs becoming infinite on the building security inside, I'll have a balanced approach where I will do the best job I can to deliver and I will have a very confident ability to respond when I get risk telemetry based on behavior and operations and I'll pick where I'm going to solve a problem. Because, you know, when we cite the rough model, we're sort of oversimplifying. There are definitely problems that is cheaper to find based on their production shadow than in requirements. And so having resilience where you can redeploy in 30 minutes based on what you observe is terrific. And what this has driven for security initiatives is a technology challenge. How do I combine my building security in telemetry that comes from legacy tools, like static analysis, dynamic analysis, composition analysis tools, with my observational tools that are post deployment operational?

John Steven: [00:10:58] And most importantly, how do I inventory the bits and bytes that are running and map them to the bits and bytes that created them both in terms of the artifacts that go into creating them and the pipelines that create them. How do I tie the people responsible for operating these pieces of the infrastructure and developing and delivering those same pieces of infrastructure? And then how do I know what my code looks like in my service mesh, in my network and those things and identity look like. And so there's been a whole set of obviously technologies, and this is a space you guys play in during the day, where firms are trying to help organizations understand how to tie those disparate pieces of telemetry together so they can see the full picture and then choose how they're going to decide to respond to risk. Are they going to look at operational data? They're going to look at data from the software development lifecycle, or are they going to combine pieces of telemetry and they make an action based on.

Jb Aviat: [00:12:00] Yes. So I'm aware of tools that do that to the left on the code part, so I'm sure you have a GitHub or GitLab in mind, when we mentioned gathering data at code level or deployed at the CI level. So those companies GitHub, GitLab they are every day, more and more like security vendors, because they offer more and more like amazing security features and are very well placed to do so. But on the other hand, for the monitoring, the runtime, for the prediction path do you see tools that manage to aggregate those information from the left path and from the right path.

John Steven: [00:12:35] So GitHub and GitLab are definitely the 800 pound gorillas in this space. Both of them, in my opinion, doing a great job defining the bones of a security framework for these engineering led initiatives. They're saying you need defect discovery capabilities, so we'll help you plug those things into your pipeline, we'll route the vulnerability or defect data to the right developers. We'll track those change requests and track dora metrics like time to fix. They're doing a great job of that platform and the scaffolding. Those platforms coalesce around code, right? Theyre SEM platforms, right. So they're always going to do a better job on the builder side. Some of them are introducing features that speak to proto operational stuff like security research in and out, like bugcrowd or that stuff that goes in and out, security advisors to go out, crowdsourced defector vulnerability data comes in. They're not credible, in my opinion, yet, on the operations monitor telemetry side. You know, obviously there's a bunch of vendors that handle that. I mean, there's there's vendors that handle it from an aggregate telemetry perspective, the zeronorth's of the world, there's people that handle it from the testing perspective, like IAST vendors.

John Steven: [00:13:46] There's there's certainly people like Sqreen that handle it from the RASP perspective and the instrumentation protection side. You know, what I have said about that is that, to investors, to buyers, is a lot of these technologies that are doing the aggregation that act as sort of competitive peers to GitHub and GitLab on the aggregation side, they're pretty early days. Right. And the challenge with that is that how many security tools are there? You know, there's massive fragmentation on a legacy stack. Gartner thinks you need 10 to 30 tools on the cloud stack to get a clear picture of your, and that's just essentially one cloud. You know, there isn't any sort of de facto standard reporting format for these vendors to use in aggregate to. Right now, people are spending a lot of time either using a Series A Series B maturity technologies and making progress in that space or building their own. And in fact, in an adjunct study that I did, which was not published, but there was a compendium to the BSIMM called the DevSecOps study. We found that a third of BSIMM firms have built their own aggregator and have tried to plug it into their particular Frankenstein tech stack of GitHub or whatever. And shockingly, those firms that have done that have spent on average eight to ten million dollars building defect vulnerability management, slash aggregation technologies. So this is a really interesting space, it's sort of at the nexus and fulcrum of your capability to provide resilience, but it's a space right now where you have to pick a vendor. You could build your own, I don't think that's the right move, potentially, but you have to pick a vendor and kind of co-evolve with them.

Jb Aviat: [00:15:28] So sometimes you have new vendors. And so we did Y Combinator in 2018. And so we interviewed like 150 different companies during that during our batch. And we had an idea and we found that so many companies had built it already that we had a doubt, like is everyone building that in-house? And that's how we we pushed our playbook capability. But so that's something that was so widespread and it feels so far away from the core business of those company that it was really hard for us to believe that so many companies had built it already. So I perfectly understand what you mean. And so each time we are as a security vendor, when we are exploring a new feature and we always find customers that have built that already, and no matter what is the complexity, you have some specific needs that are not addressed today in the industry and a lot of companies are holding their own. So, a third, that goes with that. Intuitively, I would say the same thing.

John Steven: [00:16:26] At Synopsys, one of the things that I did was sort of manage the acquisitions of the portfolio a bit. And one of the spaces I looked at, pretty aggressively, was RASP. And of course, at the time, three years ago, RASP and IAST were more intertwined than they are today. And still vendors intertwine those notions. One of the things I'll say about this DevOps dichotomy is that you do have a specific and hard choice to make. And you see people struggle when they try to hedge that it does fall on one side or the other. When you build and you guys probably know this, when you build telemetry technology, you have a choice as to whether or not to make it fast and robust or whether or not to make it thorough and give you good telemetry on provenance and other things that help you debug. In other words, you can build a developer tool that provides visibility or you can provide an operator tool that hardens and provides audit capability. It's extremely hard to build something that does all of those well. You have to pick: fast and hard or slow and visible. And trends like IAST or similar that try to drive, you know, sort of visibility into production, I think are challenged because one, you know, they don't end up fulfilling...

  continue reading

7 ตอน

Artwork
iconแบ่งปัน
 
Manage episode 284605270 series 2805034
เนื้อหาจัดทำโดย Datadog เนื้อหาพอดแคสต์ทั้งหมด รวมถึงตอน กราฟิก และคำอธิบายพอดแคสต์ได้รับการอัปโหลดและจัดเตรียมโดย Datadog หรือพันธมิตรแพลตฟอร์มพอดแคสต์โดยตรง หากคุณเชื่อว่ามีบุคคลอื่นใช้งานที่มีลิขสิทธิ์ของคุณโดยไม่ได้รับอนุญาต คุณสามารถปฏิบัติตามขั้นตอนที่อธิบายไว้ที่นี่ https://th.player.fm/legal

In this episode of AppSec Builders, Jb is joined by security expert, John Steven, to discuss his BSIMM study findings, the fundamental shifts in AppSec, software-defined security governance, and much more.

About John:

Linkedin: https://www.linkedin.com/in/m1splacedsoul/

Twitter: https://twitter.com/m1splacedsoul

Through his firm Aedify, John advises innovative security product firms as well as maturing security initiatives. John leads one such firm, ZeroNorth, as CTO. For two decades, John led technical direction at Cigital, where he rose to the position of co-CTO. He founded spin-off Codiscope as CTO in 2015. When both Cigital and Codiscope were acquired by Synopsys in 2016, John transitioned to the role of Senior Director of Security Technology and Applied Research. His expertise runs the gamut of software security—from managing security initiatives, to cloud security, to threat modeling and security architecture, to static analysis, as well as risk-based security orchestration and testing. John is keenly interested in software-defined security governance at the cadence of modern development. As a trusted adviser to security executives, he uses his unparalleled experience to build, measure, and mature security programs. He co-authors the BSIMM study and serves as co-editor of the Building Security In department of IEEE Security & Privacy magazine. John is regularly invited to speak and keynote.

Resources:

Latest BSIMM

Aedify Security

Concourse Labs

Transcript

[00:00:02] Welcome to AppSec Builders, the podcast for practitioners building modern AppSec hosted by JB Aviat.

Jb Aviat: [00:00:14] So welcome to this episode of AppSec Builders. Today I'm proud to interview John Stevens. So, John is the founding principle at Aedify where he advises product security firms. John, before that, you led ZeroNorth as a CTO and before that you were leading as co-CTO at the Cigital firm. Welcome, John.

John Steven: [00:00:36] Hello, how are you? Thanks for having me.

Jb Aviat: [00:00:38] I'm great, thanks for joining. So John, another thing that you've done is that you co-authored BSIMM, so could you let us know what it is and how it can be a useful tool to AppSec builders?

John Steven: [00:00:50] Yeah, it's worth clarifying because it's frequently misunderstood. The BSIMM is the building security in maturity model observational study. We went out and over a period of 11 years we've studied about two hundred and over two hundred firms and asked the question, what do you actually do to build your security initiative and to secure your software? And it doesn't prescribe what to do, but you can use it to look at what firms that are within your vertical or that look similar to you in terms of maturity, are doing with their time and money, and decide whether or not you want to replicate those behaviours or cut your own.

Jb Aviat: [00:01:29] So you are interviewing like CISO application security practitioners, developers like every actor of the security game.

John Steven: [00:01:38] Yes. Historically, the list has looked like what you described. What was interesting to us about the last two years of this study is that when we began talking with the CISO, they'd say, oh, you need to talk to the VP of Cloud on this, or actually you need to talk to the SREs and to to delivery or to the VP of engineering. The people we had to talk to fundamentally changed over the last two years. And that was a key finding that we we wrote about this year, that the people doing the work of security were shifting from the security group to the engineering, digital transformation and cloud groups.

John Steven: [00:02:20] And that's a big deal, right, because there's been these phrases that we've held dear for 10 years or more. You know, building security in is something that we've said for two decades. Me and a colleague argue as to who said shift left first and we've ended to like November of 2001 when we first said that. It was a long time ago. The other thing we say is that security is everybody's responsibility. Every developer, every engineer, every operator needs to think about it. And we've been harping on those things forever. And what we see is now that engineers, now that SREs, now that operators are taking a really first class citizen role in security, people are taking that 'security is everybody's responsibility' to heart. And in fact, who makes up a security initiative has now changed. And that's a really big deal.

Jb Aviat: [00:03:08] Yes, it is. And so a trend that we have seen over the past two years is like QA testing moved from dedicated teams towards the hands of developers and they are now writing their own data and then monitoring their own deploy, running back if necessary. And so what you describe about security is following the same trend, right? So the teams are now starting to own security by themselves.

John Steven: [00:03:35] Yeah, and we see what we call engineering-led security initiatives, where engineers are not only acting as security champions and participants in a program, but the owners of practice areas and the drivers of the program. So it's not uncommon in some organisations, particularly ISPs, that are more mature, for them to have a Product Security Lead or a Chief Architect who has full purview and responsibility for security and for those people to do the things that you'd expect the security group to do prior. Pick defect discovery tools, tune those tools and drive to a secure coding standard, you know, generate and administer a training program associated with those standards and those tools, you know, and build security blueprints and so on and so forth.

Jb Aviat: [00:04:22] And so you mentioned shift left. So now what I understand is that you are not like advertising shift left anymore. So, due to this change in the industry, now that security is done to be done by people that are actually conceiving and building the things.

John Steven: [00:04:41] With the benefit of time, anything, anything will look wrong, I suppose. So, you know, when we talked about shift left, we were thinking about all of those organisations that use spiral or iterative development or even worse, waterfall. And, you know, we would talk about, look, you know, we can pentest your software, you can apply testing to your software. But wouldn't it be better if you moved earlier in the lifecycle and found those bugs as you were developing them so that they were easier to remediate? And that was the basis of shift left and everybody cited the rational study and it's cheaper to to fix things earlier and yada, yada. You can see why that's a valuable precept. But think about how orchestration platforms and how software delivery has changed over the last five to seven years. We're using Kubernetes you know we've changed the way virtualization has happened. We're layering on top of Kuberntes things like Istio. More and more of the way we deliver software is becoming code, and the whole infrastructure is code movement and the whole delivery and pipeline orchestration movements. What that means is that more and more of the stovepipes between build, test, deliver and operate are being broken down, so that a DevOps engineer can shepherd a greater percentage of the software lifecycle in self-service mode. I don't have to hand something over a wall to you. I can walk it further down the lifecycle pipeline myself. And even the the bridge between Dev and prod is becoming a softer wall than it has historically been.

John Steven: [00:06:26] Cloud, open-source, all of these are self-service technology stacks that allow you, again, further control over a larger percentage of the lifecycle. And so what that means is that code is creeping right in the lifecycle. When you use Kubernetes Istio configuration files, when you use infrastructure-as-code, cloud service provider configuration, what you're doing is you're driving that code right in the life cycle and saying more and more of the way I build, package, deliver and operate is going to be software defined. So more accurate than shift left is maybe shift to where the code is. And what we're seeing is that the code is shifting right. So your know my keynote of the BSIMM conference two years ago was shift right to do security everywhere. And it was extremely aggravating to the attendees because after two decades of moving to the left and trying to get closer to design and requirements, I mean, Laurie Williams out of North Carolina has published a study that says that as much as 10, 11 percent of your code may be infrastructure-as-code and that 30 percent of the churn, month to month in your code bases, is that code. So there's data based evidence that says that that code is moving right.

John Steven: [00:07:42] And so we must move right with it if we want to get earlier. And so this is really never REST. Your security initiative needs to follow the trends in technology and respond with the same principles, get earlier, re-evaluate how those principles apply to the new tech stack. Does that makes sense.

John Steven: [00:08:04] That's fascinating. So shift left, she right or shift to where the code is but there is not only code, right. At some point we need to go beyond because as careful as you are when you design a system, when you when you write your code, there may still be vulnerabilities left or any flaws of any kind. So monitoring the code is not enough.

John Steven: [00:08:28] That's right. So when you talk about shift left or shift everywhere, you're talking about proactive or building security and telemetry. The thing the capability you're trying to to build for your organization is deliver better software with fewer security flaws. But to your point, you're not, it turns out, I know this is going to shock everybody. You're not going to deliver perfect software. Not the first time. Not the tenth time. I think we can all conclude that software will have flaws in it. And so some organizations are saying rather than infinitely iterating my security practices, taking on cost and taking on complexity, maybe I listen to those people in my organization who are focusing on speed of delivery and agility and apply some of that same concept to my security initiative. What if instead of slowing people down to build better software, I participate in their desire to deliver software faster and build resiliency into my security capability. And that speaks to what you're saying. You not only have to proactively find defects and fix them, you have to observe potentially malicious or vulnerable behavior and do something that will make you resilient against that exposure.

John Steven: [00:09:48] So people are saying, if I can combine a 'building security in capability' with a resiliency capability, I'm going to have a much more robust security program. And instead of my costs becoming infinite on the building security inside, I'll have a balanced approach where I will do the best job I can to deliver and I will have a very confident ability to respond when I get risk telemetry based on behavior and operations and I'll pick where I'm going to solve a problem. Because, you know, when we cite the rough model, we're sort of oversimplifying. There are definitely problems that is cheaper to find based on their production shadow than in requirements. And so having resilience where you can redeploy in 30 minutes based on what you observe is terrific. And what this has driven for security initiatives is a technology challenge. How do I combine my building security in telemetry that comes from legacy tools, like static analysis, dynamic analysis, composition analysis tools, with my observational tools that are post deployment operational?

John Steven: [00:10:58] And most importantly, how do I inventory the bits and bytes that are running and map them to the bits and bytes that created them both in terms of the artifacts that go into creating them and the pipelines that create them. How do I tie the people responsible for operating these pieces of the infrastructure and developing and delivering those same pieces of infrastructure? And then how do I know what my code looks like in my service mesh, in my network and those things and identity look like. And so there's been a whole set of obviously technologies, and this is a space you guys play in during the day, where firms are trying to help organizations understand how to tie those disparate pieces of telemetry together so they can see the full picture and then choose how they're going to decide to respond to risk. Are they going to look at operational data? They're going to look at data from the software development lifecycle, or are they going to combine pieces of telemetry and they make an action based on.

Jb Aviat: [00:12:00] Yes. So I'm aware of tools that do that to the left on the code part, so I'm sure you have a GitHub or GitLab in mind, when we mentioned gathering data at code level or deployed at the CI level. So those companies GitHub, GitLab they are every day, more and more like security vendors, because they offer more and more like amazing security features and are very well placed to do so. But on the other hand, for the monitoring, the runtime, for the prediction path do you see tools that manage to aggregate those information from the left path and from the right path.

John Steven: [00:12:35] So GitHub and GitLab are definitely the 800 pound gorillas in this space. Both of them, in my opinion, doing a great job defining the bones of a security framework for these engineering led initiatives. They're saying you need defect discovery capabilities, so we'll help you plug those things into your pipeline, we'll route the vulnerability or defect data to the right developers. We'll track those change requests and track dora metrics like time to fix. They're doing a great job of that platform and the scaffolding. Those platforms coalesce around code, right? Theyre SEM platforms, right. So they're always going to do a better job on the builder side. Some of them are introducing features that speak to proto operational stuff like security research in and out, like bugcrowd or that stuff that goes in and out, security advisors to go out, crowdsourced defector vulnerability data comes in. They're not credible, in my opinion, yet, on the operations monitor telemetry side. You know, obviously there's a bunch of vendors that handle that. I mean, there's there's vendors that handle it from an aggregate telemetry perspective, the zeronorth's of the world, there's people that handle it from the testing perspective, like IAST vendors.

John Steven: [00:13:46] There's there's certainly people like Sqreen that handle it from the RASP perspective and the instrumentation protection side. You know, what I have said about that is that, to investors, to buyers, is a lot of these technologies that are doing the aggregation that act as sort of competitive peers to GitHub and GitLab on the aggregation side, they're pretty early days. Right. And the challenge with that is that how many security tools are there? You know, there's massive fragmentation on a legacy stack. Gartner thinks you need 10 to 30 tools on the cloud stack to get a clear picture of your, and that's just essentially one cloud. You know, there isn't any sort of de facto standard reporting format for these vendors to use in aggregate to. Right now, people are spending a lot of time either using a Series A Series B maturity technologies and making progress in that space or building their own. And in fact, in an adjunct study that I did, which was not published, but there was a compendium to the BSIMM called the DevSecOps study. We found that a third of BSIMM firms have built their own aggregator and have tried to plug it into their particular Frankenstein tech stack of GitHub or whatever. And shockingly, those firms that have done that have spent on average eight to ten million dollars building defect vulnerability management, slash aggregation technologies. So this is a really interesting space, it's sort of at the nexus and fulcrum of your capability to provide resilience, but it's a space right now where you have to pick a vendor. You could build your own, I don't think that's the right move, potentially, but you have to pick a vendor and kind of co-evolve with them.

Jb Aviat: [00:15:28] So sometimes you have new vendors. And so we did Y Combinator in 2018. And so we interviewed like 150 different companies during that during our batch. And we had an idea and we found that so many companies had built it already that we had a doubt, like is everyone building that in-house? And that's how we we pushed our playbook capability. But so that's something that was so widespread and it feels so far away from the core business of those company that it was really hard for us to believe that so many companies had built it already. So I perfectly understand what you mean. And so each time we are as a security vendor, when we are exploring a new feature and we always find customers that have built that already, and no matter what is the complexity, you have some specific needs that are not addressed today in the industry and a lot of companies are holding their own. So, a third, that goes with that. Intuitively, I would say the same thing.

John Steven: [00:16:26] At Synopsys, one of the things that I did was sort of manage the acquisitions of the portfolio a bit. And one of the spaces I looked at, pretty aggressively, was RASP. And of course, at the time, three years ago, RASP and IAST were more intertwined than they are today. And still vendors intertwine those notions. One of the things I'll say about this DevOps dichotomy is that you do have a specific and hard choice to make. And you see people struggle when they try to hedge that it does fall on one side or the other. When you build and you guys probably know this, when you build telemetry technology, you have a choice as to whether or not to make it fast and robust or whether or not to make it thorough and give you good telemetry on provenance and other things that help you debug. In other words, you can build a developer tool that provides visibility or you can provide an operator tool that hardens and provides audit capability. It's extremely hard to build something that does all of those well. You have to pick: fast and hard or slow and visible. And trends like IAST or similar that try to drive, you know, sort of visibility into production, I think are challenged because one, you know, they don't end up fulfilling...

  continue reading

7 ตอน

كل الحلقات

×
 
Loading …

ขอต้อนรับสู่ Player FM!

Player FM กำลังหาเว็บ

 

คู่มืออ้างอิงด่วน