Show 125: Jim Manico Discusses Static Analysis, Open Source, and Developer Training

August 30, 2016

Jim Manico is the founder of Manicode Security where he trains software developers on secure coding and secure engineering. He is also the founder of Brakeman Security which produces a Ruby on Rails security scanner. He is a volunteer and Former Global Board Member of the Open Web Application Security Project (OWASP) and the author of Iron-Clad Java: Building Secure Web Applications. With nearly 20 years of software development experience, and over 10 years of application security experience, Jim is a highly sought after speaker on security practices specializing in the notion of building as opposed to breaking.

Listen as Gary and Jim discuss recent developments with static analysis, the relationship between open source and security, programming languages frameworks and how they impact tools, developer trainingenterprises moving to the cloud, and island life.

Listen to Podcast

Transcript


Gary McGraw: This is a Silver Bullet Security Podcast with Gary McGraw. I’m your host, Gary McGraw, CTO of Cigital and author of Software Security. This podcast series is co-sponsored by Cigital and IEEE Security and Privacy Magazine where a portion of this interview will appear in print. This is the 125th in a series of interviews with security gurus, and I’m super pleased to have today with me Jim Manico. Hi, Jim.

Jim Manico: Hi, Gary. How are you doing today?

McGraw: I’m good. I know it’s way early in Hawaii, so thanks for joining us so early in the morning.

Manico: Well, I’m very honored to be on your show. So thanks for having me, sir.

McGraw: Jim Manico is the Founder of Manicode Security where he trains software developers on secure coding and security engineering. Jim is also the Founder of Brakeman Security which produces a Ruby on Rails security scanner. Jim is an advisor to Signal Sciences. Mr. Manico is a frequent speaker on software security practices and specializes in the notion of building as opposed to breaking. He’s a volunteer and former Board member of OWASP and authored the book Iron Clad Java from McGraw-Hill. Jim lives on the island of Kauai with his KKCR radio producer wife, Tracy. So thanks for joining us.

Manico: Thanks for having me on the show, Gary.

McGraw: Let’s start with your view of a technical trend that I find a little bit worrisome. It seems to me that static analysis, which flourished just a few years ago, may be stagnating in the enterprise in some respects. Do you see that in your work?

Manico: I do see some people just simply not using it, which to me, in 2016 is a shock. I don’t see static analysis as anything advanced or even interesting. It’s something that everyone should do early in the SDLC. Among people I work with, if anyone is not using it, I’ll flag it as a dramatic and major problem. But yes, I do see folks—some moving away from it. Or even worse, Gary, they’ll use it but use it in very ineffectual ways, like only look for criticals or not let it block anything—just run it, maybe deal with it, maybe tell developers about it. So I see a multitude of problems, either not using it, using it ineffectively, or just not understanding the importance of doing it very early in the SDLC.

McGraw: Yeah, that makes sense. Do you think that lightweight approaches that are now being developed in a number of places will help?

Manico: Well, I’ll say that in two ways. First of all, we have a lot of problems with people moving to DevOps quickly. We’re going to do DevOps, we’re going to do all automation, and we’re going to have static analysis be a core part of that. And then they end up tuning static analysis to only show critical bugs or remove certain security areas to make it work well within an automated DevOps environment. And then major bugs slip through, major bugs that SaaS could have found slipped through. So I just want it used effectively.

What I do like—the trend is technology where folks are integrating and building static analysis that’s live in the IDE. People talked about this 10 years ago, but I see the beginnings of companies who are building it in very effective ways. It’s like a spell check for a coder as I’m writing code. Static analysis rules will fire up in real time with advice of how to fix it. That is awesome. That’s extremely interesting to me.

McGraw: So maybe that’ll kind of rescue the stagnation problem that I think I’m seeing. I hope it does. Tell us about Brakeman and how its use is going and future plans and all that. That’s a Ruby on Rails static analysis tool.

Manico: My history with Brakeman is I know Dr. Justin. Dr. Justin is the real engineer who built this open source tool, built it from the ground up, and has been working and maintaining it over time. And, Gary, a lot of people build open source solutions. They celebrate their open source solution for marketing and then walk away from it. That infuriates me. Dr. Justin, he’s been working and maintaining and adding rules to it consistently for many years now, which is why I’m so impressed with him. I went to Justin and said, “Justin, you should consider a commercial fork of this. I’m not saying stop the open source version or do anything out of integrity from the open source world, but there’s need for a pro version.” And then a year later, he went and did it. It’s myself, Neil Matatall, and Dr. Justin. I’m a small partial owner and guide of this project. It’s Dr. Justin who’s the brains and the real muscle behind that project. I’m very honored to have my small part in it.

McGraw: No, I totally get that. It reminds me of FindBugs a little bit, which Bill Pugh really did when he was a professor at Maryland. And then his grad student who, by the way, worked at Cigital a trillion years ago, Dave Hovemeyer, was getting his PhD and now he’s a professor at a small college in Pennsylvania. Dave was the guy who really kept that going. And also it was open source and it also needed kind of a commercial front end, so they integrated it with various tools like the Fortify Static Analyzer so that you could use the open source thing and dump the results into something that might be more useful. All that said, do you think Brakeman use is going well out there? Is it making a difference in the Ruby community? Do you have an eye on that yourself?

Manico: I do. And a lot of the statistics we see on download from the open source world, we don’t even collect that data. Dr. Justin really is trying to add something to the community. So a lot of that community data visibility he on purpose does not collect for the sake of privacy. In the commercial world, we did push out Brakeman Pro. It is a live product now. And we don’t have a lot of customers, but the customers that jumped in are giant. So all of a sudden, overnight, we’re doing business with multi-billion dollar communication companies and similars who are depending on Brakeman Pro. There’s not a lot out there in the commercial world that does really good Ruby on Rails analysis. And this is a one trick pony tool. It does Ruby on Rails analysis. I dare say it does it really good and there’s no desire to expand beyond that. So, frankly, I’d like to see more tools like that—that do a couple languages extremely well instead of doing lots of languages in maybe less robust a fashion.

McGraw: I totally agree with you. And I think that’s especially important when the paradigm is an old school language like Java or J2EE or C versus a new dynamic language like JavaScript.

Manico: Yep. JavaScript is just really difficult to analyze. As one of the ways that I troll my good friend Dr. Justin, I constantly add bugs and bring up agendas in our meetings to say, “When’s the JavaScript version of Brakeman Pro coming out?” Whoever does a really, really good JavaScript static analysis tool, which I do not believe exists in the market today, that’s a mammoth gap as the whole world rushes to JavaScript development both on the client and on the server.

McGraw: I think it’ll have to be way more dynamic just because of the nature of JavaScript and the nature of assemblies. But you’re right, whoever does that right—that’s super-fast and a new solution—will make a big difference in the world.

Manico: What I say about JavaScript analysis, it’s best to collect the JavaScript dynamically, but best to analyze it statically. What I mean by that is I want to hit a website, get back the JavaScript that they’ve assembled dynamically, because if I look in the code base, that JavaScript may be in fragments dynamically built in some way. The JavaScript I get back from a dynamic analysis is stuff that I can now really analyze statically because it’s usually complete and well-formed JavaScript. So just an idea there. It’s tough, it’s tough to analyze JavaScript.

McGraw: Well, that gives you a point in time, which is certainly better than nothing. But it’s still just a point in time. A lot of work to do there.

Let’s turn the channels to open source a little bit. You are a major OWASP contributor of the highest order, so you’ve got to have lots of thoughts about open source and security and so on. What are your thoughts?

Manico: Wow, that’s a big question. I think that OWASP, from an open source point of view, does a few things exceptionally well, and does a lot of stuff that we’ll put in the research category. My world is mostly Java, Gary, so I like to highlight the Java tools that have been extremely disruptive from OWASP. The main one is the OWASP Dependency-Check tool from Jeremy Long. That has destroyed several companies and taken income and it’s harmed companies that depended on that, and that’s what positive disruption should do. It’s innovated very well, it’s free, it works, and it takes out products that normally cost six, seven figures.

McGraw: You know Jeremy Long, of all people, is super fantastic. So whatever he produces is going to be great.

Manico: There’s also a tool from John Melton, another fantastic person. He built a tool called AppSensor, which is a way to embed intrusion detection alerts inside of a Java application. There are teams building this, but it’s John who does AppSensor. It’s Jeremy who does the Dependency-Check. So I’d like to look at open source security tools. Rather than supported by a large community, I want them supported by one or two stellar experts. The encoder, there’s no good encoding library to stop XSS in Java. So we have Dr. Jeff Ichnowski who wrote the OWASP Java Encoder. There’s also no good HTML sanitizer to sanitize third-party authored HTML snippets. So Mike Samuel from Google wrote the OWASP HTML sanitizer. Those four Java tools I see as either being production quality or close to production quality, disruptive or helpful in some way where I would use them or I do use them in my own projects. And I want to counter those tools to the sea of hundreds of other tools that don’t have that level of production quality. I’m not even sure I have a judgment to make on that. That’s just the state of the union at OWASP open source.

McGraw: That’s cool, but let’s talk about open source in an even larger sense. What about all of the piles of open source that, as security people, we have to contend with outside of the security tools range? What are your thoughts about that?

Manico: Got you. It’s just scary, Gary, because there’s trillions and trillions of lines of insecure code that we depend on right now. Right now, Gary, somewhere out there a developer is looking for a third-party library to satisfy a programming task on their plate. And they go and Google or DuckDuckGo or Bing around looking for this particular third-party library. They find it, they download it, they mess with it for a little while, it works, and now it’s live in their project. What do we miss? We miss security analysis. We missed even due diligence in looking at the security history of this library. This developer didn’t look at the code! Compound this by millions of times, and that leaves us where we are today. There’s trillions of lines of open source code that we have to contend with. At least in the Java space, in the .NET space, I like what Jeremy Long is doing, Dependency-Check.

McGraw: Absolutely, that’s the way to do it.

Manico: It gives me something, Gary. It gives me a little something. It’s not perfect. It’s not the solution, but at least I’m now doing my due diligence as a developer or security or server administrator where I’m doing something to check for that. It’s a tough problem.

McGraw: So let’s talk about something closer to your heart which is J2EE, Java. What are your thoughts about frameworks like Spring? Another way of putting that is, in your view, what’s the security situation with the use of frameworks and how does that impact tools?

Manico: I’ll give you two different philosophies. I’m going to throw a little cognitive dissonance at you and throw a couple of different perspectives because it’s not a simple issue. It’s complex. So I’ll throw a few ideas. Spring moves the problem around, right? It moves the problem from something I have to code to something I have to configure. And so now when I’m using Spring Security, it’s like death by XML. I have to configure so many things to get this right. So I have to become a master at Spring Security configuration to the point where there’s now helper projects to help me build Spring configuration in an easier way. So it’s like you’re kidding me. There’s your answer right there. Let’s say that again, Gary. There are meta projects to help you configure Spring Security. There’s my answer. It’s tough. It’s not easy.

McGraw: So how do you think the tools that are working well with Java can be brought up to date when they’re processing Java code that has a lot of framework stuff in it?

Manico: I don’t have a clear, good answer because there is such an infinite number of ways to configure Spring, how do I thoroughly check for that? It’s just a really difficult and challenging problem. Just like JavaScript analysis, I’m saying I want to grab JavaScript dynamically but analyze it statically. And your comment, a very fair comment, was, “But that just gives you one perspective, Jim. I may send different data in and get back different JavaScript. What happened to your analysis?” You’re right. The same thing happens in Spring. There’s such an infinite number of ways to configure it. If my tools only look for one particular kind of configuration, it’s going to give me a limited perspective. So I think we should keep trying. I think we should keep throwing research dollars at the problem for various tool vendors.

My experience, as someone who’s invested in or started several small tool companies, is that the estimation for how long it will take to build rules or triggers (whatever you want to call them)—the estimate is always way under by a factor of 10. I’ve seen three companies…

McGraw: Oh, dude, it’s more like a factor of 1000.

Manico: Yes!

McGraw: When we built the Fortify tool stuff a million years ago—what was that thing called? Secure Scope or Secure something—I don’t know. At Cigital, the real problem was the rules. And, frankly, they had to be produced at gunpoint to get them done.

Manico: Exactly, because it’s horrifically painful and hard to verify if you’re building rules correctly. It’s time-consuming research, it’s time-consuming to write the actual logic, and it’s time-consuming to verify if I even built that rule correctly. And it’s not something that gives developers that satisfaction of getting a page to work or a widget to work. You get that little charge. Yes, it’s working! I could be writing good rules for weeks and I never get as much satisfaction and the work is much more difficult. So there’s your answer. Spring Security, what can we do better at this? Yeah, just throw heaps and heaps of money and resources and the top tier talent you have at this and hope for the best. I don’t know what else to do.

McGraw: We’ll be right back after this message.

If you like what you’re hearing on Silver Bullet, make sure to check out my other projects on garymcgraw.com. There you can find writings, videos, and even original music.

McGraw: So let’s talk a little bit about evolution of Java. Scala has, in some sense, served as a training ground for new language features in general. And it seems like the way that they’re adopting stuff in Scala and trying it out is causing Java to adopt some of those features more quickly these days than before. Do you think that’s true? And what does that mean?

Manico: I’m not big on the LangSec differences of Scala versus Java. I don’t have a lot of interesting things to say there. Let me pivot on you, though. Java 8 and 9 have an extraordinary number of new security features to help Java developers build more secure apps. That’s what excites me about Java. And this is the talk that I’m giving at JavaOne next month where I’m going to highlight the security features of the newest versions of Java. They’re trying to get the cryptography and TLS better, and internal validation. We can now customize the JVM and only deploy certain modules now, and more. So I think they’re learning from the hipster languages, the componentization world, the need for validation deeper in the framework, and I’m very happy with the movement that Java’s making. They’re not as far as .NET. .NET is another 10 years ahead of the game when it comes to LangSec, but Java is getting there and they’re putting a lot of serious effort. That’s not an exact answer to your question, but it’s what comes up in my mind at least.

McGraw: No, that’s okay. That was exactly the question I was trying to get to. But that kind of leads to this. What happens when new programmers (that you grant them Java, which is “you now have fire”) get instantly accelerated to “you have Java 9 and you have a nuclear reactor”? Do you think that matters to learning?

Manico: Well, this is where Cigital comes in, right? If you’re building Java for nuclear reactors and you’re not bringing in some kind of really advanced software security consultancy and assistance, we got a problem. Get help! Bring in some help!

McGraw: That’s just a metaphor, though. If the developer can barely get Java to work and you give him all these advanced features in the new versions of Java, do you think that’ll overwhelm them or do you think net, net that’s a good thing?

Manico: I’m going to pivot again and it’s because if you just give a developer a language and say, “Go write me some high assurance software, go figure it out,” wait a second, Gary. We’re missing a couple of touchpoints here. We’re missing secure coding standards, secure coding checklists, architectural guidance, some kind of standard and training that we’ve given this developer, some kind of corporate standards that we’ve built. And if we’ve armed the developer with all of that, then it’s a different question. If we just give the developer the language and say, “Go build me a feature, go figure it out on your own with no assistance,” then we’re asking that developer to write heavily insecure software. Is that fair?

McGraw: Yeah, totally fair. So let’s talk about training a little bit. What are your thoughts about security training: instructor-led training versus, say, computer-based training? And what’s the most effective way, in your experience, to teach developers secure coding?

Manico: Gary, I can’t answer that question objectively. This is what I do for a living. This is how I feed myself.

McGraw: I know. That’s why we want to know. We want to know what you think because you think about this more than most people.

Manico: I think that a combination of both is going to be important. And I don’t want to stop with either one. Instructor-led training, especially by someone who is a developer, who speaks the language of developers, who has good and up to date material, all of those kinds of things—it’s very time consuming to build good secure coding material, that’s a great way to start initiatives. It’s a great way to get everyone on the same page, but once the trainer leaves, developers will have questions. So we need to have a center of excellence and other things available to the developers there beyond just the training. Again, it’s good to kick-start an initiative, especially when customers ask to customize the content. Why am I talking about generic authentication when I could be talking about how to leverage your authentication layer and similar stuff? So it depends on how serious the customers take the training.

My favorite customers go through every slide, make change requests, have their own standards added to the material, and it’s no extra time for me to do that. It’s very minor. But I know they’re going to take it seriously. They care about this beyond just a check box. And I think those kinds of instructor-led training initiatives, where the customer really owns the material and digs into it, ask for changes, that’s how you get the most of an ILT. Computer-based training scales extremely well, right? You can’t bring in 100 trainers for a large team. So we often need CBT to supplement what’s done in a normal ILT, instructor-led training, type of environment.

In the past, the different CBT stuff that I’ve seen, Gary, is horrible. And I don’t mean bad, I don’t mean problematic, I mean absolutely horrible. And so I’m working with one of your companies right now to build high-quality CBT training material, and that is so exciting to me. This is with Codiscope, Gary. One of the partnerships I have is with Codiscope. I’m writing content for them and we have a production media team on board, professional graphic artists on board, storyboarding and building media like you would at a professional media outfit where we’re doing good security instruction. But, it’s with a professional delivery system in small segments. I believe this is going to be an extremely big deal. It’s part of the new trends in micro-learning. It’s a way for developers, while they’re working, to get on-the-spot little snippets of training. That kind of thinking, Gary, I don’t just like it, I’m very excited about it. That’s the future of training.

And it’s far away from what I do in instructor-led training, but imagine this combination where an instructor shows up, they work with the company to make sure the material is on-the-spot for what they’re trying to accomplish, and then they start using a tool where developers get alerted with these same ideas while they’re working. Little, small three to five minute CBT trainings pop up as they’re going. That’s exciting. That’s going to change how developers write code. And that’s what I believe, the whole industry, that’s the direction we should all be moving in.

McGraw: Yeah, I like that. I think that’s a very good answer that you just gave. I remember back when we trained, I think it was something like 2,500 people, the first year at Qualcomm with ILT a million years ago. And we were all excited until we realized that they had hired, that year, 2700 developers. So we were minus 200 net. And so the idea of ILT is absolutely the most effective in my view as well, but it is hard to scale, and the combination approach really seems to work the best.

Let’s talk about enterprises and actually moving to the cloud, because you run into enterprise Java situations a lot in your work. So four years after the hype started, how do you think that this move to the cloud is really going and what makes a large enterprise comfortable with cloud computing?

Manico: My first comment—something I say often to my students is just because your code is running in the cloud, it doesn’t change your need to write secure code at all. It’s going to be the same basic code, the same basic structure, the same security controls will all be needed. And so, again, you’re moving the ball around the field. Rather than depending on your own administrators to handle the problem, you’re hiring a third party to do it. So honestly, Gary, in my world, whether it’s cloud or not has very little difference. I’m usually discussing code-level architecture. And it’s not that different as you migrate to different cloud platforms. It’s the same challenge.

So once again, I apologize, I’m not answering your question directly. It’s not an area I put a lot of focus in. Code is code. Code needs to be secure whether it’s on your phone, a cloud service provider, or a local server.

McGraw: So back to OWASP for a second to close things out. Now that the Top 10 has entered the zeitgeist, what’s next for the OWASP organization, do you think? What would you like to see? Let’s make it Jim’s fantasy world.

Manico: My recommendation is that the OWASP Top 10, everybody is allowed to read it once, and once only, and then they have to be banned from ever looking at it again. Any time someone is building a software assurance program, they should not be allowed to use the term “OWASP Top 10” at all. Anybody who’s delivering training, they should never be allowed to mention the OWASP Top 10 because there’s more than 10 things. I want to replace all global mentions of the OWASP Top 10 and change it to the OWASP Application Security Verification Standard. This is not perfect, Gary, but it’s closer. It’s a 200 item, 3-tiered standard on how to achieve basic Web application and, to some degree, mobile and Web service security. Now we’re talking more comprehensive multi-tiers for level of risk. It accounts for different levels of severity and it’s more comprehensive broken down by security area. So I think if you really want to pull something from OWASP to help you with software assurance, I would grab the OWASP Application Security Verification Standard in the 3.0 version and fork it specific to your organization.

People pay big money to get secure coding standards for their group. ASVS, the Application Security Verification Standard, can help that process. I would never use ASVS off the shelf as it is. I would fork it and make sure developers own it. And this is subtle, Gary, but when I’m trying to build a secure coding standard for a group of developers, I don’t want to hand them a standard from security and say, “You have to do this.” I sit with them, go over ASVS one at a time, and see which ones the developers want to accept and which ones they don’t. Now it becomes a list of standards, not that I forced upon them, but that they themselves decided were good for their organization. That’s a great step one in establishing a standard. I used the OWASP ASVS standard to help me get there, and I think it’s a more comprehensive guide and a better representation of what we could be doing at the OWASP foundation. So if I were king, which I’m not, Gary. I am not king. If I were king of OWASP, I would replace the OWASP Top 10 with the ASVS standard since it’s much more comprehensive.

McGraw: Great. That’s a good answer. Well, I have one more question that has nothing to do with software security, so we’ll turn to that. What is the most charming and frustrating part of living on a 522 square mile island?

Manico: There is nothing bad about living here at all. Let’s make this very clear. I live on the island of Kauai, which is paradise. People save their whole year to come here for two weeks, right? And this is my home. And I say the word, “I’m lucky, I feel lucky.” And my wife is like, “You’re not lucky. You’re fortunate. Be fortunate.” So that’s the language I like to use. Living on Kauai is a precious gift. I feel extremely fortunate that my path took me to living here. I live in a nice home. I have a really lovely wife, and great neighbors, and an ideal living situation. And I count my blessings every day.

When people come to visit, I always try to open the red carpet for them. I had a salesperson from a competitive company drop by in the security space, so I went out and bought some nice ribeyes, made a nice steak for them, and walked around the property and try to extend the aloha spirit to anyone that visits. And Gary, let’s talk for a second, Gary. I have a three bedroom house with three bathrooms, and not one of those bathrooms has…

McGraw: Has a plastic shower?

Manico: No plastic there at all. They are all granite, marble, serious showers.

McGraw: This is very important to me, so that’s good.

Manico: I normally say to people, “I’d like you to come visit. Please, drop by.” But to you, I say, “Gary, no plastic showers in my home. Please come and visit.”

McGraw: Well, I really enjoyed doing that radio show with Tracy, too. That was a lot of fun. So hopefully, one of these years we’ll do it. Thanks very much for participating today. It’s been really interesting, Jim.

Manico: I mean this sincerely, Gary, it is a big honor to be on your show. This is one of the oldest podcasts in the application security space. I’m just tickled that you asked me to be on the show. Thanks for doing what you do.

McGraw: Absolutely. This has been a Silver Bullet Security podcast with Gary McGraw. Silver Bullet is co-sponsored by Cigital and IEEE Security and Privacy Magazine and syndicated by Search Security. The May/June issue of IEEE S&P focuses on the economics of cyber security but also features our interview with Jacob West in which we discussed the IEEE Center for Secure Design.

Make sure to watch the video we shot to celebrate episode 120 of Silver Bullet, 10 years of the Silver Bullet Security Podcast. 

show 125 - Jim Manico