Mark Merkow — Secure, Resilient, and Agile Software Development

0:00Chris RomeoMark Merkow works at WageWorks in Tempe, Arizona, leading application security architecture and engineering efforts in the office of the CISO. Mark has over 40 years of experience in IT in a variety of roles, including application development, systems analysis and design, security engineering, and security management. Mark has authored or co-authored 17 books on IT and has been a contributing editor to 4 others. Mark joins us to discuss how application security and agile software development methodology fit together. We hope you enjoy this conversation with Mark Merkow. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term, sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun.

0:50Robert HurlbutWe don't do lectures.

0:51Chris RomeoInstead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style. allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo.

1:15Robert HurlbutHey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and also co-host of this podcast. I am coming to you from Raleigh, North Carolina, where we have Robert, this strange white substance falling from the sky that we are not even really sure what it is. Well, yeah, this is Robert Hurlbut joining today as well, Threat Modeling Architect. Good to be here with you, Chris. Yeah, if you could just tell me what this white substance is. It doesn't normally happen in Raleigh, North Carolina. They call it snow. I believe that's what it is.

2:02Chris RomeoReally unusual.

2:03Robert HurlbutI looked on Wikipedia. I looked at a picture on Wikipedia to see, and I think it's actually snow, but I'll have to go test it later, maybe after this interview. So the topic that we have for today is agile as it relates to the world of security. We're joined by Mark Merkow, a gentleman who I've known for a few years and met at some conference somewhere along the way. And Mark, we're going to jump right in with our first question, and that is our audience is always very interested to know where people are coming from. And so we want to start with, what is your security origin story, or how did you get into this wacky, wacky world we call cybersecurity?

2:44Mark MerkowHello everyone, uh, thanks so much Robert and Chris for making this happen. I really appreciate it. My security origin story began around 1998 when I got immersed into working on a project to write a protection profile for smart card security. So it was the, the deep end of the pool for security engineering and all of these new, brand new concepts of assurance and whatnot that really fascinated me. And after that, I tried to learn as much as I could about positive security engineering, and it's actually shaped my worldview on how to go about securing applications.

3:25Robert HurlbutSo Protection Profiles in 1998. So you're tapping into my history here as well, given that I was playing in that same kind of a space. I was working at one of the first, or what was the first commercial laboratory that was doing Common Criteria.

3:39Chris RomeoOh, wow.

3:39Robert HurlbutWe did a little bit of Orange Book, and then we started doing a lot of Common Criteria. So it sounds like you and I are coming from somewhat similar backgrounds from kind of a historical perspective.

3:50Mark MerkowYeah, we were looking at— at the time I was with American Express and we had various efforts among the card companies trying to find a way to secure chip cards because EMV was brand new at the time and captured a lot of interest. So Visa had their own set of specifications of what they expected from chip card security as it comes to them for personalization. MasterCard had its own. American Express had some, and NIST was getting bombarded by all of these requests to come up with a unified way of assessing the security of smart cards as they are sent to issuers. So we created a consortium. It was a Smart Card Security Users Group, and it took about 2.5 years actually, because the Common Criteria wasn't quite final at that point. It wasn't actually published as a standard until, what, '99, 2000?

4:49Robert HurlbutYep.

4:49Mark MerkowUm, so we were working on it as it was also being worked on itself. So it was challenging, but it was an incredible learning experience. Just incredible to see the inner workings of the schemes, how they go about interpreting all of this documentation, the inner workings of the labs to try and figure out how to get a protection profile certified, uh, and just the whole scheme. So much so that I I found it fascinating enough that I did write a book about it, Security Assurance Using the Common Criteria. That one came out, I think, in the early 2000s. But that's what I tend to do when there's a topic that I'm really, really fascinated in. I find the best way to learn about it, you know, get as deep into it, is actually by writing about it. So it forces me to go into all kinds of sources that I would never otherwise just go out of curiosity. and actually learn as much as I can. I figure if I can explain it in English to somebody, then I understand it sufficiently enough myself, and that those tend to make good books.

5:59Robert HurlbutThat's kind of— it's funny because when I think about the way that I use to actually build content, learning content for like secure coding, I kind of follow the same approach in that When I start, and I've just been looking at Node.js and JavaScript the last couple of months, when I start, I feel like I don't really know anything about it. And by the time I get to the end, I feel like going through that process of creating content has really caused me to have to understand it at such a high level. It sounds like writing a book gets you to the same place.

6:30Mark MerkowExactly. Yeah.

6:32Robert HurlbutSo how'd you get to AppSec then? From the world of credit cards and chips and protection profiles, how do you make that jump to AppSec?

6:43Mark MerkowOkay, so in '98, one of the projects I was working on in the interactive security group for American Express was an implementation of the Secure Electronic Transaction protocol, because Amex as an issuer needed a payment gateway and all kinds of card-related certificates to make the whole set, uh, process work. So it was incredibly complicated, the systems analysis that went into it. And they— oh, I, I was approached by somebody in the security department who were getting slammed with requests to move to the internet. At the time, American Express had the— they called it American Express Online. ExpressNet on America Online. That was their internet presence at the time, and they decided they wanted to move to their own internet presence, so their own website. So all these departments were coming up with all these requirements for doing just that, and a lot of them had a lot of security considerations that they never had to deal with before because normally that was just taken care of for them by those guys out in the corner. Now suddenly they had to deal with it personally and really had no capacity for doing so. So what they would do is go to the information security department, which was fledgling at the time, and, um, you know, ask for help. And it was getting to the point where there were, you know, 40 active projects. and 2 people were working on it. So because I had worked on the set specifications, because I was able to spell cryptography, the guys over in the security department took notice and asked if I wanted to come in and work there with them. So I did just that. I went from systems analysis and design to security consulting, and it was great. It was really an incredible learning experience for everybody. And over the period of time, we wrote standards, we, you know, documented repeatable patterns, things like that. By the time 2005 rolled around, American Express had gotten very interested in a software security program, and they had brought in consultants to help set it up, but it was getting very expensive and taking much, much longer than it should have. And they decided to insource it and created a department, mostly 2 or 3 FTEs and 5 or 6 contractors, to do all of the work that was needed at the time and help figure out how to set it all up. But of course, this was when we had no guidance. We had no idea what we were doing. So typically, you know, the first thing you do is go out and get a scanner. and start running static scans and exposing zillions of vulnerabilities and then freaking out about it and getting really angry at everybody who is responsible for it, right? So lashing out at all these developers who have no idea what we're talking about, uh, and threatening them, threatening to pull their plug on their application, it was just, just chaos, just endless chaos and terrible relationship damage occurring. So it took a couple of years to figure out all of the wrong ways to do it, because there's, there's a lot of them. There, there's quite a few. Turns out there's just a handful of right ways to do it. But the most important part of all of it is understanding that it is not a technical problem. It is a human problem. And if you try to address it with technology, through technology, it's just going to make it much worse. And that lesson I learned somewhere around, I'd say, 2008, 2009, when it— when the industry started getting, you know, starting to flourish, the software security industry. And by then we had lots better guidance, a lot more experience with it, and everybody kind of came to the conclusion, yeah, this really is a people problem. Let's try to solve it that way. And it worked. It worked. So by the 3rd iteration of software security program, we actually got the recipe correct and went at it by preparing everybody for what is to come instead of throwing all this technology at them, actually getting them to want it themselves so that they get the idea, you know, this makes me a better programmer.

11:36Robert HurlbutRight.

11:36Mark MerkowI'm more valuable to the company. I'm more valuable in the industry. So that's the paradigm I think that's really, really most important, that it really is a people problem.

11:47Robert HurlbutYeah, I would tend to agree that definitely is a people problem. And I guess one of the ways that you're helping to address this is, you know, you mentioned earlier that you've written a number of books, but you've got a new book now called Secure, Resilient, and Agile Software Development. And so I thought I would share the dedication dedication, because I was looking at the dedication, I was flipping through this a little bit earlier today, and I was thinking, this just kind of speaks to the whole thing you're trying to accomplish here in the book. And so, I'm just going to read it verbatim, with your permission, of course.

12:21Mark MerkowSure, of course.

12:22Robert HurlbutThis book is dedicated to the next generation of application security professionals to help alleviate the struggle to reverse the curses of defective software, no matter where it shows up. And so, that just kind of stuck with me a little bit. I love the way you put those words together, reverse the curses of defective software that we've all experienced and that we continue to experience in all of the services that we use everywhere on Earth.

12:49Mark MerkowYeah, every day, every moment of every day.

12:52Robert HurlbutSo, high-level question then that is not directly from the book, but I have a feeling the answer to this comes could be found in the book by reading all the different chapters together. When you think about Agile as a software development methodology, what are the challenges then that security brings to Agile?

13:13Mark MerkowIt's more the other way around. What challenges does Agile bring to security? So, over the years, we figured out more or less all of the things we need to do to build better software. We had the luxury of phase gates containment through the waterfall model, and we worked everything around them, and it worked really well because we could stop things in time to get them into the right shape where they can move into the next phase. Agile did away with all of that, so we have to become much more deliberate and much more thoughtful.

13:51Robert HurlbutYeah.

13:52Mark Merkowin how we accomplish this notion of shifting left, bringing everything back into the point where defects can be introduced is the point you want them caught and undone. So the moment you have an insecure line of code written or function, you should know that right away. It shouldn't take weeks and weeks and weeks and multiple compilations and builds and releases until you finally get a scan that says, hey, you got a problem here. You should be able to catch it and stop it and fix it right then and there. And threat modeling, for example, before we even get into the development world, the development activity, catching those defects, getting rid of them while we're still doing design. And that's been the challenge with Agile because it's all trying to, you know, accelerate time, we have to slow down enough that we can incorporate these, but with the notion that the development team themselves want it and demand it because they know it improves software. And that's the point we want to get to, where they understand this is my responsibility, I own it, nobody can do this for me, and I want to do the best possible job I can. And I think that is the challenge for the security team to get the development world into that paradigm, making them feel that, you know, personal responsibility no matter what activity on the development team they have. So that's where the challenge has been. But it's not insurmountable and it's certainly solvable as long as we're patient and we listen. Because the more we try to force changes into their own processing day in and day out, the less successful we'll be. We have to adapt and ride along, hitch on to whatever's already happening, and just kind of make it a seamless transition.

15:59Robert HurlbutYeah. And so I want to kind of— I want to get your perspective on something that I think is becoming more and more of an issue when we think about security looking at development. And so When you kind of rephrased the question, I said, you know, what are the challenges that security brings to Agile? And you kind of flipped it around and said, hey, what, you know, let's talk about the challenges that Agile brings to security. Do you think that as security people, we are too blind to the actual life of the developer and too focused on our own end goals without actually knowing or having empathy towards the people that we're actually trying to influence. What's your take on that?

16:45Mark MerkowThere certainly are some. Um, a lot, a lot of technical people in security don't tend to deal very well with the human element. You know, they're not trained as psychologists or teachers or whatever, trainers, to actually empathize with the people who we're asking to change their behavior. So yeah, there is a lot of that, and we can't force behavior change. We have to enable behavior change. It's a very, very different set of activities to get there.

17:20Robert HurlbutSo you said that we have to enable behavior change instead of trying to force it?

17:26Mark MerkowYeah.

17:27Robert HurlbutHow do we do that then? I mean, the forcing seems easy, right? We can just write a policy, we just make a checklist, we just say, thou shalt do this or else we will not ship your product. So, that's the hammer approach has always been the one that's the easiest to think about and wield. But what's the other side of that? How do you enable instead of trying to force?

17:51Mark MerkowThe easiest way and the most effective way that I found is by immersing them into these cool new ways of learning software security, things like Security Journey. things like command and control, other kinds of cyber ranges that get them engaged. And finally, light bulbs start going off saying, oh my, you know, my program works just like this. I wonder if kind of thing. So just giving them opportunities, giving them that, that not really a playground or sandbox, but just an environment that encourages a learning culture, because that's what it's all about. Without that learning decentralized and spread everywhere, nothing's going to change.

18:43Robert HurlbutSo learning is definitely having that culture of understanding and truly knowing what the things are that you're being asked to do. In my experience, that's been a big part as well. I see a lot of developers and They don't really understand, first of all, why we're asking them to do something.

19:02Mark MerkowRight.

19:03Robert HurlbutA lot of times we just say, hey, run these tools, code like this, but without expanding on the why for them, they're like, you know, you're just throwing facts at me versus giving me something that I can truly understand and then apply because I understand what the risk is ultimately behind the scenes.

19:23Mark MerkowRight. And when, when they have this environment, they start asking the right questions, which is exactly where you want them to be. When they come to you and say, help me, give me, give me what I need in order to succeed, that's when you know you've actually made that shift. But it happens quickly, actually, as the light bulbs start going off and people start getting interested. These cohorts around them start also getting interested, and it kind of builds organically, but it builds organically rather quickly. And then as you have an opportunity to kind of contain them— not really contain them, but give them a forum, bring them all together, give them a chance to talk among one another— then things really, really begin to change. And this whole notion of the security champions come about.

20:16Robert HurlbutYeah.

20:17Mark MerkowAnd we get real thought leaders in the space out there who then contribute to the next improvement. And the cycle just continues on. So it's an amazing transformation, but it all starts with learning. Without that basis, that foundation, none of this really happens. So it's just, it's lighting that, you know, getting that spark to start the the fire and then just kind of feeding it and letting it, you know, burn in a controlled way that you can see exactly the kinds of, you know, progress that you're looking for in maturity. We'll talk about metrics here, certainly, but, you know, the maturity models help tell us where to go as we achieve certain levels of, you know, capability.

21:08Robert HurlbutYeah. And so when we think about One of the major challenges that I heard you describe here when we think about agile and security is we have this need in an agile, and even so in a DevOps world as well, we just have this need to go fast. And we don't have the weeks, months, years of waterfall development that we used to have. And so, when you're thinking about the counters to these challenges, like, how do we do this well in an agile world? How do we accelerate and keep up with the requirements of the business versus being the department there, the group that says, let's slow everything down because we're security and we can't go as fast as you want us to.

21:48Mark MerkowRight. So by engineering the whole agile development and DevOps process in such a way so that things aren't being impeded, that this whole notion of shifting left, getting everything back to discovery and remediation as quickly as these flaws are introduced is actually the way, the best way to do it. So getting these developers to not just run tools but use the right tools in the right way actually makes a huge difference. But one thing that's really along the way we found is the static code scanners are complex. I equate it to, you know, giving somebody the use of a staticode scanner without the right kind of understanding and background, similar to giving a 7th grader who learned how to use a drill press in shop to suddenly run an NC machine, you know, that does mass production of drilling. You don't do that. You don't want to do that. So along the way of helping inform people and prepare people with the right kinds of information is giving them the knowledge of what's going on inside the static code scanner. If they understand the basic notion that if a tainted variable hits a sink, a vulnerability is declared, light bulbs start going off. It's like, oh, I get it. And suddenly they know what to do, or they begin to know what to do, and they start looking for cleansing functions.

23:27Robert HurlbutRight.

23:28Mark MerkowOr other ways of helping the problem along to prevent it for that particular application and every future one thereafter. So it's, it's kind of, you know, rewarding the right kind of behavior at the right time to instill it and get it to, you know, shift to the next person and the next and the next. So it's a lot of small changes that make a big difference at the very end. And none of them involve waiting. None of them involve waiting at all for the security department to come along and do their magic and, you know, suddenly stop everything in its tracks because there's 1,300 cross-site scripting errors.

24:11Robert HurlbutIt's more about us kind of getting out of the way, right?

24:14Mark MerkowExactly.

24:15Robert HurlbutAs security, we're more, we're more about being the builders of the process, the secure development lifecycle, that can execute and run at the speed that the business needs to develop features and push stuff out, but we just have to get out of the way and let that process execute and run.

24:32Mark MerkowExactly, exactly. And building it in from the very beginning, like in the book we suggest using— expressing security requirements as guardrails on user stories. So instead of writing user stories that say, I want a secure system because I want one, We just let the user stories for the features get written, and the acceptance criteria tells us what specifications that feature needs to meet, including all the security and other non-functional requirements. So it's a really powerful way of making sure that nothing progresses until everything is done and tested and proven done. So it's a really, really powerful way, but it starts with the product owner, getting them to understand that security is not free, it's not magical, it doesn't just happen by itself. It actually takes effort and thought and work, and allowing that effort and time into the project so that it's not being ignored. So they really need to understand 3 things. That non-functional requirements, especially security requirements, need to be treated as equal citizens to functional requirements, to features, and use acceptance criteria whenever possible to limit what a feature is able to do if it's out of bounds to the policy that it needs to conform with. So that forces it right at the beginning of the project instead of waiting until Trying to bolt security on later, which we all know never works.

26:14Robert HurlbutSo when you think about the agile secure development lifecycle process, I know we talked about education already, so I'm going to take that off the table. What's your first go-to thing? Let's say we dropped Mark into a brand new company that's just gotten AppSec fever, meaning they don't have any— they don't have a program, they don't have anything. But they're like, well, this is important. We got to do this. Our board's saying this is mandatory.

26:43Mark MerkowYeah.

26:43Robert HurlbutWhat's the first thing in— what's the first part that you're going to do in the program? I know I would normally— I think a lot of us go to education, so I'm going to take that off the table and say that's being handled separately. What's the first thing that you're really going to and you're trying to achieve there?

26:59Mark MerkowAwareness. So forget the education, that'll come later. But getting everyone on the same page with the same understanding of the problem and a common understanding of what the ultimate solution will look like, maybe months or years down the road, is really essential because it gives them the roadmap that they need in order to understand where things are going to go. And then, and then filling in all those gaps. But the important thing is to first get everybody on that same page with the same level of understanding, all of the terminology and whatnot, so that when we talk about it, everyone understands it the same way. And then forming core— a core team of people, representatives from each of the development communities, whether that's depending on the size of the company, of course, whether that's somebody from every Scrum team or somebody from a product team, getting all of those people together and working on figuring out how to make this their program, because it has to be their program. It won't work otherwise. If it's not them doing it and owning it, it'll never happen. There's just too few security people to secure tens of thousands of apps in a particular company. So that's what I would do. And that tends to— that has worked a couple of times already, that process, that approach.

28:28Robert HurlbutOne of the things you mentioned was a roadmap. And so, that's just making me think because in my past experience, I've always thought of the secure development lifecycle as kind of the roadmap, but it's making me think like there's almost a need for a new program to do some marketing. to internal marketing.

28:50Mark MerkowYeah.

28:51Robert HurlbutAbout, hey, here's where we're going, here's what we're trying to do. It's almost like you would do in a startup where you've got your roadmap and you're sharing with, with customers to get them excited about, hey, here's where we're going. It sounds like you're talking about doing the same type of thing inside this new organization using awareness, showing people, hey, here's the roadmap, the set of things we got to do to get to where we want to go. And we're all— we know everybody needs to get on board and get behind this whole idea.

29:16Mark MerkowRight, and then getting the right people in the room to help make it happen. Because we, you know, in the security world, we don't know what goes on internally in a development team or development group, and they're all different. There's no one, you know, unified set of how people behave when they're doing development. So we need representatives from all of those varying ways of doing things to find a common way to implement these processes in the right way at the right time and in the right scope. Because again, if we don't do that, it won't work.

29:53Robert HurlbutYeah, I guess you can make all the plans that you want, but if you don't have the right people with you on the train, then you're never going to get to the destination you're trying to get to, right? It's— you get there and you'll be holding a bunch of binders, but nobody else will be there with you to help you you know, the solution will not have been found.

30:14Mark MerkowRight, more like PowerPoint slides, but yeah.

30:17Robert HurlbutAll right, so I wanted to talk about metrics for a second because I know you've got a section in the book about metrics, and it's always curious to me to think about or to understand what are some of the most important application security metrics from the minds of other practitioners across the industry. And so when you're thinking about agile and security metrics, what are the things that organizations should be measuring and operating their program against?

30:46Mark MerkowI think there's 2 really important metrics that tell you about the health of the program and the direction of the program. And the first one is the normal time it takes to remediate a vulnerability of a particular type. So if we know how long average time it takes to remediate cross-site scripting, then we have a much better way of knowing basically what we can expect when we come across these kinds of vulnerabilities. So that one's important— average time it takes to remediate a particular class of vulnerabilities. And then the other one is the incidence of reappearance of vulnerabilities that we thought we knocked out. So, you know, scanning— initial scanning shows tens of thousands of cross-site vulnerabilities. Some major Manhattan Project goes out and gets rid of all of them, basically, you know, within reason. And now suddenly new scans are showing cross-site vulnerabilities going up and up and up every month. So that's an important metric to know that something's going on inside the program that once worked is no longer working. So I think those two. Other than that, the maturity models, I believe, are really important to help understand where things are at today, where you would like them to go, and have you actually achieved that as you do these assessments over time. So OpenSAM is a great example of, of one. A simpler one than BSIMM and a hell of a lot less costly. Um, yeah, but it's a great starting point for just about everyone to understand what is the industry saying should happen when you're developing software.

32:48Robert HurlbutYeah, and OpenSAM, I'm also a big fan of that, and they've just recently hit their 2.0 release of the, the new version. And, and one of the things that I think is really exciting about that is they're continuing to try to figure out how to let people anonymously share data under the umbrella of OpenSAM. So you'll get some of the BSIM, some of the magic you get in BSIM of being able to see how you stack up against the rest of the industry and verticals. They're really working. They see the value in that. And I do as well. I'd love to see that data in an open and anonymous format where everybody can play, whether you're a small company or a large gigantic enterprise.

33:31Mark MerkowYeah. That would be really valuable.

33:33Robert HurlbutSo last thing that I see as I'm kind of scanning the index of the book is you've got this section on new frontiers for application security. And so kind of what, why'd you put that in the book? And what are some of the things that we'll find there?

33:50Mark MerkowA lot of it came from concern that all this new technology is coming out faster than we can even begin to understand what it's doing or manage it or, you know, use it in a way that makes it useful in whatever form it takes on. But I think about people who are business systems developers suddenly writing software that's going to activate some of these IoT devices, and some of these IoT devices can do things like move Which means they can actually cause safety issues, especially if they malfunction or act really weird. Now, it's people writing the software for this, and we know inherently there's going to be flaws. I don't think there are proper vetting processes in place quite yet that will prevent the kinds of problems that we see every day with these devices from, from happening.

34:52Chris RomeoRight.

34:54Mark MerkowAnd it, you know, the consequence of a vulnerability in a device is very different. I mean, if you have this internet-attached refrigerator and suddenly it malfunctions, do you need to send it back for an update? It just causes all kinds of problems. And the worst of them, if we think about it, are autonomous vehicles. So whoever's hiring the developers for these autonomous vehicles, they're probably pulling them out of colleges, which means they have little to no commercial development experience, or they're pulling them out of businesses and they've been writing, you know, business logic applications. None of each prepares them for putting their software out on the road to act autonomously and potentially, you know, do some real damage out there. So that is— that kind of concerns me. And I added that section of the book in hopes that developers will appreciate the responsibility, the awesome responsibility they take on when they write software for these kinds of things. Because there are consequences.

36:13Robert HurlbutYeah.

36:13Mark MerkowAnd if you don't think in terms of safety as well as security, you know, the problems are gonna just get much worse, not only harming people but also harming other assets. So it was just an exploration of all the new technology that's out there and emerging technology and new ways of deploying systems that You know, it's so new, we don't even know what the right questions to ask are quite yet. So, it's mostly there as food for thought. Let's put it that way.

36:49Robert HurlbutWhich is good because we need to be thinking about AppSec in the context of everything because software's everywhere and, you know, software's eating the world. That's been overused by me and many other people, seems like thousands of times, but it's true though. That's the challenge is it's such a true statement. of how impactful software is in everything that we do. And just means AppSec is going to have a more front and center role going into the future. So anybody out there in college right now, that's where it's at. Application security is where it's at. Learn how to code, learn how to do it securely, and you will have a long career and you will likely retire before we solve all these things. But that's okay, as long as we make some progress and maybe we have the OWASP top 5 in 2030 or something. I don't know. Yeah, or top 2 or something, some type of, uh—

37:41Mark MerkowAnd we need as many as we can get.

37:43Robert HurlbutThat is most definitely true.

37:45Mark MerkowDefinitely true.

37:46Robert HurlbutSo, Mark, what do you want to leave our audience with here, kind of as a final statement for the audience? Could be a call to action, could be just the food for thought, whatever, whatever you want to leave them with.

37:57Mark MerkowWell, I hope everyone buys a copy of the book. That would be great. Um, I wrote it as an update to the 2010 edition, which was called Secure, Resilient, software development. It was really important to update it for Agile because most of what we knew about Waterfall, I mean, it still applies, but it has to change, and that's what the whole idea is there. So I'm hopeful that, you know, people adopt these ideas and actually bring them to life because I've done it and it actually does work in a very large organization. It works really, really well. But you have to have patience and the right expectations. So, you know, you're dealing with people. People can only take so much change at once. They can only absorb so much at once. Don't drown them. You know, turn off the fire hoses is basically the best advice I can give.

38:55Robert HurlbutWell, Mark, thanks for taking the time to share your experience and knowledge with the listeners and for writing the book. that's going to help our industry to understand even better how to approach agile and the application security and how these things all fit together. And so, thank you very much, and I look forward to having you back again in the future to talk about, I don't know, whatever the next book is you write.

39:16Mark MerkowThanks. I really do appreciate it.

39:18Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/appsecpodcast.

39:33Robert HurlbutYou can also find Chris on Twitter @edgeroute and Robert @roberthurlbut.

39:39Chris RomeoRemember, security is a journey, not a destination.