---
title: "Conclusion: All the Pieces You Need for an #AppSec Program"
url: https://appsecpodcast.com/conclusion-all-the-pieces-you-need-for-an-appsec-program/
date: 2018-06-12
duration_seconds: 1753
topics: ["OWASP Projects", "Building an AppSec Program", "Security Testing", "Software Supply Chain"]
audio: https://www.buzzsprout.com/1730684/episodes/8122680-conclusion-all-the-pieces-you-need-for-an-appsec-program.mp3
transcript: true
---

# Conclusion: All the Pieces You Need for an #AppSec Program

*June 12, 2018 · 29 min*

on [OWASP Projects](https://appsecpodcast.com/topics/owasp-projects/), [Building an AppSec Program](https://appsecpodcast.com/topics/appsec-programs/), [Security Testing](https://appsecpodcast.com/topics/security-testing/), [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122680-conclusion-all-the-pieces-you-need-for-an-appsec-program.mp3)

## Show notes

Which practices belong in a complete application security program? The Season 3 finale answers by assembling clips that move from early development decisions through testing, resilience, and runtime detection. Kevin Greene explains shifting left, Robert Hurlbut defines security champions, Pete Chestna distinguishes SAST, DAST, IAST, and RASP, and Megan Wu describes burnout and its warning signs. Jim Manico presents the OWASP Cheat Sheet Series, David Habusha explains software composition analysis and the Equifax example, and John Melton closes with OWASP AppSensor. Chris and Robert use the clips to show that AppSec is not one tool or one team; it is a connected set of technical practices, community roles, and sustainable working habits.

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 Chris Romeo and Robert Hurlbut:  
→ [Chris Romeo on LinkedIn](https://www.linkedin.com/in/chrisromeo-appsec)  
→ [Robert Hurlbut on LinkedIn](https://www.linkedin.com/in/roberthurlbut)

Mentioned in this episode:  
→ [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)  
→ [OWASP AppSensor](https://owasp.org/www-project-appsensor/)  
→ [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/)  
→ [National Vulnerability Database](https://nvd.nist.gov/)  
→ [OWASP Cheat Sheet Series](https://owasp.org/www-project-cheat-sheets/)

Chapters:  
00:00 Building a complete AppSec program  
00:50 Kevin Greene on shifting left  
04:58 Robert Hurlbut on security champions  
06:38 Pete Chestna on SAST, DAST, IAST, and RASP  
10:16 Megan Wu on recognizing burnout  
12:50 Jim Manico on the OWASP Cheat Sheet Series  
17:35 David Habusha on software composition analysis  
20:45 Could SCA have prevented Equifax?  
22:44 John Melton on OWASP AppSensor  
28:05 Closing Season 3

## Transcript

*4,754 words · assemblyai*

**0:00 Chris Romeo:** Like in previous seasons, we do a wrap-up and we hit the highlights on things that really stuck with us throughout this season. So we hope you enjoy that. And also, if you wouldn't mind, please visit the iTunes Store, and if you haven't already, please give us 5 stars and a nice review on the iTunes Store. Thank you. The Application Security Podcast. Here we go.

**0:50 Robert Hurlbut:** For this first clip, we go back to the beginning of the season to ask Kevin Greene, what is shifting left?

**0:55 Chris Romeo:** So shifting left to me is fundamentally the way we think about security. It's a mindset. It's not a catchy phrase that we often hear, build security in, shift left. Those are all catchy phrases, but at the end of the day, what I really wanted to get across in the article is it's a mindset that has to be pervasive throughout the software development lifecycle, and security must be at the conversation, must be seated at the table, and must lead the way to a certain extent, because at the end of the day, when we build requirements, we have to, we have to have security in the conversation so we're building good security requirements so that we can build good design, so that now we can take the design and implement it correctly in software and then code. So that's kind of my, my, my focus is shifting left. 50%, I should say, of security issues come from design, design architectural issues. So if 50% of actual security issues come from design, then how are we addressing design? We have to move further left. And I think, you know, we start from the beginning and build the right mindset where there's a shared responsibility across not only the product team, but developers, security architects, operations folks. I think we do a better job at, you know, one, reducing attack surface and also reducing risk that's associated with poorly developed, poorly designed software.

**2:15 Robert Hurlbut:** Now we must ask, why are people saying they can't shift left?

**2:20 Chris Romeo:** One of the biggest fundamental things I think is people just don't know how. They don't have a good strategy, and that becomes the crux of the problem. And once the train gets moving, you know, it's very— and it gets some momentum, it's very hard to slow it down.

**2:35 Robert Hurlbut:** Yep.

**2:36 Chris Romeo:** So from the onset, I think not having a really, really good sound strategy is one of the biggest issues that I see. You set yourself up to fail when you don't have a good approach, a good plan, a good strategy in place on how security should be governed throughout the entire process. The other thing is tools just don't perform well. I mean, we start talking about AppSec tools, specifically static analysis, and even some of the web application security testing tools, they just don't perform well. The coverage areas is very narrow to a certain extent. These tools have not kept pace with the rate, the rate in which modern software is being developed. So people get frustrated with the tools. These tools generate a lot of false positives, and because they generate a lot of false positives, developers get frustrated because obviously they have to spend so much time doing triage, finding the actual security vulnerabilities that really matter, you know, amongst a, a, a wealth of false information. So they take the tool out the tool chain and stop using it. And now we're building software and we don't have the proper tools to provide the necessary assurance levels that our software can be trusted and that we did a good job at testing it for potential weaknesses that can expose vulnerabilities in software. So I see that as a recurring theme no matter where I go, is one, not having a good plan approach, and two, We want to move fast, but automation is a big part of it. But how do you automate security testing tools when the tools don't perform well? So I think that has been, you know, a core, a core problem, um, in terms of trying to, you know, shift left. But even beyond that, you know, people just don't communicate well in organizations, whether it's the product team with the security team. These silos, these barriers You know, you got to go in this thing all in or it won't work. Meaning you can't wink wink, give a wink wink and nod and not be fully committed to building the necessary collaboration and communication that will break down those silos so that security is really a shared responsibility. So I think those are some fundamental issues that I see are some of the struggles that we, we get when we try to shift left.

**4:58 Robert Hurlbut:** Moving forward, let's ask Robert what a security champion is.

**5:01 Chris Romeo:** Well, in my experience in working with a company, I did work with one company where basically they, they brought me in as a security champion among others, and their perspective and my perspective was somebody who has typically some kind of development background, has an interest in security, application security, Ideally, they're working with development teams, project managers, others, and they're working with those teams as somebody who has an eye for security issues, can bring attention to those issues to the team, and can kind of be a sounding board, if you will, for certain issues and so forth. To me, that's that person. that you designate somebody who has that interest and you call that person the security champion for the development team or multiple teams. Maybe they have more than one team that they're interacting with. Yeah, so I guess to build on top of your definition, so based on my experience, I'm thinking of this more from the programmatic side of it. And so I'm thinking of a security champion as being somebody that I'm going to go out and recruit Like somebody that's a developer in a particular business unit or on a particular product team, somebody that I'm going to go out and recruit, and I'm going to then teach them about security and prepare them to be able to implement product security, you know, kind of outside of a core central security team within a bigger organization.

**6:38 Robert Hurlbut:** Now, let's head to the next episode to ask Pete Chesnough what the difference is between between SAST, DAST, IAST, and RAST bar? So SAST is one of the fundamental technologies inside of application security today.

**6:54 Chris Romeo:** It's static analysis security testing, it's what that acronym means. Think of it as an inside out. Some companies do it via source code, some companies do it via binary, but in the end, this is part of your CI portion of your CI/CD pipelines or the static analysis portion where you're running lint, you're running, you know, like your SonarQube type code complexity tools, you would also put this kind of SAST product in that space to be able to look at those check-ins to understand the security implications of the code that was checked in or be able to run it from your IDE. So one of the things that I always stress when I'm talking to people is whatever happens in that assurance case in the middle there where I'm doing my static analysis, that should be an open book test. That should be able to be run from my IDE, prior to check-in so I know I'm going to pass. So as you get your teams higher up the maturity curve, they become aware and intolerant of people not doing the right things. So as a developer, I didn't run my unit test because I was in a hurry and I needed to get out because my wife's getting aggravated with me, so I'll just check this code in.

**7:59 Robert Hurlbut:** Hmm.

**7:59 Chris Romeo:** And it breaks the world. So you have those tests afterwards to prove that you actually followed the right process. So that's SAST. It's an inside-out technology. It does not require your code to be running. Now, if we look at DAST, dynamic application security testing, this requires a running instance. This is automated pen testing, very simplistic automated pen testing, right? I can't— it won't do the things like infer business logic from the attack it just did, but it will do things like look at your security headers, look at input forms, make sure you're doing the right validation, look for things like cross-site scripting, look for things like information leakage. So, are you publishing the fact that you're using Tomcat version thus and such, or Spring, or what have you, so that way it gives information to attackers that they can then look and use against you? So, dynamic is an outside-in technology. It becomes— the application becomes a black box, and I can look inside of— you can look from the outside of that application. Now, as we talk about these technologies, these aren't the only 2 in your application security portfolio. portfolio, and it's important to understand that you want to look at it from multiple angles. SAST is a great tool. DAST is a great tool. Now we have IAST, or interactive application security testing. So if you think about this, this is a runtime agent that sits inside of the JVM or what have you that watches code execute. So if a dynamic attack is able to leverage something, it can see it, record it, And it becomes yet a different way of looking at your application dynamically while it's running. On the really fringes of this, we have RASP, which is Application Self-Protection, and think of that as that IAST product, but in blocking mode. So you take a look and say, hey, I see this SQL injection about to get triggered. Instead of doing the wrong thing, I'm gonna log it and I'm gonna return zero records. So it's a runtime protection portion of that dynamic analysis that kind of builds on everything. Then of course you've got things like software composition analysis to take a look at your open source tools. So there's a gamut of tools and you want to make sure you're looking at it from multiple angles, including pen testing, because nothing is better at finding logic errors inside of your application than a pen tester, someone that can infer behavior from, from results.

**10:16 Robert Hurlbut:** Next, we need to ask Megan Wu what burnout is and how we can tell if us or our coworkers are burning out.

**10:23 Chris Romeo:** What it is is a chronic state of stress. You know, we all experience stress, but it's usually characterized by things like chronic fatigue, insomnia, physical symptoms like dizziness or like upset stomach, increased illness. A lot of signs of depression and anxiety can be a sign that you're burned out or on your way to becoming burned out. Just like a huge psychological shift in like your mindset and how you view things. It's easy to feel overwhelmed. Like, things that might be a bump in the road before all of a sudden become like these insurmountable mountains. So I guess from a more like textbook definition, it's chronic stress that leads to physical and emotional exhaustion. Cynicism and detachment, and also feelings of ineffectiveness and lack of accomplishment. So I think the biggest thing to do is kind of keep an eye out on your friends and coworkers for when they start acting outside of what they normally act like. So if all of a sudden they're a lot more forgetful than usual, or one of my telltale signs is that I'm like close to burning out or am getting overworked or overstressed is I start getting more and more late for things. Like maybe 10, 15 minutes. Like usually I'm really on time. I'm one of those, if you're 5 minutes or if you're on time, you're late kind of people, right?

**12:04 Robert Hurlbut:** Yeah.

**12:05 Chris Romeo:** So that's like one of my strongest signs. And my husband's just like, hey, you might need to to take a step back or, you know, take a few things off your plate because I'm running around like a chicken with my head cut off. Or if all of a sudden something that I'm really interested in, all of a sudden I just drop it. Like if I was— so for example, volunteering and mentorship is really big for me. But if I get to the point where, oh, I don't see the point of this anymore, that's another huge warning sign. If someone's like, oh, Well, I do like this, but I don't know if I'm going to keep doing it anymore, just because, without any kind of real reason.

**12:44 Robert Hurlbut:** Jim Manico, a longtime friend of the show, joins us next to discuss the OWASP Cheat Sheet program.

**12:50 Chris Romeo:** So the OWASP Cheat Sheet series is a series of wiki pages. That's it. It's a series of wiki pages that contain a collection of high-value information on web security topics. It was originally built primarily to be developer guides, like how to stop cross-site request forgery, how to deal with access control, how to do third-party JavaScript management, Java Bean validation cheat sheet, little digestible topics specific to developers. The intention is we're basically writing a secure coding project in some way where all the different subjects would be maintained independently and autonomously at different paces. And, you know, it's done pretty good in that area. This is some of the most heavily hit pages within the OWASP Foundation. And we also have folks from the assessment world, the mobile world, the defender world. There's a lot of draft work that we have that hasn't been published yet, that's still ongoing. And so, yeah, it's just a collection of single-topic guides on primarily secure coding, but just AppSec in general. Oh, wow. I wish I had the exact date, but it started It started perhaps even 10 years ago. And I'll give props to the true original creators of cheat sheets and OWASP. This was like the first 3 people, I believe, were Jeff Williams, who did the XSS Defense Cheat Sheet, Dave Wickers, who did like the SQL Injection Cheat Sheet, and Eric Sheridan, who did the Cross-Site Request Forgery Cheat Sheet. And from there, like I jumped in, again, other people's work, but I jumped in and built a wrapper project around that, helped participate in the original cheat sheets, and helped expand it from a 3-cheat-sheet project to like a 30 or 40-cheat-sheet project that we have today. And again, this is not my work. There's literally, I'd probably say about 50 different authors who have actively done major contribution that I've interacted with in some way over the last many years. So it's a large community of people, the idea being that individual experts on individual topics can jump into one, you know, one micro topic and make it great, make it awesome, so it's sensible for developers who want to address that particular risk or defense category. Again, the theme of the podcast is, you know, it's a lot of other people assisting and doing work to make it happen. Well, how do they come up with ideas? How do you get people to do these cheat sheets, and how do they then say, hey, I really want to do this, I have a topic I'd like to talk about? How do they get into putting these together? It's a combination of ways. Like, early on, to really build the project, I went out and recruited people. Like, I knew people who were like, yeah, Robert, I knew people. Yeah, I know people, right? So, hey, you know people? Yeah, I know people. So, I know people in AppSec, and I would go and try to guilt them into volunteering their time, or I'd see open-source guides, contact the author and say, can I port this to OWASP and have you keep working on it? And most everyone is very cool about it. Like at one point, I'd say one of the most popular guides in AppSec, if we go back over 10 years, a very famous guide, it was the Filter Evasion Cheat Sheet over at Hacker's website from Robert Hanson. And this is a massively hit artifact that we ported over to OWASP, because he was closing down his site. So there's a second way. Some people just want to migrate content that fits to the series here well. The third way is people will— now that the project has gotten uptick, now that we've recruited enough people, enough people have volunteered to do missing topics, now that we've got momentum, we just get a lot of people who just want, want to add to the project in some way. And, you know, our goal as leaders of the project is to help facilitate getting the writing done, sometimes help tune up the wiki, and to make sure that we're adding the right content, right? So, you know, and we're making— we're making sure that we're curating properly in some way. And I've been very casual in how I do it, right? I'm just very happy to get writing contributors. As Dominique joins the project as lead, he's putting more of an academic bent on it, a little more of a fine-tooth comb on it, and putting more rigor into the content than I have in my leadership there. So this is great. We need fresh blood to push, make it even— to make it better, right? And so that's kind of the transition we're under and what we're working on now. And keep an eye on our roadmap. You'll be able to see plans that we have to make things better.

**17:35 Robert Hurlbut:** Now we go to David Habusha to find out what software composition analysis is and why we should care.

**17:41 Chris Romeo:** Yes. So the concept of composition, what does it— what are the ingredients that it takes to actually build something? And applications, modern applications, are built on top of existing software components, many of which are open source, because reinventing the wheel is very expensive. So we don't do it. I don't go out and reinvent an XML parser or a persistence layer. I use readily available components for that. And the packaging and what components I'm actually putting together in various orders is really what software composition analysis is all about. It's a supply chain issue, and unfortunately the market researchers you mentioned, Gartner and Forrester, unfortunately they're coming to this problem at a very software-specific angle, and it's much more than that. It's actually a full supply chain risk management issue because, as we've recently discovered, hardware too. can have vulnerabilities.

**18:48 Robert Hurlbut:** So it's, it's definitely a full supply chain issue.

**18:53 Chris Romeo:** The types of issues that we see in the news and whatnot, it's primarily focused on software. You know, the big breaches and whatnot, these are all software problems, but it's not limited to just software. Okay, and so I guess why do we care about these tools, or why do we even need these type of tools to be included inside of our programs? The usage of vulnerable— or the usage of components in general really drives a faster time to market for organizations. Organizations can quickly build applications using readily available components because, again, reinventing the components is really expensive and time-consuming. So just building on top of existing components that are, that is out there really drives acceleration. And when you have a known vulnerability, at the point where it's known, the attackers are already weaponizing it. In fact, by the time it's known, the attackers probably already know about it because the definition of known means that it had to be analyzed by somebody. Somebody had to actually wait a certain period of time for responsible disclosure and whatnot before the item is fixed and then eventually published. Well, in the open source world, you know, GitHub repos are wide open, so the adversaries are constantly analyzing our code anyway, and the fact that it's not known at the time, well, the attackers might actually know about it well in advance. So it's a— the time to mitigate these issues becomes exceptionally critical. There's a very small window to actually mitigate these types of issues, especially when your adversaries, nation-state actors and whatnot, are weaponizing it en masse.

**20:45 Robert Hurlbut:** Let's ask David if software composition analysis would have caught the Equifax breach.

**20:51 Chris Romeo:** Would SCA have caught the Equifax breach earlier in the process if they were truly doing it at a high level?

**20:57 Robert Hurlbut:** Absolutely.

**21:00 Chris Romeo:** First of all, it would have caught it, yes. In fact, we, the dependency check team, Jeremy Long, myself, a few others actually analyzed when the vulnerability appeared in the NVD versus, you know, when the issue was actually discovered by Equifax. And the open source stuff that we were working on at the time could have very easily identified the threats issue. It doesn't— that also brings up some other interesting problems why components and upgrading them can be challenging. But just being able to identify those components sometimes isn't enough because the components are an inherent thing of the overall application. If you don't constantly keep on updating the components, vulnerable or not. If you're not constantly in a place where you're, you're always updating your components, if you wait, the problem is, is that if you wait until it's, it's, it's something has been published, you might have waited, you might have introduced some, some, some issues where the underlying library that you're using has changed, the APIs have changed. And so simply dropping in a new version of that component, that doesn't work anymore because the APIs have now changed. So if you're not constantly updating your code to use new and newer versions of those components as just a best practice, it's very hard for organizations to respond when they absolutely have to do a 24-hour turnaround to mitigate something.

**22:44 Robert Hurlbut:** For this final clip, we head to John Melton to discuss the OWASP AppSensor project. That turns out to be one of the more difficult questions to answer for most people. AppSensor is a project with OWASP, the Open Web Application Security Project, and it's an odd project in that it essentially has 2 components. Most projects within OWASP are one thing. They are a tool.

**23:14 Chris Romeo:** Yeah.

**23:15 Robert Hurlbut:** Or they're a documentation effort, or something along those lines. So this one turns out to be 2 things. This one is a documentation effort, and it's also a reference implementation of that idea, right? So I like to generally tell people the idea is the most important thing, even though I'm the one that works on the tool primarily. The idea is the most important thing, and then there's a reference implementation. So So the idea is essentially, um, it, it's kind of trying to bring the operational aspect of security back into the application security realm. So most application developers, their familiarity with, with security probably does not extend much beyond the OWASP Top 10, if at all.

**24:05 Chris Romeo:** Yep.

**24:06 Robert Hurlbut:** However, there's a whole bunch of things that they naturally do as part of software development that they understand very well, right? Exception handling is something that everybody has to do. Building functional requirements out into your systems is something that they understand very well. And in most Agile shops, at least, we have this concept of use cases. And in many shops, there's also this idea of abuse cases. How could somebody abuse the systems? That's really the sweet spot for AppSensor. The notion is, if I'm doing something in the system, I've built this happy path through my system, which is how I expect users to use the system. Well, there's always the attacker route. There's always the path that is less traveled.

**24:55 Chris Romeo:** Yeah.

**24:55 Robert Hurlbut:** Somebody, either a benign end user accidentally goes down the wrong route or an attacker purposefully goes down the wrong route. Either way, there actually turns out to be a lot of things that we could prevent if we just thought about those exceptions and handled them appropriately. So the canonical example I always give is, let's say you're building a banking application, right? You log into online banking and you see your checking account and your savings account, and maybe you have, you know, a money market account or something. You have a few accounts and you get that master list. Well, if I go and click into my checking account to see more detail, logically what's going on behind the scenes is I'm clicking on something that the application presented me with 3 accounts, and those are identified by individual— some form of an identifier. It may be a database key, it may be a GUID, something like that. I click on that and it takes me to more detail. Well, that's an access control issue, right?

**25:58 Chris Romeo:** Mm-hmm.

**25:58 Robert Hurlbut:** I have to go in and view that data. In order to view that data, I need to have access. So when I view my master account, the system is presenting that data. When I go into view detail around that one record, I am telling the system I want to view this particular piece of data. And so that's a classic indirect object reference bug where people forget to do that access control and they assume that If you've asked me for something, I'm going to hand it back to you. It's a select from database where this is the ID, and that can get you into trouble.

**26:30 Chris Romeo:** Yeah.

**26:30 Robert Hurlbut:** Well, hopefully most banking systems now prevent that. They do an access control check and they— what do they do? If it's happy path, they'll let you see your data. If it's not happy path, what do you do as a developer? You might log something, you might send an exception, to the end user that says you don't have access. AppSensor says go one step further. Send that exception. Just say, hey, something strange happened here. The end user did this and they did this activity that they shouldn't have done. That data gets sent off. You could think of it as this centralized logging system. It gets sent to this system and I'll talk a little more about what that system is in a in a second, but it kind of shunts it off to the side. And you can think of hundreds probably of examples of different cases where, okay, maybe you're building a wizard and somebody jumps to step 4 instead of going 1, 2, 3, 4. You could think of forced browsing where people are trying to find, you know, well-known paths on your system, right? Lots of things that attackers do or that that accidental end users do. All of that data is going to get fed. If you think about it, all that data from your system is now going to get fed into this separate system. And what that system is doing, what the core of AppSensor is doing, is it's basically keeping track of that data. It's storing it, and it allows you to apply rules to those, what we call events, that are coming into the system.

**28:05 Chris Romeo:** This is the end of season 3. We want to thank each of our listeners for listening to each episode throughout this season. We want to thank all of our special guests who joined us and shared their expertise and wisdom with us about the world of application security. And I can tell you that we're already planning season 4. It's going to be bigger, it's going to be better. Uh, we're going to be at various AppSec conferences over the next few months talking to lots of different people and collecting lots of new interviews. So stay tuned for season 4, which should start to drop sometime around August or September. Have a great summer. Thanks. Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and Teached. And the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/conclusion-all-the-pieces-you-need-for-an-appsec-program/