---
title: "Thinking back, Looking forward - A Balanced Approach to Securing our Software Future"
url: https://appsecpodcast.com/thinking-back-looking-forward-a-balanced-approach-to-securing-our-software-future/
date: 2021-07-15
duration_seconds: 4313
guests: ["Kevin Greene"]
topics: ["Threat Modeling", "OWASP Top 10", "Software Supply Chain", "DevSecOps and CI/CD"]
audio: https://www.buzzsprout.com/1730684/episodes/8869588-thinking-back-looking-forward-a-balanced-approach-to-securing-our-software-future.mp3
video: https://www.youtube.com/watch?v=JGkb-TDQE9k
transcript: true
---

# Thinking back, Looking forward - A Balanced Approach to Securing our Software Future

*July 15, 2021 · 1 hr 12 min*

with [Kevin Greene](https://appsecpodcast.com/guests/kevin-greene/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [OWASP Top 10](https://appsecpodcast.com/topics/owasp-top-10/), [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/), [DevSecOps and CI/CD](https://appsecpodcast.com/topics/devsecops/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8869588-thinking-back-looking-forward-a-balanced-approach-to-securing-our-software-future.mp3) · [Video](https://www.youtube.com/watch?v=JGkb-TDQE9k)

## Show notes

Software security has spent decades alternating between prevention, detection, and response. Kevin Greene joins Chris and Robert to ask what a balanced approach should look like now. Drawing on work at Parasoft and across government and industry, Kevin discusses secure development practices, standards, developer enablement, and the limits of relying on tools alone. The conversation connects supply-chain failures and the federal cybersecurity executive order to cyber resilience, penetration testing, red teams, and assurance. It closes by looking ahead to policy, software minimalism, and the changes organizations must make if they want secure software to become a repeatable engineering outcome rather than a late-stage scramble.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Kevin Greene:  
→ [Parasoft](https://www.parasoft.com/)  
→ [Kevin Greene on API security testing](https://www.parasoft.com/news/parasoft-release-delivers-new-level-of-visibility-into-identifying-api-security-vulnerabilities/)

Mentioned in this episode:  
→ [Parasoft](https://www.parasoft.com/)  
→ [OWASP Proactive Controls](https://top10proactive.owasp.org/)  
→ [MITRE ATT&CK](https://attack.mitre.org/)  
→ [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/)  
→ [Executive Order 14028](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity)  
→ [Apache Struts](https://struts.apache.org/)

Chapters:  
00:00 Looking back at software security  
02:03 Kevin Greene’s path through AppSec  
04:54 What a balanced security approach means  
06:59 Prevention, detection, and response  
09:52 Standards and repeatable engineering practices  
12:38 Making secure development easier  
15:42 Helping developers own security  
18:40 The current state of software assurance  
22:36 Guidance, governance, and accountability  
24:46 Where security tools help—and where they do not  
28:00 Supply-chain failures and SolarWinds  
30:00 Why old software problems persist  
33:00 The federal cybersecurity executive order  
37:00 Adapting to rapid change  
40:00 Building cyber resilience  
42:00 The role of penetration testing  
45:00 What red teams add  
47:00 Standards, certification, and assurance  
53:00 Looking toward the future  
54:00 Goals for the next generation of software  
56:00 Software minimalism and reducing attack surface  
59:00 Policy as a driver for change  
62:00 Closing thoughts

## Transcript

*11,241 words · assemblyai*

**0:00 Chris Romeo:** Kevin Greene is the Director of Security Solutions at Parasoft and has extensive experience and expertise in software security, cyber research and development, and DevOps. He leverages his knowledge to create meaningful solutions and technologies to improve software security practices. Kevin and I had a conversation to discuss software security from the past and into the future. We cover how to make security easier for developers, SBOM, software minimalism, cyber resiliency, and so much more. We hope you enjoy this conversation with Kevin Greene. Are you trying to build a security champions program? Everyone is these days. One challenge of rolling out security champions is, how do we educate all these new folks? Security Journey has your answer. We provide a security dojo environment with level-based security education that gives your newfound champions a path to follow. And the best part? It requires almost zero administration by you. Visit www.securityjourney.com to set up a demo and learn how you can use the Security Dojo to connect with your security champions. Hey folks, welcome to our webinar today, A Balanced Approach to Securing Our Software Future. We're gonna be thinking back, we're gonna be looking forward. My name's Chris Romeo. I'm the CEO of Security Journey, and I've been involved in the world of security for almost 25 years at this point. Have done a lot of different things from traveling security consultant to director of incident response to application security being where I've landed over the last 10 years. I spent the time before Security Journey at Cisco running a large portion of Cisco's internal security program focused on secure development lifecycle and training and education for developers all over the world. Super excited to be here with my friend Kevin Greene today. Kevin, glad to be back on the line with you again and having a conversation.

**2:02 Robert Hurlbut:** Chris, what's up, man? How you doing? I appreciate it. It's been a while since we last talked, and I'm very excited to talk about things that are happening in the software security space and really trying to take a look back and kind of think forward in terms of things that we need to work on. I mean, as we've seen over the last couple of days, the executive order for cybersecurity has come out, right? I'm really interested in Section 4, which involves software security. So I think there's a lot of things, a lot of threads we can pull on in terms of looking at what is working and what is not working to try to advance software security practices.

**2:40 Chris Romeo:** Thank you. Yeah, I'm excited to get your perspective on this, knowing that you're someone who's focused on securing the government and now Now that you're kind of focused from the commercial private sector, I think you've got a lot of perspective, a very interesting view of the world that I think is gonna come out in this conversation.

**2:58 Robert Hurlbut:** No doubt, and I think, you know, as being the Director of Security Solutions at Parasoft, I think, you know, we have a good vision in terms of where we wanna take software security, and I think hopefully some of those things will be shared here today. But just give you an overall from my experience, Over the last decade or so, I've been really trying to be out on the front of trying to improve software security in serving numerous roles, right? One, I was at Department of Homeland Security and Science and Technology Directorate in the Cybersecurity Division, leading R&D in the area of software security. So things that come to mind that were part of my program is the Software Assurance Marketplace called the SWAP. Research from my program was very vital in what you see today from Denim Group, ThreadFix, as well as CodeDX. So these are a lot of innovations that came through my program, as well as most recently some advancements in static analysis from the work that Grammatech did through my STAMP program. So I'm very, very excited to have this conversation. It's one that is needed given the time where we are. where we've seen a lot of attacks that are software, that really have threads with software, right? So, you know, I'm really interested in talking to you about some things that, you know, we can improve upon.

**4:20 Chris Romeo:** Yeah, software supply chain has definitely taken center stage over the last 12 months or so, and I have a feeling it's not going to get— it's not going to disappear. It's going to continue to be front and center. Well, let's go ahead and flip our cameras off so we can bring this slide into full-screen mode and I'll kick off the first question that I have for you, and it's really about this idea of a balanced approach. And so when you think about a balanced approach to secure our software future, what are the pieces of this? What do we need to be thinking about?

**4:53 Robert Hurlbut:** You know, one of the funny things is, you know, when I go into DC and go into Virginia, whether crossing Rosewood in DC or going through the highway, within DC, you see a lot of roadwork being done. And the goal is to try to modernize the roadwork to create more, more resilient infrastructure to allow things to happen like creating lanes for bikers to have, you know, access to the streets and roads to ride their bicycles, widening the streets. And I think the same thing has to happen in software security. We have to figure out a way how to advance the state of practice, create that strong foundation. Yeah. Where we can do some innovative things. And a couple things come to mind, right? I think we're lagging in terms of standards and guidance and policies. Some things that come to mind, you know, obviously everyone knows about the OWASP Top 10. Everyone has a view and viewpoint about it, but I think we need to really focus on that, right? I think for by and large, it has been used as a compliance framework. or some compliance standard. But that's not the intentions of the Top 10. The Top 10 was initially created for an awareness document, right? But when we look at it in terms of the collection method, in terms of how data was collected, the quality of data to come up with the Top 10, I would like to see that to be more driven with foundational science where where we have, you know, really good analytics that is representative of what we see in attacks from the web application. I mean, so much has changed in modern software development, and it amazes me that the same top 10 is the same that, you know, there's a few changes here and there, but for the most part, you look at its overall decade of existence in the industry, we're seeing the same top of—

**6:57 Chris Romeo:** Yeah.

**6:58 Robert Hurlbut:** type of attacks. And I think a large part is there's been, in my opinion, been a strong focus on the detection piece, right, and not so much the prevention piece. If you look at the top 10, these are like the type of threats that can happen with web applications. But I do think that we have to focus on the prevention, right, and understanding and helping developers and people who build software understand the risk in their coding practices and the impact it has on software, which can be expressed obviously through the OWASP Top 10. So how do we, you know, shift left, right? Shift further left. Now when you talk about shift left, that's what it means to shift left, where we're taking a more preventive approach in understanding how to build software to mitigate these top 10 attacks that occur. Well, unfortunately, we're seeing the same type of attacks happening in the news, same type of Same type of threats that keep occurring over and over again, which signals to me that the prevention piece, you know, we need to put more focus on the prevention piece and helping people understand how to codify these threats and risks in their coding practices so we're not seeing the same type of threats and we're not being— applications and systems not being susceptible to the same type of attacks. Another that comes to mind is CWE. And CWE is also a decade old, right? CWE is the definitions and how we talk about issues in software, Common Weakness Enumeration. They provide definitions for weaknesses that can occur in software. I think, you know, MITRE has done a really good job in trying to modernize it, but I think there's more of a— more improvement improvements that need— that need to be done. Specifically, how do we make CWE broader adoption? Right? And there's all sorts of use cases that, that can be satisfied with that. And one way is to get CWE, right, more broadly adopted, especially with developers. Right? And helping developers understand what could go wrong, the consequences of their coding practices, These are things that I think are fundamental, right, in building better software, understanding how do we prevent these bad things from happening. I mean, obviously software security is much more broader than application security, but these are 2 things that come to mind in terms of how do we move the state of practice forward. Because to me, when you— when we're able to improve and advance the state of practice, now we can have the— now we have the, the, the ability to innovate, right? We can evolve the state of the art and create better tools, better practices, right? So I think, you know, this is a key in terms of a balanced approach. Other things that come to mind? Yeah.

**9:51 Chris Romeo:** Go ahead. Yeah, so a couple of thoughts that come to mind for me thinking through kind of your general constructs here. Agree, totally agree with you on the OWASP Top 10. Like, I have a standard OWASP joke that I normally only reserve for OWASP events, But, you know, it's something to the, the focus of, you know, why do we even have an OWASP Top 10? Why don't we just have an OWASP Top 1? Let's just solve that problem. Let's solve injection first, and then we can talk about all these other things. And in front of an OWASP crowd always gets a smile, or, you know, maybe even a little bit of a laugh out loud. But totally on board with your idea of detect versus prevention. And when I think about the OWASP universe, The proactive controls is that companion document that goes with the OWASP Top 10, and that's the one that people always forget about. Like, all the focus gets put on the OWASP Top 10. Let's think of it as a, you know, too many people think of it as a compliance document, but to your point, it is an awareness document. But people always forget about the proactive controls as that answer to how do we deal with those particular types of issues. And so that's an important one to bring out into people's perspective as well. And, you know, CWE, I think CWE is one of the most underused resources that we've got in our community.

**11:08 Robert Hurlbut:** Absolutely.

**11:09 Chris Romeo:** We gotta find ways to use it better.

**11:10 Robert Hurlbut:** Right. So I, before I left and came to Parasoft, I was working on trying to help increase broader adoption with CWE. And I, I will agree, you know, it's, it's considered a standard, but by and large, it's mainly used by vendors in, in, in their tools and trying to detect CWE violations in tools, right? But we need to move it further left, right, into prevention. But also another use case is how do we get these things in curriculums, right, where we're teaching future— our future developers how to build better software and be aware of things that could go wrong when you're developing software, right? And if we can codify these things, these become— these things become second nature, right? It's like, I mean, it's part of what we do. We won't even have to think about trying to build security in. It will be part of what we do in building software and developing software. So we can at least do these 2 things, get it more, more activity around the prevention piece, as well as using CWE, as well as the OWASP Top 10, to be more on the academia side and really teach our next coming crop of software developers and systems engineers of how to develop software and think about ways in which adversaries can attack us and really understand how software weakness can manifest and how security issues can manifest in software.

**12:38 Chris Romeo:** Yeah, you just— you're describing why I get out of bed every morning. That's, that's, that's my challenge to the— that I put forth, you know, in front of the world is that's, you know, that's why my company exists is we want to, we want to teach developers about these things. But I'm also talking to different universities and thinking about like, how do we get this knowledge into the first computer science programming class you take as a sophomore or maybe even a freshman in college these days? Like, how come they don't learn CWE there? Like, wow, imagine a world where CWE has been unlocked and we've got all that knowledge kind of out there. I want to come back to something else you said because I always like to get an understanding for people's perspective on shift left. Because when I think shift left, and even up till, you know, 2 or 3 months ago, I used to think of shift left as purely a marketing term. And then I had a conversation with Jim Ralph, who's been a CISO a lot of different places, built a bunch of AppSec programs, and his explanation of shift left really flipped it upside down for me. And so I'm curious, Kevin, what's your perspective on shift left? Is this a marketing term? Is this something we need to be putting forth? Like, what are your thoughts?

**13:50 Robert Hurlbut:** So to me, I mean, people use shift left, it's a catchy term, obviously it's the new marketing term that you alluded to, but to me shift left is really helping people who are developing software understand how to think about security from concept, you know, from concept to delivery, right? You know, that's the term I like to use, from concept to delivery. The concept is how do we design software? Right. Right? Software that is resilient, software that's secure, right? Having that thinking, understanding ways in which the adversary is trying to attack software, right? And using that, that knowledge, that context, right? And applying it to how we build software, right? How we develop— take, for instance, there's, there are design principles from a security perspective that goes into a design, right? A developer has to implement those design and security principles in code, right, the implementation piece. Developer needs to understand and be aware of the coding and refactoring activities in implementing the design correctly in code. So to me, shift left is really about, from concept, how do we think about ways in which, you know, there's threat modeling, there's all sorts of things that we can incorporate. So shift left to me is really about understanding how to get people to think about security. as part of their daily activities so that we can have it in software. So from design, from the concept, as I mentioned, to design, to implementing in code before we do any testing, right? A lot of times people talk about shift left as, as part of a, a new phenomenon that's involved software security testing, but it to me is a lot broader and deeper than that. And hopefully I, you know, I was able to share some of my thoughts around that.

**15:41 Chris Romeo:** Yeah, no, I think you've, uh, you've added even a little bit more to my definition or my understanding of it. So this idea of that where you said getting people to think about security in their daily activities, that really resonates for me as well because that's, that's, that's an overall goal that all of us that are, that are focused on software security, application security, secure development lifecycles, like, that's what— that, that's like the best thing that could possibly happen is where everyone starts to think about security. Everyone embraces this idea that security is a part of what I do in my job. It's not the only thing I do, but it's a percentage. And some people in the industry kind of throw shade at that idea of like, you know, having, you know, this everyone is a security person, but I think it's crucial to the success of whatever we do. I don't see how we have enough people in a development organization to be able to say that, hey, we've got security figured out in this central team, right? It's something that has to be a part of the bigger organization. So I wanna keep ourselves moving here because I see something on this slide right now that I wanna make sure I get your take on. You mentioned the executive order that's come out. One of the big things that's in that executive order is this idea of SBOM. Tell us what SBOM is and then how we're going to accelerate and mature it.

**17:00 Robert Hurlbut:** You know, I don't, you know, I, I think everyone has their own definition criteria of SBOM, but to me, I think, you know, for it to be what it is, is, is being designed to be, we can't over-politicize it, right? And typically when we over-politicize it, it stifles innovation, right? It becomes, you know, something that is forced upon people. One of the things I think that is important to have is I think that in order for us to accelerate and mature anything around software building materials, I think there needs to be more foundational science. And what I mean by that is, you know, I was asked by, several years ago when Sonatype had their State of Supply Chain report, I want to give a shout out to my friend and colleague Derek Weeks. He asked that I kind of, you know, review and provide some comments regarding the report, and I did. And one of the things that I was able to provide just by Just about, you know, you know, I come from a different perspective. I was more from a research and development perspective, and I have operational experience in implementing and building software security programs. But of late, you know, I tend to look at things differently. And for whatever reason, I think we've always seemed to put the blame on developers, right? I want to be a developer advocate, right? And one of the things I think we have to provide developers better software options. And what I mean by that is I provided a quote, and the quote was something around, you know, I think developers have surrendered to the idea that all software have vulnerabilities, right? So no matter which one they choose, it has a vulnerability, right? So I think of it this way. My kids play travel sports, right? And we're always on the road. One play baseball, one play soccer. You know, we out of town for tournaments and showcases or whatnot, and it's like I'm always— all I see is fast food restaurants, you know. So where are the healthy options in terms of food, right? You know, so now you see different, you know, chain restaurants putting more healthy options on their menus and things like that. So it's a variety, right? We have to get developers better option as it relates to software. One of the things I think this SBOM has to avoid doing is tallying CVEs as a mechanism for determining the overall hygiene and whether or not software is— it has low risk or high risk. Those are the known knowns, right? We know that there's the known unknowns, which we need to start focusing on. And hopefully the— when I say accelerate and mature the SBOM, hopefully there are solutions that come out of SBOM that's focusing that focuses on the known unknowns, but the bigger problem, I think, is the unknown unknowns, right, the things we don't know about software. And I always say that we have to put ourselves in a position to understand the defect proneness rate of software and the attack proneness rate of software. And what I mean by that is we have to be able to predict or have some information to help developers and people who are building software to make better informed decisions about which software projects they should choose, what libraries, what frameworks they need to use, right? You know, I need to be able to have some visibility into if I use this component, right, what is the risk 6 months from now and a year from now? I know scientifically we're not there yet, but to me, that would be a phenomenal challenge to solve, and I think it requires some research, some research and development to do that, because one thing we are sure of the overall consumption rate of open source software is not decreasing, it's increasing.

**20:59 Chris Romeo:** Yeah.

**21:00 Robert Hurlbut:** So because of the consumption rate is constantly increasing every year, we have to provide better software options and better visibility so developers can make better and wiser decisions in terms of what software to use in building software systems. So when we talk about accelerate, hopefully there's an R&D piece of that, but typically when things get over-politicized, the creativity, the innovation piece seems to be stifled. So hopefully that's not the case.

**21:28 Chris Romeo:** Yeah. No, I share your, your kind of focus and opinion there that we want to make sure that SBOM is able to deliver on the promises that it has been, that have been, it's been described with. When I think about, you know, the true value proposition of SBOM, like being able to understand clearly the software components that go into any particular additional piece of software, like is a level of visibility that we've never seen as an industry. And the government's going to be— is pushing SBOM here. And normally I'm somebody who's like, I want to see innovation and this type of stuff happening from, from, you know, from commercial entities and from academic research and things like that that are driving it. But I think in this case, like, it's time. We've been dealing with this, you know, software composition problem, dependency management, vulnerability management and dependencies. They're there. We need— we needed a boost. We needed a push to get us in the right direction.

**22:36 Robert Hurlbut:** It needs to be It needs to give it have a big bang. When I say a big bang, it it needs to have a a a substantial movement in terms of how we do software and how we acquire software and how we build software. It it needs to have that type of impact, and I'm not sure if it can have that impact because you know think about it. There are so many ingredients and so many different. Components that goes into building software. Are we, are we creating more work by having the transparency with software bill of materials? Possibly, possibly so. One of the things that we have to be aware of is we need to provide context related to things that are in software and understand the architecture in terms of— because one thing we do know is you could take a component with a relative good risk, good risk scoring, or good risk hygiene, or however you want to classify it, implemented incorrectly in code that would have— that would expose an attack surface, right? So it's also about not just the components itself and the overall security associated with that component, but it's how do you implement it, integrate that component within your software development project that it doesn't increases the attack surface, right? So I think, you know, one of the things that we also have to be aware of is with transparency, like, how do we understand— how do we help people understand what they need to patch? What are the touchpoints of this particular component? What are the— what is the execution path of this component? Like, is this something that is being called during execution? Like, all these things are important. If we can provide that level of visibility, to help people kind of prioritize what they need to focus on, because that becomes a, a big burden, really trying to figure out how do we prioritize of, of 1,000 things we need to worry about, which one matters the most, right? And I think any software security solution should help users and developers understand what matters the most and prioritize so that it can triage and also help reduce risk to the organization.

**24:46 Chris Romeo:** Yeah, tools. I'm with you there. Tools really need to be focused on how do we make developers' lives better from a security perspective, especially security tools, because we have so many out there that are just generating lots of different alerts and things like that. But are they really making the triaging of those alerts something that's, that's practical and that we can, we can work with? And I agree with everything you said about the fact that You know, I think your conclusion was kind of leading towards, hey, SBOM is good, but it's not the end-all and be-all. It's not going to solve all of our problems for us in application security, software security. I agree with what you're saying about, hey, you know, architecture is key. Like, lack of a secure architecture with SBOM does not equal a secure product or a secure application.

**25:35 Robert Hurlbut:** Absolutely.

**25:35 Chris Romeo:** It's just not going to get us there. We got to, you know, part of this whole idea of shifting left and shifting right, shifting up and shifting down and whatever other way we can shift is thinking about security as a holistic approach of a lot of different pieces that all have to fit together. Now, I think SBOM is an innovative way for us to get ahead of this specifically dependency management challenge and answering the question of what the heck is in this particular piece of software that I just bought. I think that's— I think that— but that's only solving a smaller piece. Granted, it's been— it's gotten a lot of attention, you know, with SolarWinds and other software supply chain events, that problem has gotten a lot more attention lately. And I think it'll be interesting to see how does SBOM in the next 12 months or the next 24 months help us to maybe eliminate some of those bigger supply chain problems that potentially would have, would have been something that would have dinged, dinged the whole industry.

**26:33 Robert Hurlbut:** Right. And my thing is, to a certain extent, I think there was an HR bill that was being circulated. This is maybe back in 2013, 2014 when I was at DHS around SBOM. It's, it's almost like SBOM, you know, we should have been doing this maybe 5 years ago. Um, now we're trying to do it. Now the question becomes, has, has, has software security industry, has, has the pace moved so much that SBOM is gonna be ineffective? I don't know. With cloud or hyper— with cloud and a bunch of other things that are coming on, on into modern software development, the complexity that's associated with software development. You know, it's gonna be, it's gonna be interesting to see how SBOM is going to help improve software security. I'm going to keep an open mind. I mean, I've, I've been on the fence, but I think at the end of the day, this is where we want to go with the industry decides to go with it. You know, I, you know, I have to be you know, open-minded and really look at how Parasoft can be a player in helping achieve some of these challenges with SBOM and helping improve some of our capabilities internally and build that vision, right, to accomplish some of the things that I think is important to have as part of an SBOM solution. One of the things that, you know, we also need to figure out and understand is the relationship between supplier and the consumer and being able to provide those who are purchasing, acquiring software, the ability to have re— you know, a popular topic that's coming up now is the reproducible builds, right? The ability to ensure that the software you are acquiring from a supplier has no known vulnerabilities and backdoors in software, right?

**28:17 Chris Romeo:** Yeah.

**28:18 Robert Hurlbut:** The ability to have— because that's what SolarWinds— SolarWinds was able to compromise the build environment, right? So now we need to have some validation that the, that the build, right, that the build we're getting actually matches the initial build by having a way to recreate identical artifacts about the build, right? So I think, you know, things are moving in the right direction. And from— if I'm a consumer, I want some assurances that whatever I'm acquiring from a supplier that I want some assurance that there's some software integrity involved, right? Because we know that code can be modified during distribution, so I need to be able to reproduce those same results. And that's why reproducibility is a, is a, is a good way to establish that, that relationship between the supplier and consumer. So, so the consumer has some assurances that whatever I acquire I can have some level of trust because I may be able to reproduce those same artifacts to have some level of trust.

**29:20 Chris Romeo:** Yeah, and that speaks to your point of establishing and enforcing software integrity. Like, that is, you know, that reproducible build is software integrity. Like, if I can prove beyond a shadow of a doubt that this was— this thing, this piece of software was built in this pipeline and things were signed along the way and it gets to the end, and then I've got a, you know, I've got kind of the ability to trace back through the cryptographic history to say, Hey, this, this is— I, I, I have, you know, almost 100% belief that this thing wasn't modified throughout the build pipeline in a negative way. Like, that's also a future that we want to be making our way towards as an industry.

**29:58 Robert Hurlbut:** Absolutely. And these are not things that are new. I think these things have been happening, but now that it's— since it's more mainstream, we, we gotta pay attention to it. And anything that involving supply chain or improving supply software supply chain, We got to have a way of having that level of assurance that, that soft, you know, that software integrity chain of custody type of thing that, that, that, that people who buy software can, can trust. And I think that's what the government is trying to do with the, the EO on cyber is trying to put these assurances in place because government by and large is a huge consumer or acquirer, I should say, of software. You know, government produces little software. I mean, there's some pockets within government in federal environments that, that develop software in-house, but by and large, they, they acquire a lot of software. And I think the government realizes there's a lot of risk associated now, given, given the widespread of adversary attacks that we're seeing in terms of how, you know, how to compromise, you know, software. Now they're targeting— they got smart. They know now we can, we can just target the supplier, right, and infiltrate that. As opposed to going directly to the customer. We, if we know that the supplier has relationships with these customers, you know, who we want to target, hey, why not just target the supplier? Why go after directly after the consumer? We can, we can knock out a lot of different things by going after the supplier who may have relationships with some really high-profile organizations. So.

**31:25 Chris Romeo:** Yeah, so I think we, we talked about kind of the keys to a balanced approach. I'd like to transition now into I guess we got a couple other things we wanted to just touch on before we talk about the past a little bit and then the future. I'm curious what you mean by a software minimalism approach here. That's kind of an interesting— minimalism seems like it's one of the things that a lot of people are talking about just in general, like throwing stuff away out of my house and trying to lead a minimalized style life. How does that apply to software?

**31:55 Robert Hurlbut:** So I did a podcast in 2017 and I had a I came across a term, software minimalism. So I, I sought after the person who wrote the blog. His name was Brian Knapp. And essentially, it's the ability to reduce complexity in software, right? A lot of times we build software, we add so many different things to software, and a lot of times we don't realize that we're adding things, right? We're adding more and more. Think about You know, you go to a fast food, everything's supersized now. Give me supersized number 1. Give me supersized number 2. Everything in life, right, in our normal lives is about supersized. More is not better, right? We have to get back to sound fundamental software engineering principles where software minimalism is important, right? And when we say software minimalism, it's about building software with only the things you need, right? But it also is a— is an offshoot of software engineering, right? Being able to build software with least privilege, right?

**33:02 Chris Romeo:** Yep.

**33:02 Robert Hurlbut:** Which things are— these are things that are highlighted in the Cyber EO Section 4. Minimize sharing, the ability to reduce complexity and reduce attack surface. I think that's important because that— our focus have to be on software resiliency. And we can't have software resiliency if software is so complex that it exposes attack surfaces and different entry points that can be— that can be attacked. So we have to get back to the fundamental point of software minimalism. And what he also indicated during our interview is there's something called software gravity where features and complexity pulls towards a system over time. And that accumulates— essentially, you're accumulating technical debt. Right. By bringing more complexity into your environment. And what we know for sure is that in a competitive business marketplace, right, where people are always trying to gain a competitive advantage, right, and a lot of times features become very important, right, features and functionality become important. How can I create new features or functionality that can differentiate me from my competitors, right? But the problem with it is more features means more complexity. More complexity means code, and more code means more attacks, more cyberattacks going to happen. So we got to be mindful of that, that we need to get back to the, the core of what we know from software engineering, software engineering, that software minimalism play a key role in bringing and helping us establish cyber, cyber resiliency so we can adapt and be able to respond and recover from cyberattacks that are happening. So, and also it reduces— it helps reduce the cost to maintain software. And a lot of times organizations are, are so, uh, in debt with, with, you know, they accumulate a lot of technical debt that increases the cost to maintain software because there's so much complexity with it, right? The goal is really trying to reduce the, the amount of technical debt which can have eventually reduce the cost of maintaining software because it allows you to respond quicker. You know, given, given that the adversary is doing so many different things to attack us, we need to be able to simplify things so we can respond a lot faster and quicker.

**35:26 Chris Romeo:** Yeah, I like that term. I'm gonna, I'm gonna, I'm gonna bring that term forward and I'll provide attribution to you for the first 3 times I use it, of course, Kevin, as is normal industry practice.

**35:37 Robert Hurlbut:** That's fine. Brian Knapp is a very Smart Developer, who, who we had a great conversation, um, on my podcast about it. And I think these are one of the things that just rings dear to me because I think it's something that's not taught, obviously, and it's something that is so essential to real resiliency in software. So I think it's important for us to at least understand that. And, and with these new things that are being called out in the Cyber EO, we're able to try to get back to some of those basics that are so fundamental in software security.

**36:12 Chris Romeo:** Definitely, definitely things that, you know, if you go back to the history of computer security, it's— there's a lot of simplicity is what was practiced and what was described as the way security should be done. You know, going back in the '70s and '80s in that timeframe before this whole internet thing and networks and everything complicated the world of security. But there's something to be said about simplicity. That's, that's a focus that I like to apply all the time. So let's talk about learning from the past. You know, we've been software security, we've been kicking this thing around for quite a while. And let's— I'd love to draw kind of your thoughts about what can we learn from the past.

**36:53 Robert Hurlbut:** And there's so many different things that we can learn from the past. And, and, you know, the funny thing, the past is not too, too, too much of a distance to us, right? But given the rapid pace of software and modern software development, 2 years is obsolete in a lot of regards, right?

**37:15 Chris Romeo:** Yes.

**37:15 Robert Hurlbut:** 2 years is obsolete because there's always something emerging. But a couple of things that come to mind, I mean, the last 3 or 4 years we've been talking about, you know, shift left, shift left, shift left, right? I want to change that. I think we need to push left because people are not shifting fast enough. We need to push left. But learn from the right. And what I mean learn from the right is we need to codify the things we know about how adversaries are trying to attack us, right? And learn from that and use it as continuous learning to inform the, the far left things that, that, that I talked about that goes into concept, right? The concept of, of new features and functionality, concept of, a new software design. We need to learn from that, right? And, and when I say the right, right meaning red teaming, penetration testing. There's a whole taxonomy that MITRE created around ATT&CK, right? MITRE ATT&CK, you know, really understanding adversary tactics, techniques, sub-techniques that are used to gain certain things or achieve certain, certain objectives that they're trying to do to to compromise systems. There's things we can learn from the right side, the operational aspect of software development, right? And we need to be able to use that and learn from that and push left with that, right? So we can build these things, right? Codify— I wrote a paper on dark reading, an article on dark reading about codifying intuitions, and I learned something by having I was watching a Microsoft presentation and it was this engineer talked about how, how he was able to, you know, do bug bounties and things of that nature. And what he said was he was able to leverage his intuition, things he knew from the past, you know, his experience of how breaking, fixing, building software, right? He used that to, to, to, to help exploit certain things in software, right? I think we have to kind of take a similar approach and codify that in concept so that we're building software from the start. And the other thing learning from the past is, is technical debt creates so much chaos that it causes organizations, or it, it slows organizations' response to cyberattacks. Right? Because sometimes you got to coordinate downstream with suppliers, you got to coordinate with stakeholders. One thing we do know, the time, the window of exposure seems to keep sliding to the right. And the reason why it's sliding to the right, because there's so much technical debt people have accumulated over time, it becomes very hard to, to patch in a timely fashion. And not to mention, the time to exploit is shrinking. Right? We know that the Apache Struts vulnerability was— there was a 3-day timeframe from the time the vendor released the patch to the time that we saw things on the internet, people were looking at the exploits that were going on with the Apache Struts vulnerability, right? So there's like a 3-day window, right? That's real small and in terms of— that's real fast in terms of, in terms of, you know, being able to respond. Most organizations have so much technical debt, they can't respond that fast, right?

**40:49 Chris Romeo:** Mm-hmm.

**40:49 Robert Hurlbut:** So we've seen, you know, these are the things that, that we need to think about. And the other thing is threat modeling is so valuable and we don't use it. It's an opportunity for us at concept to think like a hacker, right? And/or adversary. I mean, you know, I don't wanna use the word hacker 'cause hacker has certain, you know, means certain things, but I wanna say adversary. adversary, right, a motivated adversary, a skillful adversary. This is an opportunity to do that and really develop good misuse and abuse cases that we can bring into the software development process. So the whole product team is thinking about ways in which software can be attacked, right? So developers are understanding how they need to code to prevent certain things from happening. And I think The realism in associating, or, you know, the realism that threat modeling brings in associating specific ATT&CKs, right, proof of concepts that we know exist in the wild or exist somewhere, it can be codified in that process to help, you know, us build better software. So I think these are things that we need to really think about, and tools need to improve, right? Tools haven't kept pace, right? So if we're gonna do, uh, use tools to automate, we have to have tools be better in terms of, in terms of improving their techniques. I'm realizing, we're realizing now that, you know, there's no such thing as an uber tool. You know, the sum of many is better than the sum of one. That's always, I've, you know, it's been my, my slogan. The sum of many is better than the sum of one. And each tool find different things, but the context of these tools become very important. and really understanding and getting visibility in the software because this software is so complex. And I think adversaries are finding really unique ways to target us. So I think these are things we have to learn from the past and use going forward to try to, to try to improve the state of the art and state of practice around software security.

**42:49 Chris Romeo:** Yeah, I got a couple, couple reactions to a few of the things that you said here that I'll share, and then we gotta quickly talk about the future. Because we can't just focus on the past, we got to look at the future. But to your point on push left, learn from the right, one of the things I think we got to be careful of is as an industry we focus on hack the planet, red teaming, pen testing, like that, that's what gets all the attention. And I understand that's where a lot of the, you know, cool things are happening, you know. Understanding how to prevent a SQL injection is not as cool as exploiting a vulnerability and, and getting access to something, you know, kind of having that moment. But I think, I think we just have to be careful and ensure we don't put so much emphasis on red teaming, pen testing as the end-all be-all, because guess what? A pen test never fixed a single vulnerability at the end of the day. It just, it just didn't. So, no, great modeling.

**43:47 Robert Hurlbut:** But I do think I do think that we have to connect the dots with red team back to product teams and developers and architects. I think that's the piece that we need to do because red team do provide some valuable information, some valuable context that's important to overall software development. And a lot of times Because of silos that we've created with, with people who use DevOps or who don't use DevOps. There's still silos. I don't think anyone has totally fixed that silo problem. I think there's some improvements, but I do think that how do we connect the dots and create that continuous learning feed, right? That is, that is able to help developers understand ways in which, you know, adversaries attack. And I think red team has a lot of that knowledge that can be shared to help, to help make the transition, to make the process more seamless in terms of having the balance that we need to improve software and learning from, you know, what the adversary is doing, or even threat hunting to a certain extent and leveraging these, you know, more forward-leaning approaches. Right, that has a lot of times been disconnected to, to the software development process. We need to figure out a way how to connect the two and leverage that and leverage that information.

**45:16 Chris Romeo:** Yeah, and I'm not saying pen testing, red teaming is not important. I'm not saying it's something we shouldn't do. I'm just saying we have this industry view of it as the best thing, the most important thing, the, the thing that gets all the attention because it's flashy and I'm much more about how do we, how do we fix the vulnerabilities? How do we, how do we identify a problem during a threat model so that when we get to pen test and red teaming, it doesn't exist? It's not there. Nobody could find it because we already fixed it in our secure design process. And to thinking about threat modeling, I'm a huge proponent of threat modeling. I spend a lot of time talking about it. I got a chance to be a part of the Threat Modeling Manifesto. So for our audience, if you haven't seen that yet, go check out the Threat Modeling Manifesto was myself and a group of 14 other folks from across the industry wrote a document about what defines threat modeling, what, what is, how do you be successful in using threat modeling. So it's something that you should definitely look into because we got to do a lot more of this because if we are going to shift left, if we're going to push left, we got to— threat modeling's got to be the key that enables us to eliminate a lot of these problems before they ever get further down the line to be considered from a pen test or red team perspective. We got to talk about the future, Kevin. We advertised in the beginning of this that we were going to talk about the, you know, some key things, some the past, and then we got to talk about the future. I guess I have your answer to what you think about the future here. The future is unknown, but I know you got more to say about the future than that.

**46:48 Robert Hurlbut:** Yeah, I'm, I'm, I don't want to be pessimistic, but I You know, given, given where we are in terms of how the pace in which software, modern software development is moving, looking at some, you know, the, the EO to me is a, is a telltale sign because a lot of things that's in this EO, I mean, when I say, let me, let me, let me preface this, Section 4, the software assurance, software security piece.

**47:16 Chris Romeo:** Yeah.

**47:17 Robert Hurlbut:** a lot of that language was already in the Underwriters Lab 2900 series documents. And it surprised me that no one leveraged that information, you know, as part of, you know, the EO. So it's kind of confusing to me. But I don't know. I, you know, I want to be very optimistic, but I just think that software is moving at a very fast pace. It's ubiquitous, right? It's It's in every, every aspect of our lives, right? And in, in, in adopting something like DevOps, we've created a certain cadence, a certain speed in delivering software that, that to me is, is feature-driven. Functionality-driven, competitive-driven, right? To keep, to keep, to keep a competitive edge. All the business drives like the pace in which software is moving. And because of that, I think, you know, we've taken shortcuts, right? We've, we've had poor designs. We've, we've, we've had a lot of things to me, which speaks to the accumulation of technical debt. So I'm afraid that we've accumulated so much technical debt. That we can't pay it off, and eventually at some point you gotta pay. You you're going to be a result of a major cyber breach because you you can't continue to move at this pace. You know, with complexity of software and and and the size of software is growing as well because of the complexity. So at some point. the danger of technical debt scares me, right? And when is the right time to pay it off, right? Like being— or just being aware that you've accumulated a certain amount of technical debt that's preventing you from moving and moving fast on the maintenance side, right? You know, we keep saying speed is the new security. Yeah, but speed can also help you introduce vulnerabilities faster as well. So we have to be— Yeah. Be mindful of that. And then also cloud is growing. I see the future outlook cloud. More people are moving to the cloud. Kubernetes and microservices are going to continue to be the way of computing, and I think that's a good thing. I think that's a good thing, but it also creates a larger attack surface for a particular adversary, right? If you hit a major cloud provider, then You know, chances are you you may strike gold, right? So you know, hopefully, you know, with language in the EO, you know, talking about suppliers and understanding the importance in providing assurances to consumers, I think consumers have to put pressure on cloud providers to make sure certain software security practices are followed religiously, making sure that there's artifacts to support. the attestation of these things, and having a way to audit this on a regular basis so that you have some level of trust that software is being developed to protect your mission needs. I think that's important. The other thing is not just shift left, balance both ends. And I think a lot of times you talk about, you know, you just mentioned previously about heavy focus on red teaming and penetration testing. Well, that's— if you look at a seesaw, that's, that's not a balanced approach, right? To me, a balanced approach is, as I mentioned, learning from both ends and using that collectively to build situational awareness around software security. So both ends are aware of things that could go wrong, things that will go wrong. We can infer things about what we've seen that, you know, we can leverage AI in a powerful way to reason about software, to reason about things that we see from testing and things of that nature to build a more comprehensive and a more integrated approach to software development. Because software development has changed. There's cloud, there's microservices, there's Kubernetes, there's software-defined networks, there's So many different aspects now that are coming to the fold. So I think it's important to not just shift left, but balance both ends. And then, as I mentioned, there's a greater focus that's going to be on software security testing. You know, people say you can't test your way to a secure app. That is true. But what you can do is you can provide visibility, right, into your issues so that you can, you know, test them and find these things early by combining quality and security early in the process, integrated automated testing, so that you can find things early and fix them and have a way to remediate these things so that we can, you know, have a way to mitigate and prevent these things from happening, but also have a way to detect potential targets that adversaries are going after. So I, I do think that the future of software, while I'm somewhat pessimistic, I do think if we can turn the corner of some things that are working and abandon things that are not working, and ultimately, you know, we have to reduce our appetite, right? We have a humongous appetite for, for more, more, bigger, better, and that tends to lead to complexity. And I think we can reduce that. I think we can help clean up some of the things that we see around software security and create a healthier software world.

**53:06 Chris Romeo:** Yeah, the future, the future is bright, right? I don't think, I don't think we, I don't think we need to be afraid of where we're going. And I think, you know, with a number of different things you're describing here, you know, this is— you're not afraid of where we're going. You're just saying, hey, we've, we've done some things in the past, so we got to pay off this technical debt. We can't keep pushing it forward, forward, forward into the future. The cloud's taken a bigger place. One of the things that I'm excited about is the cloud providers are really starting to get some controls together that you can really deploy. And if you, if you think about it and put those controls into play in one of the major cloud providers, you can come up with a really secure solution. That's one of the things we've been studying over the last couple of months here. And then, yeah, I mean, not shift left, balancing both ends, you know, start left. Shift left, shift right, you know, shift every direction, shift up and down. I mean, we want to see security embedded into every piece. And the only thing I'll throw into the future outlook is I have a simple request. Can we just move injection off from the number 1 spot in the OWASP Top 10? Can we just fix that, please, as an industry? Even if it's number 2, I'll call that a win. But I'd love to see it eradicated from the OWASP Top 10 so we've got a whole bunch of new things. And that's what I think is ultimately going to happen is there's going to be new types of attacks and things that come in. And we're going to start to see some of these things that we've been working on for a long time make their way out of the way because the frameworks and whatnot are going to fix them. Kevin, thank you.

**54:34 Robert Hurlbut:** Our goal as an industry should be by the time of the next OWASP Top 10 release, injection will be low or even not on the list. And if we can make that concerted effort as an industry collectively through technology innovation, security awareness and training, I think we can do some really, really good things in the future. But, you know, it, it is— it has to be a collective effort. You know, there can't be one person or one, one, you know, government telling us, you know, how to go about achieving software security. I think it has to be a collective effort where all stakeholders come together and really solve a very, very challenging problem that we've been, we've been, we've been you know, trying to figure out for the last decade and a half. So I think if we can do that, I think that's progress. Chris, that, that was a good conversation in terms of really trying to figure out ways we can move the needle forward. Even if it's really small things that we can do to improve software security, I think that's the The major thing that, you know, I wanted to share and get across to our audience. I think it's important that we do look back and learn from our past, but also, you know, really take a clear vision and say, okay, the things that are not working, we need to abandon those things. And we need to try to either fail fast and try to do more forward-leaning things. But obviously, we need to do something to keep pace and try to get control of of all the things that we're seeing in terms of software security, because everything, right, software security is our first line of defense in stopping and mitigating any cyberattacks. So, you know, I think this is a great conversation. I think, you know, we can continue. I think there's a couple questions I think they were asked. Do you see the questions in the queue?

**56:29 Chris Romeo:** Yeah, yeah. Let me ask you this first question. And I'll give, I'll give my opinion after, but I want to hear your take on this first. And The question was, you know, we talked a lot about shift left. So whoever asked this said, what about starting left instead of shifting left? Wouldn't it be more efficient in terms of implementing security by design and by default from the start? Good question. What's your thoughts?

**56:51 Robert Hurlbut:** I think that's— I think that is a really good principle. But unfortunately, I don't see that as a common position or a common practice in an organization. I do think that, you know, starting and building security in from the onset is very important. And that's why I mentioned in the— in the— in the— in this talk is that, you know, the entire product team, right, when new features and functionality needs to be onboarded, the entire product team is thinking about ways in which these new features can be abused and misused, right? And developers are aware of their coding and refactoring activities in eroding a design or creating more vulnerabilities or creating bugs, I should say, that can expose vulnerabilities in software. So I agree wholeheartedly that we need to do more design thinking, right, and have secure by design and leverage some, you know, fundamental software engineering concepts like reducing attack surface, Software minimalism is one thing that we can potentially do, right? A lot of these systems now being built, there is so much things that are being added, you know, we keep onboarding new features and functionality, we're not deprecating things that are not being used, is exposing attack surface. So I agree, we definitely have to do more secure by design, and figure out a way to, to make things more simple.

**58:22 Chris Romeo:** Yeah. Yeah, I kind of think of shift left, shift right, start left, start right. You know, if you put all these things together, what do we get? Secure development lifecycle. This is the thing we've been talking about. I've been talking about this for 10 years. So I love, I love how these things are all coming together. But I think starting left, we used to call it build security in, remember the old days?

**58:45 Robert Hurlbut:** Yeah.

**58:45 Chris Romeo:** It was build security in, that came out of DHS, I think, as well. Now we call it shift left, but it really, it's the same idea. Like, we can all agree that if we start applying security best practices from the moment we draw a new product on a napkin, it's gonna be better than if we wait until we're in production. Like, I don't know anybody on earth that's gonna argue that with me, but when I think about it, I think like start left, start right, start up, start down, you know. Starting left is, thinking from the requirements phase, starting right means we're considering things in production. We've got, you know, solutions to be able to help us check our security in production. It's really bringing all those things really together. So we got another question in here, and this is one that I think is another great question. What are our— question the person asking is saying, what are our thoughts on the ability for infrastructure and code and infrastructure Infrastructure as Code's ability to provide security when deploying provisioning resources. So I know I got an opinion on this one, but I want to hear your opinion first. What's, what's your thoughts on IaC and IaC security in general?

**59:54 Robert Hurlbut:** No, I think that's important. I think any, anywhere where we can have the opportunity to, to, to incorporate or embed security, either through some practice whether it's through DevSecOps, whether it's deployment of infrastructure, is an opportunity, right? Secure— treat security as code and have it, you know, go where we need to go, enforce a policy when we need to enforce a policy. I think that's very important. And we're seeing more and more up-and-coming companies and organizations take this on, right? They're really trying to leverage infrastructure as code. and build better security practices in it, right? And leverage security as code by means to do that, right, and be able to deploy securely, right? So we talked about the software development piece, right, and being able to develop the software. But I think deploying securely is very important as well. And we can't, we can't overlook that. So I think that was a great question. And I think, you know, the person who asked the question, thank you for asking that. I think you know, we have a tendency to focus so much on the software development piece. I think the deployment piece is something that we're seeing that there is an array of attacks that, that can be targeted for that. So obviously building that security element into our security practices and how we deploy infrastructure is very important as well.

**1:01:17 Chris Romeo:** Yeah, I mean, in a DevSecOps world, IaC, infrastructure as code, is, it's table stakes, right? Like, I'm old school. I'm from the days where we used to, like, get a server out of the box, put it in a rack, and then we sit there and load an operating system on it, and then we'd load applications, and, you know, 2 weeks later, we'd be ready to run something in production. Now, with infrastructure as code, it's a configuration file, it's a YAML file, and I just go, bloop, doo-doo-doo-doo, everything that would have taken me 2 weeks before is done before I finish the sentence that I'm currently talking about. But I think there is a big opportunity in when you're using infrastructure as code, I'm seeing a lot of examples where people are making bad— they're still making bad decisions, right? When you're— just because you're doing it in code doesn't mean it's perfect from a security perspective. You still have to have a hardened approach to your infrastructure as code. Good news is there's tooling that's helping us to do that, whether we're on Terraform, whether we're on AWS CloudFormation, whether we're using—

**1:02:15 Robert Hurlbut:** Right.

**1:02:16 Chris Romeo:** I don't remember what Azure's tool— I'm sure Azure has a tool to do it as well, but That this is the future. Like, if you're not there now, you need to be studying this class of tools and thinking about how we get there. The key takeaway is you got it.

**1:02:28 Robert Hurlbut:** You can't—

**1:02:29 Chris Romeo:** it's not secure by default. It's secure because you put security into your approach to infrastructure as code.

**1:02:36 Robert Hurlbut:** It's the thinking, you know, I always say, hey, if you have bad practices and you go to automate, you're automating bad practices. So we have to be careful not to automate You know, everyone wants to automate, but we have to make sure not to automate badness. We want to automate goodness into anything that we do as part of DevSecOps.

**1:02:55 Chris Romeo:** Yeah, most definitely. I think we've got time for maybe one more. Let's see. I've got a couple to choose from, so I'm kind of hedging my bets here a little bit on which one I want to hear the answer to, but I think the audience will want to hear the answer to as well. So answer this one for me. What's the value of using automated security testing to accelerate software delivery?

**1:03:15 Robert Hurlbut:** I think it's important. I think, you know, you know, the ability to do integrated where we're integrating quality and security earlier and getting it into developers' desktops and IDEs, so they can, you know, understand what's going wrong, being able to provide some continuous learning as they are coding right in their IDE. So that we can correct those, those things before it moves through the software development lifecycle. So I think it's important to automate and get tools in the hand of developers, right, and have that consistent stream of testing so developers can do it early and often, and they can correct the mistake before it moves through the process. And I think once we can do that, I think you'll see the other downstream processes moving a lot faster, a lot more efficiently.

**1:04:04 Chris Romeo:** So Yeah.

**1:04:05 Robert Hurlbut:** I think we need to wrap this up, Chris. This has been great. Thank you so much for, for, you know, sharing with us today. I think it was great. I think everyone who attended this session, please share and come back and view it again. And you have any questions, please let me know. I can be found on LinkedIn at Kevin E. Greene, G-R-E-E-N-E, and I'm looking forward to engaging with more folks about how do we improve our software future. Thank you so much.

**1:04:36 Chris Romeo:** Thanks, Kevin. Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjourney.com/resources/podcast. You can also find Chris on Twitter @edgeroute and Robert @parkerparker.

**1:04:55 Robert Hurlbut:** Robert Hurlbut.

**1:04:56 Chris Romeo:** Remember, with application security, there are many paths, but only one destination.

---

Source: https://appsecpodcast.com/thinking-back-looking-forward-a-balanced-approach-to-securing-our-software-future/