---
title: "Chris and Robert -- The Activities of the Secure Development Lifecycle"
url: https://appsecpodcast.com/chris-and-robert-the-activities-of-the-secure-development-lifecycle/
date: 2016-09-20
duration_seconds: 2647
topics: ["Threat Modeling", "Secure Development", "Security Testing"]
audio: https://www.buzzsprout.com/1730684/episodes/8122738-chris-and-robert-the-activities-of-the-secure-development-lifecycle.mp3
transcript: true
---

# Chris and Robert -- The Activities of the Secure Development Lifecycle

*September 20, 2016 · 44 min*

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [Secure Development](https://appsecpodcast.com/topics/secure-development/), [Security Testing](https://appsecpodcast.com/topics/security-testing/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122738-chris-and-robert-the-activities-of-the-secure-development-lifecycle.mp3)

## Show notes

Which activities turn a secure development lifecycle from an aspiration into repeatable work? Chris and Robert walk through security requirements, authentication and authorization, threat modeling, coding standards, approved libraries, code review, static analysis, dependency management, dynamic scanning, penetration testing, and post-release response. For each activity, they explain who benefits, when it belongs in development, and what it can reveal that another control cannot. The conversation emphasizes shared ownership: architects, developers, testers, operations, and response teams each see different parts of the risk. Tools support the process but do not replace design judgment or human testing. The episode provides a practical map of the SDL and shows how its activities connect from initial requirements through production feedback.

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 Top 10](https://owasp.org/www-project-top-ten/)  
→ [OWASP ESAPI](https://owasp.org/www-project-enterprise-security-api/)  
→ [Microsoft Safe C Library](https://learn.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt)  
→ [PSIRT Services Framework (FIRST.org)](https://www.first.org/standards/frameworks/psirts/)

Chapters:  
00:00 Activities of a secure development lifecycle  
01:45 Security requirements  
03:27 Authentication and authorization  
05:24 Capturing requirements in development work  
07:17 Threat modeling  
09:12 Identifying threats systematically  
12:14 How threat models help testers  
14:09 Secure coding standards  
15:52 Why developers need actionable guidance  
17:44 Approved frameworks and cryptography  
20:49 Code review and static analysis  
23:53 Owning third-party dependency risk  
25:18 Software composition analysis  
26:53 Triage and false positives  
29:38 Testing within the delivery process  
31:26 Dynamic application security testing  
33:07 Network versus application scanning  
35:23 Comparing multiple tools  
37:35 Why penetration testing still matters  
40:45 Product security incident response  
43:37 Secure software as a connected system

## Transcript

*7,069 words · assemblyai*

**0:05 Chris Romeo:** The Application Security Podcast. Here we go. Hey folks, Chris here. On this episode of the Application Security Podcast, Robert and I continue our journey through the foundations of application security. We explore the activities of the secure development lifecycle. We cover requirements, secure design, secure coding, third-party software, static analysis, and vulnerability scanning, and a few other things. But if you want to know what those things are, you'll You're going to have to keep listening. Our topic for today is the activities of the secure development lifecycle. And when we say activities of the secure development lifecycle, we're talking about what are the different elements or things that you can do in the development of your product or web application or whatever you happen to be building. What are the different things that you can do to improve the security of that offering during that cycle? And we're specifically gonna avoid, Robert, the discussion about methodology today because we'll cover methodology and how security activities play into methodologies in a future episode. And by methodologies, I'm just talking about Waterfall, Agile, and DevOps, which is what we'll leave for the future. Okay.

**1:45 Robert Hurlbut:** That makes sense. So today we're going to talk about activities, right? Yeah.

**1:50 Chris Romeo:** So let's kick off what I think of as the first security activity that occurs if you're going to build a product, or it should be the first thing that you consider. And that's this idea of security requirements. So are you a fan of security requirements first?

**2:06 Robert Hurlbut:** I am actually trying to understand what it is that we're trying to build and why. Because we've talked about this before, if we leave it all the way to the end to figure out what we need, it's so much more expensive and time-consuming to try to go back in and put it in place.

**2:26 Chris Romeo:** Yeah, to add security in at a later time. And so when I think about requirements, I think about what are the lessons learned that the internet has learned? Not that I guess the internet— can the internet actually learn something? I guess it can.

**2:41 Robert Hurlbut:** I think it can.

**2:42 Chris Romeo:** So we'll say the history of what we've learned in the kind of in the internet product cycle, there's a number of lessons learned or best practices. I'll give you an example of one that 99,000 out of, you know, 100,000 or whatever websites today have authentication. And so when I think about authentication, I think username and password, a window that pops up, and that username and password, I have to provide my username and password before I'm able to get into that particular website. So I think that's a big example of a requirement. And so, Robert, how would you add some more on top of that?

**3:27 Robert Hurlbut:** Well, you know, along with that is authentication is determining who you are. And then authorization. What can you do? So that's also pretty important as well. Just because you verify the person who is using your application, not everybody has the same access perhaps. You know, maybe an administrator, you want to do certain things that a regular user wouldn't be able to do. So you think about that as well. And that's another, again, a very good example of a security requirement.

**3:56 Chris Romeo:** And that's more on the authorization side, right, where where Chris and Robert are both going to log into this website, and Chris is allowed to do everything, and Robert's allowed to just do certain things. And authorization then would be a requirement while that system was being— that web application was being built. They would write down a requirement that says, we need to have the ability for different users to have different privilege levels in the application.

**4:26 Robert Hurlbut:** Correct, correct. And, you know, sometimes in the past people may think about that as roles or, as you said, different permissions or privileges. But exactly, that's all authorization.

**4:38 Chris Romeo:** So the other big thing that I think about with requirements is the fact that requirements have to be written down. They have to, they have to. So if you have a best practice that says that somebody has to authenticate when they come to our web application, before they're allowed to access any data or any other type of services that we have. It's important that that be written down though, because if you don't write that requirement down, especially if you're a development team of more than one person, you're never going to be able to translate or transfer all of those requirements to more than one particular project that you're working on. So it's, it's so crucial. I mean, have you experienced What's been your experience with requirements as a developer?

**5:24 Robert Hurlbut:** Well, it's interesting. Most times they are written down, maybe by an architect or maybe through various methodologies we've talked about where you're trying to figure out what do we need the system to be and what is it we're trying to build. And you may spec it out on a board or something like that, but ultimately just drawing it out is not enough. You need to write something down, and I agree, and that's what I've seen as well, that it's important to have some kind of concrete place or something, piece of paper, whatever it is, to keep track of those requirements that you've determined or the features of the system, if you will.

**6:04 Chris Romeo:** Yeah, and then those play in as security requirements. You can have general purpose requirements that define what is the general functionality that this product needs to do. But from a security perspective, security requirements are those things like authentication, like authorization, like encryption. What are the security properties that need to be enabled within the product for it to be successful? So what— why do you— why do we care? Why should a developer care about a security requirement?

**6:36 Robert Hurlbut:** Well, it kind of goes back again to that idea of building security in from the very beginning. If you don't have a goal or kind of an idea where you're going, you may never get there. You may hit all kinds of different ways of doing things as you go along without a plan. What we're talking about here is trying to come up with an idea of the things that we need and a plan to get there. And so, you know, that's, that's why we care, is it really helps us gives some structure and understanding among team members about what is it that we need here and why. And so it just helps everybody.

**7:17 Chris Romeo:** Yeah. So let's jump into the next security element or activity that you and I are both very passionate about, and that's this idea of threat modeling. So can you tell— can you give us just a brief explanation of when somebody hears threat modeling, What does that actually mean?

**7:35 Robert Hurlbut:** Well, essentially what you're doing with threat modeling is you're trying to understand your system and the security of your system a little bit better. You may be, let's say for example, diagramming the various pieces and parts of your system. I may have a browser, I may have a web service, I may have other parts, and then how you're transferring data between those. Sometimes we call that a data flow diagram. That's one way to model your system or to diagram your system. And that's just one part. The other part is that once we've done that, once you've, you know, kind of understand the various moving pieces and parts of your system that you want to build, then you think about, well, how is— or what could potentially go wrong here? What happens if I send data from my browser to the server? Is there a possibility of somebody being able to sniff the data?

**8:31 Chris Romeo:** Right.

**8:31 Robert Hurlbut:** as it's crossing? Yes. Oh, well then what do we need to do? It turns out we may need to or should probably put some kind of encrypted communication that goes from the browser to the server. So then that becomes, you know, we identify that as a potential threat. If somebody is able to get that data and understand it, then we wanna prevent that. And so the threat modeling aspect of this is understanding your system, understanding the potential threats in that system, and then figuring out ways to mitigate those or create countermeasures, and then, you know, plan out that as essentially your design of your system.

**9:12 Chris Romeo:** So threat modeling then is just a way to— it's a general process to identify what are the potential threats that could impact almost anything? Correct.

**9:26 Robert Hurlbut:** Yes.

**9:26 Chris Romeo:** So when I think of threat modeling, I think of— I always hear people, when I go in to start explaining threat modeling to someone, I'll say, hey, everyone in the room, go ahead and raise your hand if you've ever done threat modeling. And it's a room, it's a class on threat modeling, so most people's hands don't go up. But I said, you know, everybody in this room actually knows how to threat model. And people kind of look at me quizzically and they say, you know, what are you talking about? That's why I'm in this class. But what I mean and what I explain to them is you threat model every day of your life. You just don't realize that you're doing it. When you walk out your front door, you pull that door closed behind you, you start the threat— you begin the threat modeling process. You might hear a dog barking off in the distance. You're going to turn to that direction, look and see, is there a loose dog that's angry running in my general direction? There's cars whizzing by in front of your house. So if you're going to cross that street, you're going to, you're going to do a little bit of threat modeling. You're going to analyze that threat. You're going to say, is there a mitigation for that threat? Well, maybe the mitigation of those fast cars is that I need to go to the corner, push the button so that the light comes on and allows me to walk across the road, you know, without it, without being run over.

**10:39 Robert Hurlbut:** Right, right, exactly. And we don't even think about it. So yeah, that is definitely a kind of threat modeling.

**10:45 Chris Romeo:** Yeah. So it's— so threat modeling is applying that same type of a mindset and to analyzing the, you know, a particular feature. It could be a module, it could be a product even. It's just, it's applying that analysis, that security analysis to a given, you know, piece of technology.

**11:07 Robert Hurlbut:** Right. Correct.

**11:09 Chris Romeo:** So why do we care then about threat modeling? Why should a developer or a tester— let's talk from the developer's perspective first and then we'll come back from the tester's perspective. And so I'll let you answer the developer's perspective. Why do you care?

**11:21 Robert Hurlbut:** Well, the main reason why you care and what I found to be helpful with threat modeling is that it really helps you understand your requirements. It, uh, so for example, maybe I don't know that I need some kind of encrypted communication as I was talking about earlier, and then I determine, oh yes, I do, because there's a possibility of an attacker listening in on the communication that goes between these 2 points. Out of that, and the fact that I now know what I need to do to mitigate that problem or countermeasure that problem is I now have a new requirement. I now know this is something that I need to build into the system. And so as a developer, that helps to understand, aha, there's something I missed or something that I need to build here or develop here to, you know, make sure that we don't have a problem here, potentially somebody Compromising our system in some way.

**12:14 Chris Romeo:** So I'll answer that question from the tester perspective then. So, you know, why would a tester care about the threat modeling process and why would they need to do threat modeling? From the tester's perspective, the threat modeling, even if they don't do the threat modeling themselves, threat modeling is a great input into the tester's world. Because threat modeling gives you a list of potential security problems that could exist when this product's actually built and you actually begin to test the code that's deployed somewhere, whether it's in a staging environment or whatever. But so threat modeling can help the tester to have a better perspective on what are the security challenges that I could potentially use to find a bug in this product that I'm doing testing on.

**13:06 Robert Hurlbut:** Right, that makes sense. And so, yeah, you're trying to find out, again, as you said, from the tester perspective, what is it that could go wrong? Then I want to test it that way and understand, okay, this is what we found, this is the possibility, let's make sure that we're addressing it.

**13:22 Chris Romeo:** Yeah. Another activity that I'm thinking about here is what I and many other people refer to as coding standards. So when I think of a coding standard, I think of the need, and it's more difficult to think of a coding standard as an activity because it doesn't seem like there's any type of action there. But when I say coding standard, I'm talking about a secure coding standard. And I expect a development team to have a document that describes what are the expectations from a development perspective as far as how we're going to create the most secure code possible. So have you had any experience as a developer, Robert, with coding standards?

**14:09 Robert Hurlbut:** Yes, yeah, definitely. You know, many times on a team, we'll kind of come together as a development team, or maybe it's already some things have been decided, but at some point or another, somebody or a few people have come together and said, you know, here's some ways that we need to write our code First of all, to make sure that our code is consistent, that other people can work on it, not just ourselves.

**14:36 Chris Romeo:** Yep.

**14:36 Robert Hurlbut:** So that we're following, you know, conventions for naming and so forth. But when you talk about security coding standards, you're talking a little further about how do you write secure code. For example, SQL injection is a common problem. In fact, it's the number one issue still on the OWASP Top 10. We've talked about that before, and there's a certain way to address that in every language and every way that you write code, which is to use some form of parameter, putting together parameters as opposed to writing direct SQL in a string of some sort and sending that into the database. Every language has its own form format, but that in itself is a coding standard. So you make a decision from a security standpoint, we're not going to concatenate strings and send them into the database. We need to figure out a way to create parameters and send those in as a command to the database along with the command of the SQL statement. So that's a really good example of a security coding standard and a decision that you make among the team. This is how we'll write our code. This is what we look for when we do code reviews, for example, as well.

**15:52 Chris Romeo:** Yeah, and I think you address the why do we care in your answer there from a coding standards perspective, because the coding standards are what provide the best possible solution or answer for the developers. If we follow that guidance, then we're gonna have the best possible chance of having Not a, you know, less problems in our code when it gets deployed wherever it's going.

**16:21 Robert Hurlbut:** Absolutely.

**16:27 Chris Romeo:** So, another thing that— another item under that's kind of related to code but slightly— a slightly different topic is this idea of using secure libraries. And so, I'm going to separate this into a conversation that— oh, I'm going to call— I guess I'll combine it. Secure libraries and frameworks. I think that we can, we can talk generally about these. And, and the idea with a secure library or a framework is this is a set of code that you can import into your existing development project, and there will be some functions and some features that exist in that framework that do some standard things that you might normally write your own code to do, like process input or output data into the browser window. Right. And the idea with these secure libraries or frameworks is that somebody can reuse a time— a tested and verified and analyzed solution for doing a particular function instead of writing your own. And you're going to have a better chance of not creating your own security problems, for example, just with dealing with input or output if you use some routines that have been tested as part of a framework.

**17:44 Robert Hurlbut:** Right, right. And, you know, along those lines, I can think of several things that you would— you wouldn't want to write yourself. For example, cryptography.

**17:53 Chris Romeo:** Oh yeah.

**17:54 Robert Hurlbut:** Don't write your own algorithms. There are very good libraries that already implement these algorithms in the best way possible. They've already been tested. Along with that, I talked about SQL injection a moment ago. There are some really good ORM frameworks for which essentially are letting you be able to make connections to databases and send in data. And already underneath the covers in the libraries, they're doing the right practices for SQL injection with parameter handling. So again, there's lots of examples where Don't write your own, you know, security libraries, secure libraries, or libraries that have been written in a secure way are a much better way to go.

**18:41 Chris Romeo:** Yeah, I totally agree. And I have a couple of examples that I want to share for the listeners in case they want to know of an example for what are these secure libraries that you speak of. And so the first one is what's called— there's something called the SafeC library. And so our listeners probably know or remember that I spent 10 years working at Cisco as part of the Secure Development Lifecycle team. And one of the things that some of the engineers at Cisco did is they created this SafeC library. And what this library does is it acts as a wrapper for a number of different functions that exist within the C language that are known to not properly do bounds checking. And the idea with bounds checking is that when you take input in from outside of— from an outside source, you should always check to make sure that that input, especially when you're programming in the C language, that input is not bigger than the buffer that you're about to drop that input into. And traditionally, the traditional C from the 1960s doesn't have any type of bounds checking that's built into the language. You have to write your own. And that's what happens a lot of times is people will write their own bounds checking routines, but a lot of times they'll have faults in them. So this idea with the safety library is you take a routine like strcpy, S-T-R-C-P-Y, which is copying a string. And what the safety library does is it adds a routine called strcpy_s. And that _Scopy of the routine actually does the bounds checking for you before it actually calls strcpy. So they didn't rewrite strcpy, they just wrote a little wrapper that sits in front of it that does the input validation, the proper tested input validation, before it calls the actual routine. And so Safe C Library, something like this, ends up providing a better overall solution for the average C developer out there.

**20:49 Robert Hurlbut:** Right. Yeah, definitely a very good example.

**20:52 Chris Romeo:** And Microsoft actually released a Safe C library just recently as well. People can Google for that if you want to look up and see what, you know, what might be available there. From the Java perspective, OWASP has had this ESAPI program or project for a long time. It's a Java library that does some of these same types of web-related tasks like input validation and output encoding. The ESAPI hasn't really received a lot of updates, and so there's— so be on the lookout for some other things if you're using within the world of Java. I know things like Spring have a lot of these types of security routines now built into them.

**21:40 Robert Hurlbut:** As well as on the .NET side, there are several built-in tools that allow you to do encoding as well as decoding of data that comes back and forth. And so again, it depends on your language of choice and your tools of choice. There's lots of different libraries that are available, and it's always good to make sure that you know how to use them, what they are, and how to use them.

**22:04 Chris Romeo:** Yeah, definitely. And I think we probably already answered the why do we care, why do you care about this, but I'll summarize it up by saying that using those secure libraries, safe libraries, or frameworks will save you a lot of time as a developer because you're not going to rewrite things that people have already written well before. You're just going to reuse them. And so take advantage of the fact that developers in the past have created these routines for you. They've tested them. and they've proven that they work, now you can use them in your features and in your code. So another activity or element that exists within the process of doing security is this idea of third-party software handling. This loosely fits in with these other discussions, Robert, we're having about coding, Because a lot of these frameworks and libraries that we just talked about are technically third-party software. So one of the elements that I think everyone should consider when they're building a product or building something, you're going to use third-party software. The question is, how do you update your third-party software? Because a lot of people will, they'll go out and find a library because of the reasons that we just talked about. But they don't necessarily have a process to update that library. And we know as security professionals that— and developers and testers— that these libraries get updated all the time. There's security problems found in it, library gets an update, gets pushed out. If you don't have a process to go back around and update the third-party software that you're using, you may have vulnerabilities that exist under the hood that you're not even aware of.

**23:53 Robert Hurlbut:** That's right. And so along with that, which is interesting, is when you pull these third-party software into your own process, now you own it and you're responsible for it. And so you do need to keep track of what's going on.

**24:09 Chris Romeo:** Yeah, I had a colleague at Cisco that used to say, it may not be your code, but it is your problem, which I think just summarizes this third-party software issue. really well because it's the truth. You know, it's, it's not your code. You didn't write it. But when you import it and agree to use it in your product, it becomes part of what you're responsible for. And so you have to do something to deal with that.

**24:35 Robert Hurlbut:** Right. So along with that, you want to have some kind of idea about updates and management.

**24:42 Chris Romeo:** Yeah, you got to have a process. People don't like process. They don't— they want to, you know, buck against the process. But this is an example where you have to have a process to deal with this. And it doesn't have to be a 25-page document. It can be a 1-page explanation for within our product, Jill or Bob or whoever is responsible for ensuring that our third-party software is up to date and is not suffering from any known vulnerabilities that could could open some risk to our customers as they're using our solution.

**25:18 Robert Hurlbut:** Right.

**25:21 Chris Romeo:** One more stop on the— in the coding phase from a security activity perspective. And this is the idea of static analysis, which sounds like a really boring term. Static means, you know, not moving. Analysis probably wouldn't introduce myself at a party as a static analyzer, but what does that actually mean?

**25:45 Robert Hurlbut:** Well, essentially it's typically a tool that you're using to go through your code, and it's doing a lot of pattern matching. It's doing a lot of things that we already know about, security issues that we know about that we might find common in code. And so it's doing essentially a scan of your code and trying to find any patterns, matching any patterns, ways of using the code in an insecure way, and flagging those.

**26:16 Chris Romeo:** Yeah, and it's so important to use tools whenever possible in the world of application security to help make the engineers, the developers, the testers, make their job easier, possible. Take away manual things that they might have to do. Static analysis has kind of a bad rap a lot of times because it is just like antivirus used to be back in the '90s. It's really well known for false positives. And everybody on the development team just loves false positives, right?

**26:53 Robert Hurlbut:** Right, right. Not at all. No, because, you know, you see this and now you've got more work to try to figure out, well, wait a minute, this is something that doesn't match really. It's not our system. It says that, you know, that we might have a problem with our database. We're not even running a database. What are they talking about? So, you know, nothing is perfect. It doesn't know completely— no tool is going to know completely your process. No tool is going to completely know everything about your application. But on the other hand, it is going to get a lot of the low-hanging fruit They're going to find a lot of potentially a lot of things that you may have missed. And so I still think it's worth the time and effort to take a look at the results. And if you have a— there are some tools that actually are what I call really smart tools that if you indicate that this is something that really doesn't apply, it'll know the next time to either ignore it or if it finds something new, then it'll say, hey, I did find something new, but I'll ignore the ones that you say to ignore.

**27:58 Chris Romeo:** Yeah, I think the tuning process with static analysis is, unfortunately, it's a phase that a lot of people, they install it, they roll it out, they say, our developers need to use this now, and then they don't ever go back and spend a lot of time tuning it. So you need to invest the time and the resources in any tool that you're going to use to tune it, to make sure you provide the best possible output for the developers to really focus their time and the information that you're putting in front of them so you're not wasting their time. Because when I say false positive, what I mean is that these tools are notorious for saying, we found 217,000 problems in your code. And then when the developers start to go through and start to look at each one of those, a lot of times they're just not— there's not a problem to be found there. The static analyzer or static analysis tool is just doing a pattern match and it pattern matched on something that was a variable name or was a routine name that wasn't actually the problem. And so that's frustrating for them. So you have to ensure that you're using tools that are tunable and that are smart. When I think of static analysis tools, I think that they're— I think of them as being good at some things and terrible at others. So I think of a static analysis tool as being really good at the pattern matching side. So static analysis is good at finding SQL injection. Because SQL injection problems in code have a very defined pattern of what you can look for. Every time there's a database call, you're examining that code closely for a pattern that looks like you're concatenating some information together to make your database call.

**29:38 Robert Hurlbut:** Correct.

**29:39 Chris Romeo:** Those are easier to find. What static analysis is not going to find though is the logic flaws, right?

**29:46 Robert Hurlbut:** Right. Again, it doesn't know what your intent in terms of the application, the business flow, and all those kinds of things. It doesn't know those things. All it can see is just the code that's there, but not necessarily, you know, why, how did you get there, how was it called, that sort of thing.

**30:04 Chris Romeo:** Okay. Yeah, so another thing that's happening in the world of static analysis now that I've been studying lately is A lot of the tool vendors that make static analysis are now providing IDE plugins, or what is that, integrated development environment plugins. So this is, Robert, you're a developer, so you live in the, in an IDE, especially in a Windows world, you live in an IDE, integrated development environment, all day long. So how useful is it for you to have a plugin that does the static analysis for you right in your development environment?

**30:39 Robert Hurlbut:** Well, if as a developer, if I'm writing some code, especially if it's a team member that's still trying to understand security issues and trying to understand best practices, if they're typing something in and you have an analyzer that's running right there in real time to say, hey, it looks like you're trying to concatenate a string before you call a database, or make a database call, you might want to rewrite that. Something like that. If you could do something like that, I mean, it just pays for itself, because if you can catch those issues, inform a developer, and get them fixed before you have the code, you know, written, saved, run, and so forth, that's always a win.

**31:26 Chris Romeo:** Yeah. So the next set of activities or activity that we move towards here is what's referred to as vulnerability scanning. And this is sometimes these days you'll see this referred to as D-A-S-T, DAST, Dynamic Application Security Testing, as is the fancy way to describe what I used to call vulnerability scanning. I guess back in the day, maybe that's— I'm showing my age here. But the idea with vulnerability scanning is just like static analysis is a tool that looks at the code base and analyzes for any problems in the code base, the vulnerability scanning or DAST tool actually scans the finished product as it's deployed. So if you have a web application that you're pushing out into a production environment, you can use a vulnerability scanner to— and what it'll do is it'll attempt to connect, it'll do a port scan, through to see what TCP or UDP services are open on your server. And then it'll go through and look for, are there any system daemons that are listening there? You know, programs that are going to provide some type of service like a web server or a mail server. And once it identifies what services are available, then it'll try a whole bunch of different attacks to see if it can detect some type of a challenge. And And I think of vulnerability scanners, Robert, as 2 different categories. There's those vulnerability scanners that are good at network vulnerability scanning, and then there are those tools that are good at application vulnerability scanning. Which one of those categories have you had the most experience with?

**33:07 Robert Hurlbut:** Probably the application side. I mean, I've run some network scanners many times, but the ones that I, been running or looking at more and more are the application side.

**33:20 Chris Romeo:** Okay, and those are— so tell me, walk me through a little bit what's happening when you run one of those tools.

**33:27 Robert Hurlbut:** Well, essentially, it's in a way, it's a kind of pattern matching again. It may be trying, for example, I keep going back to SQL injection, but it may try to connect to a database by sending in the kinds of commands that would indicate that there is concatenation happening in the backend. So it's testing the application. It may be trying to, you know, verify are there certain types of vulnerabilities within the system by doing some, again, some pattern matching, but in this case it's actually testing with the tool to send in the kind of data that might result in the presence of a vulnerability.

**34:15 Chris Romeo:** Okay. And I've had experience with both. I probably spent more time, total time in my career, if I had to categorize my career by how much time I spent in vulnerability scanning tools, I probably spent more time on the network vulnerability scanning side as a pen tester and a vulnerability scanner back in the '90s and early 2000s. So when I think of, I think that difference, there's different tools. Some are good at scanning networks, others are good at scanning applications, and it just comes down to collecting the right tools that you need to do the job and to successfully provide the best coverage. And that's why I recommend that a lot of my people that I work with and advise is you shouldn't use just one tool from a vulnerability scanning perspective. It's important to use multiple tools because some tools are going to be good at finding one type of problem, and another tool might be better at finding a different type of problem. So use multiple tools together and combine that output to truly get a picture for how vulnerable is the instance that you're assessing right now.

**35:23 Robert Hurlbut:** Right, because like you said, not every tool is going to have all the answers. And so sometimes it's good to have at least a couple of tools and compare the differences.

**35:38 Chris Romeo:** another piece that kind of sits on top of the vulnerability scanning. I think of this as being very, very supportive and working in tandem with vulnerability scanning, and that's this idea of penetration testing. And so the idea of penetration testing is it's normally a manual process where you pit a single or multiple human beings against an IT system, and it's a battle royale. You know, it's a battle to the death to see who can— and the system doesn't really do anything back to the people, but the people are trying to see, is there any type of vulnerability that I can find and then exploit to get access to this system? So how does— Robert, when you think of penetration testing, how do you think of, or how do you think about the connection between vulnerability scanning and pen testing?

**36:35 Robert Hurlbut:** Well, let's say, for example, I've run some tools to do some scanning, vulnerability scanning, and I might find a few interesting things. But as I'm starting to work with the system and understand it a little bit better, I'm thinking of pen testing as taking that information and doing a little further investigation. Going a little further into the system and perhaps, you know, looking at the workflow and try to understand, okay, well, what happens if I do something not expected here? How does it react? And so a good pen tester is going to take the data that they're gathering from these automated tools and do some more focused attention and work to try to find out, are there other problems potentially in this application that maybe not necessarily the tool is finding, you know, may not find all of them. And we're going to dig a little deeper and run some more analysis.

**37:35 Chris Romeo:** Yeah. And there's, yeah. So, and there's, there's a lot more details that go behind this, this concept of penetration testing, but, but why would somebody care then about, why doesn't somebody just do vulnerability scanning? Why do you have to do pen testing on top of it?

**37:53 Robert Hurlbut:** Well, because again, vulnerability scanning is only going to run what it knows.

**37:58 Chris Romeo:** Okay.

**37:59 Robert Hurlbut:** It's going to only run the patterns that it's aware of. But again, it's not going to know everything about your workflow, your business flow within your system. And so a good pen tester can dig a little deeper and try to find out if there are any other problems in the workflow itself, in the logic and so forth.

**38:20 Chris Romeo:** Yeah, that makes sense to me that you would want to have some human being that's going to do a deeper analysis. And not to say that pen testers don't use tools because they use tools to enable their process and their job every day. They just have a lot more knowledge in their brain to be able to apply. So if the tools don't provide anything, that doesn't mean they're dumb. they'll just go and start thinking up some new creative way to attempt to bypass the security of a product.

**38:52 Robert Hurlbut:** Right, right.

**38:56 Chris Romeo:** So that takes us into our final security activity/element that we wanted to discuss, and that's this idea of response. So when I think of response, I think, you know, coming from a product company-focused background, spending a lot of time there, I think of response from a product security incident response team or PSIRT type of a perspective. And incident response in general is the expertise and the job roles that focus on protecting and cleaning up after particular attacks that happen to an organization. When I think of the product security incident response team, this is a subset of that incident response team that's focused inwardly on the products that the company creates. And so I see a big connection between application security and this idea of PSIRT, because in the application security process, you're focused on all the activities that are going to make the product as secure as possible. The PCERT is what closes the loop there after you release the product and it's in the customer's hands. The PCERT process and the PCERT, the people that are in that role, in those, in that role, that is the interface for the customer when they have a security problem or when an external researcher finds a security bug in your product. PCERT is the avenue that they have to make the contact and to say, Hey, I found this security problem. And the PCIRT process is what allows you to go through and ensure that that problem is fixed, that it's patched, and that the proper notification occurs out to all of your customer base.

**40:45 Robert Hurlbut:** So it really is a release support team, essentially. It's just making sure, like you said, to close the loop and dealing with any potential issues that may be found after the fact of after it's released and so forth, and how do you handle those appropriately?

**41:01 Chris Romeo:** Yeah. Yeah. So the— and why would you care about the PCERT? I think because the PCERT is your interface to the outside world to talk about security with your products. And the outside world, your customer base expects security built into the products that they buy from you, and they expect to have somebody to talk to that's knowledgeable when there is a vulnerability in your product that's disclosed on the internet, or when they find something in their testing that they need to do a deeper dive. It's good to have that frontline set of people that can triage and determine if there really is a problem that requires some deeper action by an engineering team. So, the key takeaways then, Robert, that I have from our conversation today is that First of all, security requirements are very important to the overall product that's being built because these are the lessons learned. These are the best practices that need to be applied from a security perspective, and we want to ensure that those things get applied across the board in all of our products. Threat modeling is about finding or identifying what are the potential ways somebody could hack into our product or our offering, and how can we mitigate those things before we ever start writing code? The idea of coding standards— this is providing some set of guidance in a document that says, here are some good things to do as to how you're going to code, here are some things to avoid. Secure libraries— these are functions that we can include, that we can borrow from somebody else's code they've developed to make our job easier as a developer by using secure alternatives and frameworks or secure libraries. Third-party software is so important to ensure that you think about that software as your code, your problem, things that you have to deal with. We talked about static analysis, vulnerability scanning, how those tools come together and are, are important to use in improving your application security. And then we are— the last 2 we talked about was pen testing deeper from a testing process and then the importance of the response. So I think all these activities, Robert, are really important for doing application security. And I think that it's something that not— you won't necessarily do all these activities all the time, but it's important to understand what they are and choose the ones that are going to provide the best return on investment for Definitely.

**43:37 Robert Hurlbut:** I mean, it's, it's just a part of how you build secure software.

**43:41 Chris Romeo:** No doubt. Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Boring and TJ, and the outro is Southern Delight by Stefan Kartenberg.

**43:59 Robert Hurlbut:** You can find us on Twitter at AppSec Podcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/chris-and-robert-the-activities-of-the-secure-development-lifecycle/