Security Education With Jim Manico

"Jim Manico: The breaches come up, they're getting bigger, they're louder, they're more damaging to society. But all that breaches are, to me, it's that momentary reminder, security really matters a lot. We are entering a new era, everything you say must be more precise and taken to a new level of rigour. Think of the culture of software development. Once you get everything working, don't touch it, it works. That's been the mentality for decades, and that mentality is destructive when it comes to third-party library security. This is why we're talking. This is why we're here."

[INTRODUCTION]

[0:00:36] Guy Podjarny: Hi, I'm Guy Podjarny, CEO and Co-Founder of Snyk. You're listening to The Secure Developer, a podcast about security for developers, covering security tools and practices you can and should adopt into your development workflow.

I'm excited to announce that The Secure Developer has expanded into a fully-fledged community. Check out thesecuredeveloper.com for great talks, and content about developer security, and to ask questions and share your knowledge. The Secure Developer is brought to you by Heavybit, a program dedicated to helping startups take their developer products to market. For more information, visit heavybit.com.

[INTERVIEW]

[0:01:10] Guy Podjarny: Hello, everybody. Welcome back to The Secure Developer. Today, we have an awesome guest, one of the – maybe the most well-known figures in the world of application security, or definitely one of the more noisemaking ones of it, is Jim Manico. Welcome Jim to the show.

[0:01:24] Jim Manico: Thank you so much for having me on your show, Guy. It's great to be here.

[0:01:27] Guy Podjarny: Cool. We've got a lot of great things to sort of talk about here. But I think, for the sort of three people in the audience that might not know who you are. Jim, can you tell us a little bit about who you are, what you do, maybe a little bit about how you got into this sort of world of security AppSec?

[0:01:43] Jim Manico: Absolutely. Guy, I'm a security educator, I travel around the world. I teach software developers to write secure code, with a team of different trainers' part of my company. I've been a developer since I was a kid. With 30 years of writing code, I started as a Commodore 64, assembly developer, and coding ever since. I was brought into security by Stephen Northcutt, who is a fellow resident on the Island of Kauai, where I live. Stephen, maybe I think 20 years ago said, "Jim, anyone could be a developer. You need to be a developer who study security, and it will be a great benefit to your career." I listened to him, and I'm grateful that Stephen Northcutt dragged me into the security industry. Now, I'm doing secure coding for living and I love doing it.

[0:02:26] Guy Podjarny: Yes. Well, that's quite insightful also 20 years ago. That's some forward thinking there.

[0:02:30] Jim Manico: Absolutely.

[0:02:31] Guy Podjarny: To see this coming. Today, it's I think a slightly more well-known fact that security is key.

[0:02:37] Jim Manico: Absolutely.

[0:02:37] Guy Podjarny: I guess, you've lived and you've sort of evolved, like you're doing the security education for a good while now. Has that always been the case? Like, I guess, how long has it been security education versus the developer? What was that tipping point kind of going from doing the coding to doing the training?

[0:02:53] Jim Manico: Well, I started my firm about four years ago, and I've been doing like 100% developer training for a little more than four, almost five years now. Other jobs I've had over the last 10 years, I used to work for white hat, I did training for them. I used to work for SANS, I did training for them, it was always a part of my job. This is the first time in my life where training is my 100% of my job. I was in the classroom over 100 days last year. I love it. It's not just teaching, it's research, it's studying, it's doing sample coding. It's reading other people's research, it's participating in the conversation of application security, trying to actually contribute something. It's working at OWASP as a volunteer, helping with standards.

There's a whole collection of activities around being able to be a good educator, I just love doing it. This is the greatest puzzle of software development. It's not just my job, it's is my passion. I love doing application security, it is fun.

[0:03:49] Guy Podjarny: That's awesome. Well, we need kind of more of that knowledge disseminated. The sooner the better, as well. It's all very, very important gospel. I guess, let's dig into that. We're talking security education, developer security, whatever, even with sort of that narrative of it being a good sort of career choice these days. Where do you think we stand today? You go around, you talk to these developers? Do people know security? What's the sort of state of affairs do you feel around developers' kind of knowledge and maybe adoption of security?

[0:04:22] Jim Manico: Let me take a step back. I think it's really key that companies get how important this is. When I was brought into training, say, 10 years ago, it was a quirky thing. It was something to do on the side because they had some extra budget lying around or because compliance told them to do it. They didn't move down with their life. Today, training is something that I have to take very seriously. I've always taken it seriously, but 10 years ago, when people took the training and didn't think about it for a year.

[0:04:50] Guy Podjarny: Yes. They didn't care about the results, they wanted to check the box that they've done the training.

[0:04:53] Jim Manico: Today, like 10 years later, where every little slide you talk about, it's going to affect their policy. It's a whole different level of responsibility. I've had people call me and say, "We just earmark 30 million, so we can turn our entire infrastructure to internal HTTPS and stronger transport security inside of our network." When I first heard that, that was about three years ago, like my jaw hit the floor. We are entering a new era of everything you say must be more precise, and taken to a new level of rigour because of how much people care about this topic now. I think this is this the golden era of application security for me, because we have a mature tool set for assessment. We have really good books and literature on assessment. We have a plethora of intelligent people thinking about building securely. It's not at quirk anymore, it's now a core part of development, at least among the teams that I interact with.

[0:05:49] Guy Podjarny: Yes, that's awesome. I love kind of those comments on, in general, about adoption of security. Specifically, HTTPS, I think is one of the big wins of the world of security.

[0:05:58] Jim Manico: I agree.

[0:05:59] Guy Podjarny: I know just like very much instead of carrot and stick on one hand, making, you rank higher on Google or things like that. And advocating for security on the other side, making it easier with less encrypted likes. Then, alongside all of those, having the browser start marking you as not secure.

[0:06:16] Jim Manico: Exactly.

[0:06:16] Guy Podjarny: I guess, we've sort of seen this shift a little bit, which I relate to, and I feel – maybe there's two trends, maybe they tell me if you agree with this. I think there's two trends driving this. On one hand, maybe once again, the stake are sort of the external one, which is breaches, just like more, and more security problems that occur, and the implications of not doing it make a big deal. On the flip side, what you have is you have sort of this accelerated development. Everything is becoming software, your clouds are becoming software, your servers, your network, your infrastructure, everything is becoming code. The people writing that code needs to secure it. So almost like the scope of what is application, what is application security has grown. Do you feel those? Do you see those two narratives? Do they make sense to you at all?

[0:07:05] Jim Manico: I think it absolutely does. Let me start by saying, this kind of question, this is important. What's motivating people do AppSec. This is not something I think about a lot. I'm usually worrying about how can I get this SDLC program to be rigorously within the organisation. So just bear with me on this. is that, yes, the breaches come up, and they're big, they're getting bigger, they're louder, they're more damaging to society. But all that breaches are, to me, it's that momentary reminder, "Oh, shoot, security really matters a lot." Then, it goes away, and we hear it in the news. It's important, those reminders are important. It helps me justify budget, it helps me justify time, it helps explain to the board, and the sea level staff why application security matters. We have to very often rethink everything about how we write software. That's helpful.

But it doesn't change the culture, it doesn't actually fix the SDLC program. It's just the stone in the pond to get the process started, or continued, or renewed in some organisation. It's important, but it's just a small piece of the puzzle. The next one you were saying is, we see everything moving to software. Again, this is really critical, and that, all of infrastructure has changed now. Suddenly, developers or developer like people are now directly involved in infrastructure. I see in some people's top 10 lists, that cloud configuration is one of their most difficult issues to get their hands around from a security point of view. These two things are critical. But I'm going to say that, again, breaches are the stone in the pond, to give us a reminder that security matters at different parts of our company's evolution. Everything moving to software is yet another reminder of how important software is.

I'm going to say something controversial that a lot of people don't agree with. I think to move to the cloud in my world is the same old, same old, and no one agrees with me here. I'm on my own here. It's more code. My form that collects data, that goes to a database, or my report, or my advanced business logic, financial flow, that code is all mostly the same, man. I have the same vulnerabilities to struggle with there. Yes, as I attach this code, up to the cloud, I have all different kinds of ways to hook my code, and application to cloud services. I agree with that.

I have been slinging code for 30 years, it's all the same old code to me is what I'm saying. But it's the same old level of importance, it's the same old, "We have to take this seriously." It's the same old, "We need to train our workforce, and have assessment tooling in place, and have sea level staff supporting these efforts." And take that product manager who doesn't drive security but has control of all of my requirements to take them to the roof and drop them off the roof. Sorry about that. And then it goes to the ceiling. We do that kind of stuff. Get the product manager out of our way

All those, what I think are was core problems in AppSec delivery. Guy, that's all the same. What I see is different is the acceleration of how much people are taking this seriously. That's hard.

[0:10:11] Guy Podjarny: Yes. I think the acceleration maybe is the keyword. I'm actually like, I'm right there with you, which is, the fundamental problems are input validation, there's just some core elements that we're now doing in sort of the same premises. I do think we've enlarged the scope a little bit. It used to be that AppSec couldn't compromise in all your storage. But today, maybe your sort of cloud configuration is indeed sort of an aspect of your code. But beyond that, maybe it doesn't impact security directly. But it doesn't impact the development pace. By doing so, kind of kills the notion of a gate, kills the notion of an external audit.

[0:10:49] Jim Manico: Now, that's the point I think is critical here. It's that, the general attack surface of all software has grown dramatically in 10 years, infrastructure in terms of how we host our software, infrastructure of the world, interconnectivity of everything. Absolutely. The need to get software security right has grown dramatically in an unmeasurable way, just in the last five or 10 years. The fact that so much is moved to the cloud, and our code is now infrastructure. That's a critical part of that mammoth growth of attack surface of software. The drum beat is getting louder, the importance of getting this right is getting louder. The frameworks and the kinds of ways to deploy to the cloud, the frameworks we're using, all that is expanding as well, which makes it a lot more difficult to get our hands around application security. But I get your point, and I'm with you, Guy. Attack surface growth.

[0:11:42] Guy Podjarny: Yes. I love the guidelines. I guess, the bottom line of it is kind of merging. The perspective is to say, software security remained the same. But what is software and the pace of software has changed. We still need those same mechanisms, but just the context of what's at stake, and maybe the complexity of how to get it done is the thing that has changed, because software has grown.

[0:12:04] Jim Manico: I'm going to steal that quote from you, and say it in conferences, like I thought of it, so I could sound smart. That's awesome.

[0:12:12] Guy Podjarny: That's what we do. That's what we do, That's the purpose of podcasts. That's the whole intent. How do we do it? Maybe let's kind of get down a little bit from the, "Okay, fine." It matters, this is important, it's growing in importance. Budgetary wise, and all that, maybe organisations are getting it a little bit more than before, and they're willing to drop their $30 million on HTPS initiatives. How do we kind of get it embedded? You come in, you talk to a shop, what would you say are like the kind of core premises that need to succeed for people do indeed get AppSec right?

[0:12:44] Jim Manico: From the beginning of the SDLC, I like requirements and training. I like training, not just because I do it for a living. I recommend my competitors to do training as well. Just in general, I want an educated workforce, even the basics of application security, number one. Number two, I want to have a clear definition of security requirements, so we're all on the same page of what this thing called application security really is. Number three is having a security champion. If you don't have an AppSec expert directly embedded with your team, your likelihood of having application security gets low really quick. Three things, security requirements, number one, a trained workforce and knowing the basics of secure coding and application security. And having a security champion that developers have access to, that can lead the intellectual part of what it means to write secure software. Those are usually three of the first things that I'm looking for. I'll even give you a fourth. Alongside of that, I usually want to ramp up basic assessment infrastructure very early on, if that's not there already. These days, it usually is there in some way already. There's my three and a half.

[0:13:52] Guy Podjarny: Okay. Cool. Let's pick them apart a little bit. The requirements, how do you handle that? You have good security requirements, high level. Maybe, more specifically, how do you see these type security requirements manifesting in an agile world? You've got a place – it's not like a PRD that you write, and like a year down the road, some software would be delivered? How do you do security requirements? Give us some nuggets of best practices there?

[0:14:16] Jim Manico: From the open-source world, I want to avoid doing something like using an OWASP top 10 for my requirements. This is just an awareness document. This is meant to, again, do teaching and education to get people started in web security. For that matter, I want to keep away from the OWASP proactive control. This is another awareness list. The standard I start with is the ASVS. This is OWASP Application Security Verification Standard. The 4.0 release is coming out in a matter of weeks. This is like 200 plus requirements.

As an early stage, I want to take all the main stakeholders and security pro, product manager, some of the lead developers and go through the ASVS, and fork it completely for their company. Sometimes, that's where we stop. Sometimes we fork the standard, nobody uses it. But we've gone through a training process to walk through every single requirement that we need to care about with the technical leads. That's the weakest maturity of rolling out requirements. At the high level, we have requirements rolled out, and we've translated all those requirements into where it exists in the framework, where we need to do it ourselves manually, or where we have third party tools to help us, or where you need to go talk to Bob to go get help on that, because we already have our own standards. When you're taking the requirements, and breaking them apart, and really getting into the details of how you as a company are going to address them in that working process. That's when I think requirements are the most useful.

But again, let me go back to the beginning. I've seen people roll out requirements, never read them, and still have that process be helpful, because the tech leads were able to influence the lead developers for four or five hours, just talking about what's important for security. Even that is a useful process. I daresay, no matter how you roll them out, it's going to be helpful in some way.

[0:16:10] Guy Podjarny: Challenging though a little bit. I'm fully with you, by the way. Like fine, in a raising awareness, and bringing practicality to it, sort of bringing some like what does it mean to be secure, and these concrete elements is spot on, sort of immediate value there. You talk to a lot of organisations, you train, you see how they operate. What's an ideal scenario in an agile team, like a team that sort of works in this sprint environments? How have you seen the security requirements embed there? Do you see like, is this an area that we've developed? Are there good examples? Because there's no, they're going to have the requirements for whatever, like the product. But when it gets to dev, does it make it into the sort of the sprint feature plans? How do you see that happening?

[0:16:52] Jim Manico: Sure. Before you start sprinting, the thing about agile is, agile is a mix of discipline and fast moving. A lot of people will take the discipline part of agile, and throw it out the window, and move real fast, and change requirements as they go. In that scenario, you're screwed, you're not really doing agile, you're just moving fast in a clumsy way. The point is, let's take the pieces of agile that are discipline and consider those for a moment. I want to have a well-trained workforce on the framework and platform that we're using.

Part of that framework and platform is understanding the security controls of using that framework. Before you started sprinting at high speed, if you mapped all your requirements to your environment, and made it clear which one of those requirements are handled by the framework, and had a trained workforce who knew how to use the framework properly. Now, we're agile. Now, I can move extremely fast, and I have a basic static analysis, or basic assessment that's checking my work as I go fast and furious every check in. Now, I'm starting to do AppSec.

It's that pre-step of mapping your requirements to responsibilities. Do you have those libraries available? Do you have the authentication and access control methodologies established already? Do you have your key storage or cryptography dialled in already. If all these pieces are missing, and you're in an agile world, I claim you're not agile, you're not AppSec agile. You're running fast, but all these basic components to secure coding are not in your environment yet. I can't help you. You're at the beginning.

Suppose you do have an authentication service, and you have an access control, best practice, really well established, your own homegrown permission-based system that's real detailed, and it's great. And you've gone through basic training, you have subject matter experts, you have a great assessment DevOps pipeline dialled in. when people think DevOps, they're mostly thinking, "Yes, I have a pipeline of tests." Great. If you have those pieces into play, then requirements, the ones that you're not addressing will become helpful. Now, I know that these 20 requirements I'm not addressing, so I can target education just to the area of ASVS. Where my framework doesn't handle it, where my subject matter experts are not into that, and I can limit the focus of what more I need to do to spread the word on those requirements.

Again, if you're actively using requirements in a mature DevOps, agile kind of world, and using them as a core study for responsibilities, and you have those pieces of discipline in place, I think they're really useful. I think by themselves, and to your point, a lot of times in the agile environments, they get ASVS in a place, they read it, then they let it go, and just do what they normally do. That's not uncommon to your point, and that's not helpful.

[0:19:43] Guy Podjarny: That doesn't get you as far. I love the analogy of it, like the picture that comes to my mind is basically thinking, thinking about all that infrastructure we talked about as the same as having Kubernetes in place, or having like a monitoring system, and sort of having your build system, and sort of having chosen whatever react, or whatever, as sort of JavaScript framework. All those decisions, the requirements, they're within the context of agile, even the discipline to agile. But they're basically infrastructure, is kind of like, you need to build security infrastructure, just like you've built your DevOps infrastructure. It includes the tooling, but it also includes the competencies, sort of the technological requirements, the equivalence of uptime, and sort of time from build to production, the equivalence of those in security.

Then, even, that ties in perfectly into sort of that third, before the three and a half. I guess, we'll get to the half in a sec. But the third element there, which is the AppSec competency, because the other thing that you say in agile is, the team needs to be sort of a full-stack team. We don't do a frontend team and a backend team if you're doing agile. In a proper fashion, you have a product ownership, you have some scope of that of the system that you control. The AppSec competency needs to be within the agile team to get that done.

Digging into maybe that third bit about the sort of the opposite competency, which models do you see that work? Is it availability? Are those AppSec people a part of a different group or are they – they're just somehow affiliated, made available, to the dev teams building it? Do you see? Do you recommend? What do you think is right around having that AppSec champion be actually like a member of the development team? Is it a full-time job? Is that a competency? What do you see there that you think is like a good model for success?

[0:21:29] Jim Manico: I'm going to answer this little awkwardly, but we had a lot of security problems. One of the dev teams I was working with us, we solved the problem by removing two developers, not by adding anything, but by taking the two beginners who were writing a huge amount of volumes every day, it got them into a different project. That solved our problem, that got us to a better risk play statistically. The point is, I want senior developers on my team. If I have a security critical product, the first thing I'm going to do is get beginners out of the way. This is a horrible thing to say, nobody wants to hear this. But you need a developer, in my opinion, who's been writing code for three to five years before we even start talking application security in most of the teams that I work with.

Step one, having a senior team that already understands the rigours of process, and they're actually engineers, and not just code hackers. Once I have a team of engineers, I can institute all the above: process, requirements, infrastructure for testing, all the pieces we need for good application security. Training becomes easier, training doesn't become this difficult thing. These developers who've been around the block for a while that I should be able to explain SQL injection once in five minutes, and never bring it up again, and it's never an issue again. I shouldn't have to reteach that team SQL injection every six months. Something's wrong there.

So, going through teaching, having a subject matter expert. You asked earlier, the closer that AppSec expert is to be embedded and integrated with the team the better. Over at Google, some of my heroes are Michelle Spagnuolo, and Lucas Weichselbaum. These are experts in content security policy. But they're not like standard body members, like tweaking with the little variables in the standard. They're embedded inside of Google's team. Implementing CSP, that's the kind of AppSec expert that I feel is the most valuable. Absolutely. Those are my two points; have an embedded AppSec expert, and a senior team of developers, and be careful of the damage a novice developer can do to security on a project.

[0:23:38] Guy Podjarny: It's an interesting kind of perspective. I guess the conversation always goes to the max expertise. That embedded AppSec expert would be the, "Hey, there's base level expertise, who's your high-level expertise? I guess you're sort of saying, actually, you know, what the core of your problem is more from the minimum level of expertise, what's the sort of minimum level of competency. Which again, I love drawing analogies to general software practices on it. This basically goes straight up to quality. I guess, you can do things, like if you have novices on the team, which eventually, you want to have. All those experts have started somewhere.

If you have novices on the team, maybe you want to constrain them, or sort of have them focus on being framework users, or basically just sort of two areas where they have less ability to screw up from a security perspective, by sort of working within some sandbox until they develop enough maturity to sort of build the secure coding.

[0:24:32] Jim Manico: Guy, you're a nice person, and you're describing this from a nice person point of view. I'm not, I'm way more militant. I want novice developers not to be seen. I want them to go away. I don't mean that cruelly. It's that's every single time – the point is, when you're a novice developer joining a senior team, you should be paying me. You're lucky because you're getting more training right now, you're getting personal attention from senior folks that you're taking away from doing their work, and you're not producing for me that much. It's harsh, and I don't mean this in a cruel way, I'd rather have two very senior developers than 20 novices. That's what I'm trying to say.

I see a lot of my customers who've experimented with this, where they took training, but they saw from three different teams, that one person was a rock star. One of my customers took these three different rock stars, put them in a team together to do secure coding. These folks were able to deliver level of secure software that nobody else in the company could pull off. What they did was, they built a large project. It had like three medium findings after months of work. This cracked open the mind of the whole company, because everybody else was trained, everybody else has tooling in place, everyone else had the same resources.

But the team of senior developers, three of them got it, ended up delivering so much better secure software than everybody else. It brings me back to a core principle of being cautious of novice developers. They tend to cost more than the benefits of having him on teams where rigorous security engineering is important. Guy, this is a horribly unpopular opinion. But I stand by it, I've been rolling around the software industry for a long time. Every time I see a small, but senior team, they're able to accomplish magic, including application security magic, that I haven't seen in other configurations. That's my answer to this. Senior, educated, people who understand that we're not just slinging code, that we're doing engineering, that's where I think the win is.

[0:26:43] Guy Podjarny: You're sort of entitled to the view. I think we're not that different in our perspective. Maybe I'm giving a nice spin. I wouldn't be offended by being called a nice person, but I think those other three people were sort of building those secure coding platforms. They didn't let go all this sort of novice players, but what they've done is, it sort of had them build systems that use the libraries, and the access system, and the sandbox, that those sorts of trial, whatever, sort of have established for them. We might be going in circles here. Point well taken. Sort of maturity of the engineers, kind of that high quality. I daresay that, that also kind of works well for a quality analogy, like a lot of those choices, you wouldn't take your novice developer to choose your JavaScript framework or so to build it.

[0:27:26] Jim Manico: I agree. For novice developer, you do want to box them in to a very specific set of duties that we can monitor, and control, and review, but I'm with you.

[0:27:35] Guy Podjarny: And give them a chance, give some of them a chance to become from novice to expert.

[0:27:39] Jim Manico: You're a nice guy.

[0:27:39] Guy Podjarny: The few that survived, give a light at the end of the tunnel.

[0:27:43] Jim Manico: I want you to give them a chance, and once you've grown them into mature engineers, I want to steal them all for you.

[0:27:52] Guy Podjarny: Let's jump from the people bits to maybe that infrastructure, that sort of tooling. I think we're sort of painting a really kind of good picture here of what do you need to do to sort of get this done? I guess, what is the sort of the tooling stack that you need today to sort of do this stuff successfully? What do you see in that sort of infrastructure?

[0:28:12] Jim Manico: Static analysis, dynamic analysis, and third-party library analysis. Those are the three critical assessment tools that I think every single team should be running as frequently as possible. I see third-party analysis as almost a form of static analysis. It's specialised. I don't think the static analysis tools that we traditionally look at do third party analysis as well as they could. I think the industry has split those up pretty well. We have dedicated static analysis running every single time a developer checks in code, or builds code, or deploys code as frequently as we can.

That's awkward, because it's rare where static analysis will run quickly. We have to play with these whole tunings within a DevOps environment, usually tuning static analysis to run fast, then running it out of the automation environment, slow on a regular basis. I think that's almost a solved issue now. We've done a good job with rolling those products out across the industry.

[0:29:07] Guy Podjarny: It's a fair practice to highlight, for the SAST. If you do the static analysis, the SAST application, then you do one variant of that, he sort of per check in incremental, lower comprehensiveness, if you will. So the scan, but that is able to scan with sufficient sort of accuracy and speed to be reasonable for the dev flow to use it. Then, you do an out of band, sort of static analysis as more comprehensive. That would be the model.

[0:29:36] Jim Manico: I think that's the standard model I see in most places that are taking this seriously. Where assessment matters to them for their program, that's usually the dual way that I see static analysis rolled out in the modern world. To miss either of those is bad. To only do it once a month in full mode, you limit the daily loot kind of checking you get when you use it every day. If you're only using it every day, you're missing the depth of the tool because it often takes more than 10 minutes for a good static analysis tool to run across a complex codebase. You need both. I think that's solved; I don't think it's interesting anymore. It's solved. If you're not doing static analysis, go do it both those ways, or you're barely beginning. Let's look at the other categories, other categories. Dynamic analysis next, right?

[0:30:20] Guy Podjarny: Yep.

[0:30:20] Jim Manico: In my world, the best tools and dynamic are the cheapest ones. I tend to use an open-source world, ZAP, it's got a lot of decent capabilities. I can literally go to developers and say, "Hey, I want this feature." Depending on my ability to support them, I can get it. I think tools like Burp have become really popular as well, their dynamic scanning engine will go head-to-head against any of the big players. Then, the work is getting these dialled into automation. I can now run them not once a month with a consultant, but I can run them every single day in some fashion.

I think the work of getting dynamic added into your automation environment is a little bit trickier, because of the nature of how DAST works. For static analysis, it's going to touch code, and I'm done. For dynamic, I need a whole dev infrastructure. It's more complicated and more work to get dynamic rolled out. But it's a part of, of all the core. Now, where dynamic is screwing up, though, dynamic, even though the tooling of dynamic is getting better, the effectiveness is going down dramatically. Because it's getting harder to look at all the JavaScript frameworks, and it's getting harder to look at APIs and Min stack. That's the core of development now. The web app has migrated to the thick JavaScript applications, React, Angular and Vue that talk to backend APIs. These are two things that traditionally DAST has not done a great job at.

There's area for innovation when it comes to JavaScript static analysis, even to this day. Guy, we just started another company on the side, get a few good researchers, and do a dedicated JavaScript security company; JavaScript, static analysis, JavaScript framework analysis, JavaScript education. I think that's a gap in the industry right now. But that's my opinion on DAST, in general.

[0:32:09] Guy Podjarny: Okay, perfect. Great practices. I don't think there's anything for me to repeat there, so that was well articulated, SAST, DAST. Then, the third bit, open-source analysis

[0:32:17] Jim Manico: Guy, I'm not saying this because I'm on your podcast. But I believe that third-party security analysis in my world is the number one issue more important than SQL injection now. Because of how problematic it is to deal with this, because of how poor the ecosystems, like in particular, in my world, Maven, and npm, the big code repositories of the Java and JavaScript ecosystem. These are not run with security in mind at all, in my opinion. It is a complete bleep show how bad it is, and we desperately need tooling that can go deep into the Java world, and deep into obscure things like, I need to know if this third-party React module is decent for me to use. And, I need third party security library tooling, and I don't think there's any option here. This needs to run as frequently as possible.

What I like about third-party analysis is I can run it in under a minute, often, or within a couple of minutes. It's built from the ground up to work in a DevOps environment. If you're not using something to do third-party security analysis, on it like 100 times a day, I think you're negligent at this point. The hard part about this is, when people are given awareness about third-party libraries, and they see, "Oh, no, these 170 libraries are out of date from security." The initial hit to get up to date can sometimes be years. Anyways, those are the three kinds of tooling that I think every development shop should be doing as a bare minimum, to be assessing the security of their applications during development.

[0:33:55] Guy Podjarny: Yes, awesome. Well, preaching to the choir clearly about that thi5rd bit. I do think, one kind of good practice to sort of share on the backlog, as you take the blind off, and you see the disturbing number of issues that that you have there. Clearly, one aspect of it is invest in remediation. But the other bit that we've kind of embraced from the performance budget world is to draw lines to sort of not get any worse. So you can do, whatever. We do some of this at Snyk, but if you want to, you can roll your own. Which is to take a snapshot of where you are, and for starters, say, "Hey, put something into build that would only fail or in your pull requests or whatever, that would only fail if you're introducing another new library that has a vulnerable component. And, alongside that, introduce something that tracks your dependencies and alerts, or new vulnerable libraries."

The notion being, you roll something out, like again – shameless plug here, Snyk could be it, but this concept, you can roll this with whatever you want. Just to roll something out that draws a line and says, "Actually, it will not get any worse." It's a concept, as I said, that we kind of pulled from the world of performance, and performance he said, "Hey, I want to –" Tim Kadlec, actually popularised it, saying, "I want to improve my webpage speed. But for starters, I need to like stop making it worse. Why don't I just take a measurement, measure your page 10 times, see how long it takes to run, and then just put whatever that range in the build. And every time, run a test. If it takes more than that amount, fail the build, don't allow that through." Or, say, "I'm only allowed – I've got how many JavaScript libraries do I have on my page, 17. keep it to 17. If I add an 18, you have to take one away." Things like that, so you sort of establish from a security perspective to say, "I might not be where I want to be, but I'm not going to get any worse." And then, you eat away at us sort of a security debt over time.

[0:35:44] Jim Manico: Guy, the best way I can flatter you is to say, I'm going to go and give a talk at a conference or give a talk in training. I'm going to cite that exact concept of how to properly roll out. This is an interstitial process where I can stop the bleeding, at least detect when a new third-party library that's insecure is introduced, and still let the old one survive for now, during this interstitial process of rolling out third-party tools. This fills a gap in my mind, I love it. I promise you; I'm going to talk about it in the future, and giving you no credit. I'm sorry, I'm going to pry for that. I'm going to act really intelligent, and it's the best way I could flatter you.

[0:36:24] Guy Podjarny: Add Snyk at the end of there and we'll be tied.

[0:36:26] Jim Manico: I'll slap Snyk in there. Guy, I want to say it again. My claim that third-party analysis, security is the number one issue. I didn't change that to make you smile. That's my honest opinion. Because it's big, it covers every possible vulnerability out there, and it's something that a lot of people are just flat out frightened to deal with. Think of the culture of software development. Once you get everything working, don't touch it, it works. That's been the mentality for decades, and that mentality is destructive when it comes to third-party library security. This is why we're talking. This is why we're here.

[0:37:02] Guy Podjarny: Agreed. This has been awesome. Before I let you sort of disappear here into your sort of training black holes. I like to ask every guest that comes on the show, if you have one pet peeve, or word of advice, one thing you want to tell a team that is looking to level up their security poster, what's the one thing they should do or they should not do that you want to sort of convey?

[0:37:27] Jim Manico: That's a hard one, because I want to answer the question, well, what 200 things should you do? But let's go to one. All right, one. This is a boring answer, but it's good. Several of my customers have software that's so big, like 400 plus microservices. They're having trouble keeping their hands around. It's just too big. Even with lots of smart architects, all the right resources, nobody understands what's going on because it's just too complex of software. This is the bane of application security developments.

The way I've seen people handle that is to put mammoth focus on one easy thing, logging, logging, logging like mad people. They log every single thing across every single service, so they get really good visibility into what's happening. When things go wrong, they see anomalies, they can take immediate action. This is the 10th item in the OWASP top 10, do good logging. I tend to, go ahead and log. Now, let's move on with our lives and talk about more important things. This has become more important in big software. Big software is hard to lock down just because the nature of its complexity. Adding in lots and lots of logging is a relatively simple engineering task, I daresay. It gives us mammoth visibility.

I'm here to tell you, take your logs seriously. That visibility is crucial to run time security analysis and understanding when problems are happening in the real world. Let's log, Guy. Let's log like crazy. Let's log everything. Let's go log wild. That's what I'm saying.

[0:39:01] Guy Podjarny: Here, you've got a quote. Now, I can steal something off you and not give you any credit for it.

[0:39:05] Jim Manico: Log wild, baby.

[0:39:07] Guy Podjarny: That's awesome advice. Jim, this has been a pleasure. Thanks a lot for coming on the show.

[0:39:11] Jim Manico: Guy, seeing all your success of your firm is well deserved. I'm happy for you. Thank you for working so hard to solve such a critical and difficult problem in AppSec. Keep on rocking.

[0:39:21] Guy Podjarny: Cool. Much appreciated. Thanks, everybody for tuning in, and hope you join us for the next one.

[OUTRO]

[0:39:28] Announcer: That's all we have time for today. If you'd like to come on as a guest on this show, or get involved in this community, find us at thesecuredeveloper.com, or on Twitter, @thesecuredev. Visit heavybit.com to find additional episodes, full transcriptions, and other great podcast. See you next time.