---
title: "Jon Mccoy and Jonathan Marcil -- Agile #AppSec"
url: https://appsecpodcast.com/jon-mccoy-and-jonathan-marcil-agile-appsec/
date: 2017-08-29
duration_seconds: 2673
guests: ["Jon Mccoy", "Jonathan Marcil"]
topics: ["OWASP Top 10", "API Security"]
audio: https://www.buzzsprout.com/1730684/episodes/8122710-jon-mccoy-and-jonathan-marcil-agile-appsec.mp3
transcript: true
---

# Jon Mccoy and Jonathan Marcil -- Agile #AppSec

*August 29, 2017 · 45 min*

with [Jon Mccoy](https://appsecpodcast.com/guests/jon-mccoy/), [Jonathan Marcil](https://appsecpodcast.com/guests/jonathan-marcil/)

on [OWASP Top 10](https://appsecpodcast.com/topics/owasp-top-10/), [API Security](https://appsecpodcast.com/topics/api-security/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122710-jon-mccoy-and-jonathan-marcil-agile-appsec.mp3)

## Show notes

Agile delivery promises fast feedback, but where does application security fit when teams are already moving continuously? Jon McCoy and Jonathan Marcil join Chris and Robert to separate Agile principles from inconsistent enterprise interpretations and identify practical starting points. They discuss dedicated AppSec leadership, security-minded developers, continuous integration, static analysis, shared knowledge, and reusable components. The guests challenge the idea of a late security sprint and examine the real cost of building defenses early. They also explain how responsibility can be distributed without asking every developer to become a cryptography specialist. The episode closes with learning recommendations, community participation, and the principle that a mature AppSec program should help teams avoid repeating the same security mistakes.

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 Jon McCoy and Jonathan Marcil:  
→ [Jon McCoy on X](https://x.com/thejonmccoy)  
→ [Jonathan Marcil on X](https://x.com/jonathanmarcil)

Mentioned in this episode:  
→ [Agile Manifesto](https://agilemanifesto.org/)  
→ [OWASP Top 10](https://owasp.org/www-project-top-ten/)  
→ [OWASP Montreal](https://nest.owasp.org/chapters/montreal)

Chapters:  
00:00 Agile application security  
01:54 Security origin stories  
05:41 Development experience and security work  
08:52 The advantages of fast feedback  
10:11 What organizations mean by Agile  
13:24 Where security fits  
16:44 Starting an Agile AppSec program  
20:02 Continuous integration and static analysis  
23:02 Building a security knowledge base  
27:54 Why a late security sprint fails  
28:05 The real cost of building security early  
32:44 Reusable controls and specialized responsibility  
35:33 Additional first-year priorities  
37:34 Learning through local communities  
43:18 Avoiding the same mistakes over time

## Transcript

*7,273 words · assemblyai*

**0:05 Chris Romeo:** The Application Security Podcast. Here we go. Hello again, everybody. We're back with another episode of the Application Security Podcast. On this week's episode, Robert and Chris speak with John McCoy and Jonathan Marcil about using agile AppSec in the secure development lifecycle.

**0:45** They dive deeper into what is agile, how it can be used, the practical applications with security champions, and much more.

**0:52 Chris Romeo:** As always, thanks for listening and enjoy. Hey folks, welcome to this episode of the Application Security Podcast. Our topic for this time is Agile AppSec in the SDL. And SDL, if you remember, stands for Secure Development Lifecycle. And so we're really going to unpack this today with a couple of friends of the show. And so, Robert, first of all, Robert's here. Everybody knows Robert. He's very famous.

**1:23** Hello.

**1:25 Chris Romeo:** And then we're also joined by John McCoy. This is John's second time on the AppSec Podcast. So, John, welcome back. Thank you for being willing to share again with our audience here.

**1:35** Oh yeah, thanks for having me back.

**1:37 Chris Romeo:** And we're joined by one new person who has not been on the Application Security Podcast before, but he is far from a new person in the world of security. We're joined by Jonathan Marcil. And first of all, Jonathan, welcome to the podcast here.

**1:53** Hello.

**1:54 Chris Romeo:** And we want to always start our interviews in the way that our listeners have come to understand. And we always want to know from new folks on the show, what is your superhero origin story from a security perspective? So, how did you get into security? What's kind of your backstory about where your superpowers come from?

**2:16** I was wondering, do you want the dark side or the light side? Because it all started with the dark side.

**2:22 Chris Romeo:** You know what? Comic books that go from dark side to light side are always like the best kind of story. So we'll take the— we'll take both perspectives if you'll give it to us.

**2:30** Okay. I would say that the dark side actually came way before the light side because I was mostly into programming. I was working as a software engineer, and then at one point I just decided maybe to get a turn in my actual career, let's say about maybe 2008, 2009, just to do more cybersecurity as my main focus, AppSec that is. And so before that, a really long time ago, I don't even remember the date, but in the '90s, I do remember that the first time that I really, as it I've had one in my face was I was on RRC using my Windows machine because this is all I knew back then. I just got the blue screen of death and I was like, okay, my machine is behaving weirdly. I came back, reopened RRC again, and then I basically figured out that I was getting denial of service from someone. They were using probably like a super lame-ass tool, I did my research, I found the tool, I found a way to protect, and then I was back on IRC with NukeNiber, I think, as a pseudo firewall you had to run back in the days. Then I actually caught the guy and I was like, hey, look, I know what you're trying to do. It all started with me with defending actually, because as soon as I learned how to do it, I was like, okay, how do I defend myself? So, and NukeNiber, I guess, was my solution, and it worked fine for me, at least for that part.

**4:10** Hmm.

**4:11** And so, and then over time, I was more getting into security as a hobby, like, like having the hacking and all that stuff around it. And, but then really for work back in the day, it wasn't really a thing. Because I don't know, like, I'm not that old, but still the internet was rather new when I actually finished high school. So it wasn't a thing that was very common. So hacking was like really, really fringe. So I didn't hear about like any job into security really. All the jobs were like, yeah, in software engineering and all this stuff like that. So over time, I ended up doing more and more AppSec, and when I actually started to get involved in it, I was the OWASP Montreal chapter leader for a while, and I also did a lot of stuff regarding security in Montreal, mainly some conferences and also some CTFs that I was making the challenges. with the team. So cool. But now I have moved from Montreal to beautiful Irvine, California, so it's kind of a change for me, but I'm still like, uh, working full-time in AppSec. Maybe I'm a little bit less involved because I used to do a lot.

**5:41 Chris Romeo:** Yeah, so when, so when you first got started then, did you come through the software development route? Were you actually a developer for a time?

**5:49** Yes. Yes.

**5:51 Chris Romeo:** Okay.

**5:51** Well, I learned already to do programming when I was like super young. So hacking was kind of a side thing. And I did really call it hacking, not AppSec, not security. It was really for me like, how do you exploit software? How do you protect against that thing? And, uh, but then my actual courses was aligned with school, with what I've learned at school. But meanwhile, while I was learning software engineering at school, I was learning hacking at home. And so when I actually came up to the point that, oh, we have a security course, I was almost exempted from the security course because I already know all the bits and bytes of it.

**6:33 Chris Romeo:** They probably wanted you to teach it. Hey, you know, why don't you teach it and give us— enlighten us here?

**6:37** Yeah, actually right after the course I ended up making some laboratories the labs. And so I made like, I think half of them, I actually participated at making them because the course was like rather new.

**6:53 Chris Romeo:** So that's, that's, it's always fun to be able to give back even when you're early on in your career to look for ways to give back to the community. Okay. So first, thanks for sharing with our listeners kind of where you come from. I think it helps to put people into perspective kind of based on some of their kind of— as their experience comes out, it helps to kind of know where they come from. So, we're going to talk about agile, and we're going to talk about how application security impacts the whole agile thing. But in case some of our listeners out there maybe aren't heavily involved in the product development cycles or aren't software developers, they might not have a perspective on even what is this idea of agile. So, I thought we'd start by just saying, Let's just start by defining what is this overall thing called Agile. And we've got 2 Johns on the line here, so I'm going to have to say like John McCoy. I'm going to have to be more specific. But John McCoy, why don't you kick us off here? I mean, when you hear Agile, how do you explain that to people that have never heard of it before?

**8:01** Sure.

**8:04** I guess first off, it's a programming paradigm. We've all heard of OOP and Waterfall. kind of your paradigm for building your software. And it's under this idea that you want to build fast, fail fast, progress fast, and design small doable chunks, knock them out, make progress, feedback the, the good parts, feedback the bad parts, and iterate in a, in a forward momentum. And it kind of keeps us from building monolithic kind of failures after 2 years of design and implementation. We get a failure. And in Agile, it's a week, 2 weeks, 3 weeks to a feedback of failure or feedback of a milestone of success. So it's a paradigm.

**8:52 Chris Romeo:** Yeah. So what are the real advantages though? I mean, you talked about how, at least from a time perspective against Waterfall, Agile is going to allow you to get feedback a lot faster. You're going to have a build of software or whatever you're building, you're going to have an instance of it quicker and without as much kind of time, I guess, in between. But what are some of the other kind of advantages? Why else would I want to do this? Is it cheaper?

**9:21** That's always debatable. It's a six and a half dozen on cheaper or better, but it's definitely— you can plan out your next chunks of features or progress and then kind of here's our next steps. So I definitely think like to get an MVP, a minimally viable product, or getting a feature out the door to get to testing, that you can certainly get to that quickly and be able to know if your features are working. Like it's one thing to build something, it's another thing to test it and deploy it. Yeah. And then that brings us to security that I would say it started out in waterfall and kind of went through the same iterative changes. Yeah.

**10:11 Chris Romeo:** Okay. So, Jonathan Marcil, question for you is, I have this sneaking suspicion that when people say agile, they don't always necessarily mean exactly the same thing. And I'm curious on your perspective there, kind of what you've seen across maybe different organizations or things. Is there such thing as a standard Agile? And when someone says, hey, I'm doing Agile, does that really mean they're doing the same exact thing as someone else who's doing Agile?

**10:42** Yeah, because most of the places, you know, when they say, yeah, we're doing Agile, it's kind of, it's because they are doing Scrum meetings in the morning and they all stand up. And then that's how you know that they do Agile. And that's probably the only thing they are doing for it. So it's really like John said, it's really like a mentality that you have around making software that is not the same as waiting a long time for feedback. That said, I could say that even if you're not organized, you're not doing the things as agile, you actually can be agile. And so that's also a pun on the word that I'm seeing being used a lot. Like all the project managers and all the developers are like, yeah, we're agile because we're fast and blah, blah, blah. So they make it as the word instead of just the mentality. So most of the time that I'm seeing it live, let's say, in the real world, it's mostly we mimic what is done in Agile. So we have a sprint, we have the standups in the morning. One of the core rules that I thought that was in the first version of Agile, I guess because it was a manifesto back in the days, if I remember correctly, was that no release date. It's ready when it will be ready.

**12:11** Mm-hmm.

**12:11** That kind of stuff doesn't really extend for long in larger companies. Maybe you have other experiences than me, I don't know, with like government contracting because they don't care if it takes 20 years to do something. But I mean, in most of the places that I went, they were like, yeah, we're agile, but we still need a date because that's how our business works.

**12:32 Chris Romeo:** Yeah.

**12:33** So in a sense, it's not really aligned what is supposed to be agile. And so in a sense, when you are doing that, You are adding like a few constraints that makes agile, in my sense, more like iterative development. And so it's kind of, it's not like waterfall, it's more like a spiral model. If you know about those things, like there's a spiral model that you just go in a loop and then there's the iterative model when you iterate really throughout the steps. that you can have in US DLC, software development lifecycle. So when you have that lifecycle, you go over and over. So I think that many companies, they mimic agile, but they are more doing iterative development just because of the fact that they have a release date.

**13:24 Chris Romeo:** Yeah. Okay. So what I've heard so far is kind of from a description of agile, build fast, fail fast, release fast. There's one thing that appears to be missing from this equation though, and I've always been fascinated as to how security was basically not even considered from the very beginning of the Agile process. So is security built in or baked into the standard kind of approach? You talked about this Agile Manifesto. Did they even talk about security back then, or is this something that we're kind of adding on based on our experience? John McCoy, why don't you kick it, or whoever wants to kick us off.

**14:08** Yeah, Marcil, you kick it.

**14:10** Yeah, well, at first I think that Agile and all that thing doesn't really come from computer science first. I think it comes from like project management and finance or maybe something like that. And so I don't know if it was actually part of their mindset. What I know is that you can either do it with 2 things that you pick from. Is it a cheap thing, a fast thing, or does it cost much? Then unfortunately with security, it's always a thing that costs more on time and money. Because of that, if you want to do the right thing and if you want to do it fast, you will have to make some compromise and unfortunately security can be one of them. So in order to build it in, I really do think that you need to be ready in the way that you are making software, having some continuous integration. And then in this case, you could say, oh yeah, I'm easily doing security during Agile. Of course, if you have a security issue that comes up and then you treat it as part of the Agile process, then yes. But I mean, me, I don't see it really as a plus really for security because it's always, like you said, about speed. And speed always goes against really security because, I don't know, we're slow or it's slow really to fix the things and do the right things or at least do the things right.

**15:42 Chris Romeo:** So are the security people then, are security people fighting against the kind of owners of the agile development process inside of a big company? Is there pushback from those that are the keepers of the development process when it comes to— do they see the value of security in most organizations or not?

**16:02** I would say that I think they are starting to, that security is becoming a business concern. It's being a value proposition to your customers, and I've definitely seen security over the last few years moved from something that was adversarial to development to now being baked in. And hopefully, security done right, you get invited to the meetings and they see you as a resource. And developers are really starting to, I think, prize security. As long as it's not a roadblocker to their project and you're bringing value to the project, then they respect you and appreciate it.

**16:42** Okay.

**16:44 Chris Romeo:** Let's transition now and start to think about and talk about So we've kind of made a case here for why somebody should care about security that's doing Agile, and I think we've done that justice. Now let's say we transition into somebody who's on the practitioner side and they're thinking, hey, how am I actually going to do this? So if somebody is in an organization and they're doing Agile and they're doing really nothing for security at this point, where do they even begin in this process? What are the first couple of things that they should add into their kind of agile approach where they're going to get the most bang for the buck?

**17:22** A dedicated security professional.

**17:27 Chris Romeo:** Okay. So that's a good first place to start. So you mean like somebody who's an AppSec, who has years of AppSec experience that can kind of come in as the program lead and kind of guide the security program?

**17:39** Yeah. Or even have someone on the team that as their daily job puts on the black hat and thinks about breaking the system or ruining the service or compromising users, that, that is kind of a mindset switch between like when you're building something and you see the strength and beauty of it versus the weaknesses and fallibility of it.

**18:03** That—

**18:04** yeah.

**18:05** Is that what you call an application security champion? I see that a lot. Talk about that a lot more.

**18:12** Oh, definitely. Yeah, one of— I mean, as an AppSec engineer, when I come into the team, finding that person that wants to take on that mantle of being an advocate for the security process or coming at the inside-the-team security concerns. And Marcil, do you have anything on the security champion?

**18:35** Yeah, well, normally, like, When you really think about what is like a champion, there's actually 2 ways that you can spin it. It's either, like you said, like a security engineer that does the job. But in many companies, it's also a dedicated— not a dedicated, but one person that has been assigned with the gruesome task of doing security because they cannot afford an AppSec engineer or it's a bit too much.

**19:06** Yeah.

**19:07** at the state that they are. And so they basically take someone who knows a bit about Lexis security and they make them their champion ready for that project. And then in every meeting, he or she is like in charge of mainly being the stakeholder of all the security items and then will also chip in like a security engineer will do. So I guess that if you are on a smaller scale, That's what you will do. And then when you are on a bigger scale and you have multiple agile projects, then you could have a dedicated engineer that solely does security. I used to do it like in smaller companies, but I was only working like a few hours a week. Even if they had many projects using agile, it wasn't a thing that if I were to be there full-time, I will slow them too much. You know what I mean?

**20:01 Chris Romeo:** Yeah.

**20:02** Yeah.

**20:02 Chris Romeo:** Yeah. So now, so if we kind of stop for a second and kind of think where we are. So we've just talked about how we bring in either a dedicated AppSec person or we allocate somebody from the existing team who's got some interest in AppSec and we say, hey, they're going to be in charge of this. Or maybe we even have just somebody in a small company who is a security champion type person who only has a fraction of their time dedicated to security. Where's the first place that you guys would recommend based on your expertise that this person should go as far as what should they do first now? So now we've got the person there, somebody's got the role, they've got the badge or title for AppSec. Jonathan, Marcil, you kick it off for us here. What's the first thing? Where's the most bang for the buck as far as security activities that this person can add into the process?

**20:53** Like I said previously, I think that if you have anything continuous integration-wise, that would be a great place to start. There's a few reasons for that. I have one controversial one that I think that is good. But the main reasons are that, well, you are integrating, let's say, a scanning tool that will do the static code analysis over your codebase. You are bringing some knowledge from security inside the company. So if you are a champion and then you don't know that much about release security, maybe a tool will help you with more things, right?

**21:35** Mm-hmm.

**21:35** But the problem with that is that it will generate noise. So it's always— there's always like a trade-off really to do. And so anything that you can do and automate at first, I guess that will be the thing that I will start with, not because it has the best actual payout when you start doing it, because of course it will take a long time because most of the things will be false positive. It's just that over time, it will do it over and over and over. And the day that it will find something when there's no champion, no security engineer, just like the tool running by itself, then it will have payoff at this point. And my last thing about that is also that you will get the checkmark of, is it a static code analysis tool installed or not?

**22:22** Okay.

**22:24** And this, in my sense, is a good way of engaging more fun and interesting activities and maybe activities that pay out a bit more if they include people in it. And so if you check that mark first and you're done with the static code scanning, you will be able to concentrate on other things because it can be a thing that will just haunt you if you don't have it. And then other people will come and they will say, Well, you don't have the static code scanning. It's like, this is AppSec. This is all you can do in AppSec. So I do guess that John has a thing to say on that because I see him.

**23:02** Yeah, yeah. I would, uh, to kind of come off of the tool thing for like getting that knowledge base to kind of foothold off of, um, so there's certainly OWASP and OWASP Top 10 or, uh, OWASP vulnerabilities focused on your technology stack. An easy place to start is you're doing JSON. And so just go and type in JSON parser, JSON securing, JSON vulnerabilities, and you'll find that there's, there's attack vectors. And typically with clients, I'll start from just the simple conversation. What are your crown jewels? Is it a database? Is it user data? Is it uptime? Is it a service? Is it intellectual property? And to kind of just get in scope, why are we doing security? And then let's, let's look at the first line of defense. And just like you have architectures of security, you have architectures of software, the like n-tiered architecture or that kind of thing, you have—

**24:11** Yeah.

**24:12** layered defense and layered architecture of security and kind of build it around what you care about and find your weak defensible points and kind of go at it from a plan of security controls.

**24:24 Chris Romeo:** Okay. So, you're thinking from kind of like the knowledge and learning perspective is where you would kind of go next. So, after you get the static analysis tools running, it comes down to getting some kind of developer knowledge, then using things like OWASP Top 10. I can say I think it's— I go into a lot of different places, a lot of different companies, and talk to different development teams and things. I guess when I left the big company that I used to work at for 10 years, I guess I had this false understanding that web developers just knew what the OWASP Top 10 was.

**25:01** Mm-hmm.

**25:02 Chris Romeo:** I thought that had reached the point where it was just an industry standard and it's embedded in all the tools. How could somebody not even understand what it is? But now I go and I'm talking to different companies and I'm realizing that that standard, that knowledge has not been imparted across many of the organizations that are out there. And so, that's just something that I think that's a call to all of us in AppSec is to how do we continue to get the word out about things like AppSec and OWASP Top 10?

**25:29** As a contractor, I think it's great to be able to have that knowledge be highly valuable and sought after. So, I mean, it's nice to be highly valued in the market.

**25:44 Chris Romeo:** That is definitely true. This is— we've talked about this before on this show, but we are all in an industry that is— it's unlikely that we're going to run out of work to do before we all want to retire. So, we're probably going to stay pretty busy along the way. So, okay. So, we talked about bringing in— identifying a resource to focus on AppSec. static analysis and automation. We transitioned into knowledge and learning, like let's provide some basic facts for everybody, all the developers across the team. Okay, so we're starting to get something— these pieces are starting to kind of fit together into this agile security world. Where do we go next? This seems like we've made progress, but I think we've got further to go. What else could we do?

**26:28** Well, I have one question about— I've heard in different teams they'll either think about security at each sprint or to think about having a separate security sprint. Any thoughts on either one of those approaches?

**26:43** I have a soapbox real quick.

**26:47 Chris Romeo:** Hold on, let's drag the soapbox over here. Okay, we'll set him up. All right, John is now officially standing on his soapbox.

**26:54** Anytime you're developing a product, whether it's architecture, design, or security, the sooner you can bake it in and plan it in, the better. And if you have just thought about security when you're releasing, that is going to be a really, really bad time. If you thought about it during planning, architecture, even product specs, it gets easier. And I advocate or assert that it's almost free to bake in security early, that instead of having to do a refactor of your database or your data layer or your inputs, you got it right the first time. And So my soapbox, I basically say that if you can build a secure program, it won't be more lines of code, it won't necessarily be harder, it's just incredibly hard to get right. And it might be 4 lines of code more, it might be hundreds of lines of code less to do it securely. So real quick.

**27:54** So from what I take from that is, and I feel the same, is that if you see in your plan that you have a security sprint towards the end of the project, you're doing it wrong.

**28:05 Chris Romeo:** Yeah, I'm going to take issue though with one thing that you said there because— and not a serious issue, but you said it's virtually free to bake in security. And you know where I'm going here, right? So, you know, I deal with a lot of product teams inside of a lot of companies, and if I make that statement, they'll be like, Oh, so you mean we don't— so you're saying we don't have to do anything if it's free? That means that— because anything we do is going to cost money. So, I would say that I know what you're trying to say, and you're trying to say it's definitely— I'll definitely agree it's cheaper in the long run to build security in, but I can't say that it's free to bake security in.

**28:45** I know how to spin that though, because you say it's free for the project, but then what you do is that you build up all the security things you need outside the project, And then when you engage with a project that is running on Agile, then you come prepared with everything in hand. Because most of the times that I actually did that, I wasn't prepared because I just get hired to do that gig of, I don't know, installing that tool during their development process. And so you arrive at the same time that they are doing the Agile sprint. So if you can find a way to have it like outside the sprint of development, and then you can work in your corner. Then for the project envelope, it is free. It's not free for the company, of course, because it's an investment that they are doing, but really for the project, if you find a way to do it like that. Unfortunately, most of the places that I'm seeing, all the budget goes directly just in project. Okay. You know, it's kind of rare in my experience at least really to see places that they are, yeah, this is investment. It's not money that we put in a project, you know, because the project manager, they care about like the envelope and their actual shipping date and what they are shipping, right? And so if you come and you say, oh, I will install you that tool, I will do this and that, and it costs a lot. then they will be like, I don't know if I should pay for that. But if you are already prepared, you already have a tool that is mostly spun up, then you spin it and it's good. And so it's just that you have to be careful about is it time you put doing AppSec for the sake of finding issues or really for the sake of resolving issues.

**30:33** It is true, it is a sleight of hand, like, um, the data access layer security or the auth security, that building it before the project starts and and having the security in place before they get there. But it is true, someone pays for it.

**30:47 Chris Romeo:** And so, I'm thinking more even from the resource perspective. When I hear— so, if I put on my product manager hat for a second and I hear that it's free to bake in security, then that makes me think like I don't have to invest anything from my— and I'm thinking more from a resource perspective. So, I get where you guys are coming from, free to bake in security, meaning Hey, you're gonna provide me with some components that are pre-made. You're gonna give me an authentication framework that I can just plug in and use it. I don't have to do anything for authentication. But I'm thinking more from the resource side where that individual agile team is still gonna have to assign some resources to integrate that authentication when, you know, maybe they were saying, hey, we weren't gonna do such a large approach to authentication. So that's where I'm saying it's—

**31:37** Mm-hmm.

**31:38 Chris Romeo:** It's more on the resources, which translate back to dollars, meaning, engineer hours that are writing code to build security in.

**31:46** I would come back with when your team gets to that authentication, when they get to the authentication module, that a really good security project team should have a turnkey solution that you can put in there and the developers don't really have to understand it or necessarily think about it. Of course, they should understand it, but they don't have to, and that security can give them almost a turnkey solution. When they come to the data access layer or the user input, that hopefully good security is transparent to the developer.

**32:22** Yeah.

**32:25 Chris Romeo:** That's starting to build more of a dangerous kind of an architecture. That's a scary architecture that you just described though to me because now I've got people that don't really know what's happening I've got developers that could be responsible for security that have no idea what's actually happening. It's a black box kind of approach to them, and that's kind of scary.

**32:44** I would say segmentation of responsibilities, that you should have 1 or 2 developers that are really concerned with authentication, and they work with it, and they know it. And when another team needs to do authentication, that they can either pull in the resources or have a have a deployable? I guess, like, would you want your developers writing crypto or authentication or parsing? Like, you kind of want to make it so they can't mess it up.

**33:12 Chris Romeo:** Well, you want them, but you want them using crypto, right? So, so they're still going to— I'm not going to go in as a security team and write all their crypto, all their times that they use crypto. I'm going to provide them with a solid library that I trust that's been vetted in the industry. and teach them how to plug into that and use it, and then do code reviews and things to look over the top of what they did and say, you know, did they in fact implement this? Are they using crypto correctly? Are they using the right algorithms, the right key sizes, and all of those types of things? But so I would still expect my developers to have the ability to integrate with a library. I would never want them to write a library because we all know this. That's like the worst possible thing that could happen if somebody writes their own crypto library.

**33:58** And yeah, and instead of them Googling for a few hours and coming up with a solution, there's a package that they spin up. And yeah, it's— yeah. Yeah.

**34:10 Chris Romeo:** So we all know that products are built from Stack Overflow these days.

**34:14** So—

**34:15** Right.

**34:16 Chris Romeo:** Everybody—

**34:16** I guess that the good news in that case is that you know how much effort it will take because the way that I see it right now, as we just said, was like it's either you implement this type of feature using this library, so you have to integrate, or you fix that bug because we found that thing. Those are the things that they know how to wait and they know how to plan for it as well. If you ask them really to say, I'm going to do a security review during your sprint and we need some people to work on it, this is a thing that actually can have zero outcome. You can find nothing. It's rare, but you can find nothing worth of value. And so it's a thing that it might be a little bit harder really to sell than when you are sure about what is already installed. And then you just mostly tell the team, yes, you either need to integrate with this, use that, or to fix those bugs. That way, at least they know, you know, where to go because really security can be like super vague. And I think that seeing the value is what every good project manager actually cares about.

**35:33 Chris Romeo:** Yeah, yeah, definitely. Okay. So is there anything else? So we talked about a dedicated person, static analysis, and then knowledge and learning. Is there anything else that this person should try to— and that's a lot to accomplish in the first year. It sounds like a short list, but that could be multiple. It could be more than a year's worth of effort. But let's say this is a very innovative and passionate and someone who's got a lot of time. Is there anything else that they should approach in the first year as far as trying to coordinate their AppSec and their agile kind of worlds together? What else should they be doing?

**36:11** I don't know about the first year, but where does DevOps come in? I've heard people say DevOps is applied Agile. Does that figure anywhere in the first or second year? Any thoughts on that?

**36:23** My thought is that you must start Agile when your DevOps is ready. It's that simple. You, you want to be really Agile, have your DevOps stack ready. Then in this case, when the DevOps stack is ready, it's just a matter of integrating new security features into it, like a static code scanner or anything like that. So you have to have it ready because if you build it while you're doing Agile, it will be way too slow and it's not even in the same scope as what the project actually delivers.

**36:54** I would give some If a company doesn't have DevOps, I would throw out that security can kind of be thought of as stability, and that it can be a value proposition for the product. And for that first year for the person, I would throw in a community, that security is really something you learn from other people, not something you Google. So conferences and training and reaching out and going to OWASP meetings or going to hacker hackspaces and plugging in.

**37:34 Chris Romeo:** Okay, and that's actually a good transition. And kind of the last thing I wanted to talk about was, John, exactly what you just said. If we were going to recommend— and so I'll even adjust the question a little bit— if we were going to recommend things, what are some specific things based on that last statement you just made about conferences and community? Where would you recommend that our fledgling kind of AppSec person in this new company, where should they go to get plugged in? What are the resources that you would say, hey, here's the things you need to go look at specifically, and also things that they can share with the rest of their team? What are your thoughts on that?

**38:11** I would say finding the conferences that speak to your tech stack. Like, general security conferences are great, but if you are a thick client and people are reverse engineering and attacking you, then going to Recon is great. If, if you're cloud security focused, then certainly OWASP. And OWASP does a lot of thick client and cross-the-board stuff, AppSecUSA. But, but finding a tech area that focuses on your problem set, I don't know if there's a mobile security conference yet. And, uh, so I would say local OWASP chapters, look up hackerspaces, they're everywhere.

**38:58 Chris Romeo:** And, um, what is that? What is a hackerspace? Can you kind of give us a little bit of perspective on that?

**39:02** Sure. It's, it's kind of like a clubhouse. If like you and your friends today got together and threw in a few thousand dollars each and made a clubhouse. So it's everything from 3D printers to laser cutters to weather balloons to a common space to come together and tinker and maker with other people. They do security training classes or privacy classes. Every time I do a conference, I try to go to a local hackerspace and give a talk or give a hands-on training. Yeah, it's a clubhouse.

**39:44** Okay, cool.

**39:44 Chris Romeo:** So that sounds like some great advice here as far as finding a conference that's specific to what you're actually working on. And you mentioned a couple of generic ones like AppSec USA, they're going to provide value for folks across the board. And then I'm also— I think the local OWASP chapter is a great— I think we would all agree that's a great place to kind of send people. And the hackerspace sounds like— I've never been to a hackerspace. Now it sounds like I need to actually go visit one because that sounds like a pretty pretty cool place to hang out.

**40:13** Oh, cool.

**40:15** And maybe one interesting tangent would be common pitfalls that like I could go to 10 clients and see them make the same mistake at each place for the same reasons. And that would be an interesting— like, you'll get approached in the first year when you go to a conference with a piece of hardware that will solve your problems. You just put this in front of your your server and it will stop all the attacks. And it's only a quarter million dollars. Think of the savings. And, and so many companies bring in these appliances. And you, you want to talk about that, Jonathan? Or you interested in diving in?

**40:54** I'm good. And I don't want to rage too much. But what I might add to that, you know, I'm a super big community guy. It's like, all my investment in life is about adding some value in anything community-wise. I did the OWASP YouTube channel, is a good example. If you don't have the money ready to go to a major conference or you don't have the time, well, we have all the recordings, well, most of them at least, onto the YouTube channel. So it's on youtube.com/OWASPglobal, and we have everything AppSecUSA is there, everything AppSecCali. So that's also a good way really to go to conferences but without going. So that could be a really good way. But the thing that I had in mind was more that, you know, what will happen at some point if you don't know about really security? You will hire someone or a firm. Normally you will try to do some pen testing and then they will give you a report of some sort. So one thing that you can do is that you can start from that, but you can appropriate yourself the knowledge that have been sent to you. Because most of the times it will be all about, yes, you need to fix those bugs, especially if you go just with one pen test, right? And then, but if you take that, you have your security champion, and then you say, okay, you take that report and I want you to analyze how they did it and how we can do better in the future not to reproduce that. And then you start from there. And so, and if you're lucky, you will find like an AppSec engineer that already know all the steps of baking it inside your SDLC, your CI, or anything like that. But if you don't, because those are actually pretty rare, really, to find, but then having someone that do, like, a pen test, it's way more common. Then, in this case, you basically could have just a software engineer do the gap research, I would say, between the vulnerability and the code. And then that way, I think that you can have a great start on knowledge because it will be directly tailored to what you just did wrong, right? Because you just got a report of what was wrong with your system. But just don't go ahead and fix the bugs and that's it, because that's not the AppSec game. The AppSec game is to make something that works over time and that you don't do the same mistakes over and over.

**43:18 Chris Romeo:** Yeah, I think that's a great way to take us out right there. The AppSec game is avoiding making the same mistakes over time. Well, hey guys, thanks for taking the time today to enlighten our listeners on this issue of agile and AppSec. And we kind of went a lot of different places as well, but I think it was a great conversation. And folks, till next time, thanks for listening to the Application Security Podcast. 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. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/jon-mccoy-and-jonathan-marcil-agile-appsec/