In this episode of AppSec Builders, Jb is joined by security professional Jim Manico, founder of Manicode Security to discuss Application Security, Developers, and why they should be trained to build Secure Applications .
Jim Manico is the founder of Manicode Security where he trains software developers on secure coding and security engineering. He is also the co-founder of the LocoMoco Security Conference and is an investor/advisor for Nucleus Security, BitDiscovery, Secure Circle and Inspectiv. Jim is a frequent speaker on secure software practices and is a member of the JavaOne rockstar speaker community. He is the author of "Iron-Clad Java: Building Secure Web Applications” from McGraw-Hill.
Intro / Outro: [00:00:02] Welcome to AppSec Builders, the podcast for Practitioners Building Modern AppSec hosted by JB Aviat.
JB Aviat: [00:00:14] Welcome to this episode of AppSec Builders I am JB Aviat and I am honored to welcome Jim Manico, who, on top of being a famous, opinionated security professional, is also the founder of Many Good Security, where she trains software developers in secure coding and security Engineering he is also an investor advisor for many companies, frequent speaker on secure coding practices and a book writer with Ironclad Java Building Secure Web Applications. Jim, why don't you introduce yourself as well?
Jim Manico: [00:00:50] Jean-baptiste is a pleasure to be on your podcast and your show. And like you said, I'm an opinionated application security professional. I just hope that my opinions are helpful to you and your audience.
JB Aviat: [00:01:04] Opinions are always helpful, especially when they are held by smart people. So, yes, definitely. And I'm looking forward to have you sharing a bit more about that with our listeners. So, Jim, thanks a lot for joining us today. So when we are familiar with your work, we can notice that your primary focus is developers. So you train them, you write books to educate them. You contribute to a lot of OWASP resources around education. Why that focus centered on the developers?
Jim Manico: [00:01:40] I believe that the application security industry traditionally has primarily been about security testing and dev ops and all these different pieces that are about assessment of the security of an application. And I do not believe that you can achieve security through testing. I believe that the only way to truly do application security is to get developers to build secure software and to utilize tools and techniques and processes that will help developers, author, secure software. And I believe that our industry places very little focus on that important specialty because it's hard to sell an idea. The idea that you must change your process, you must change your engineering capabilities and similar. It's not something that sells in the marketplace. It's education, which is not a very big part of our industry. So that's why I focus on that, because it's my specialty and it's also my belief. That's how you really do application security is to enable developers capabilities around security in some way.
JB Aviat: [00:02:54] And a so you've been doing that for a while. What are the big changes that you have witnessed over the past year?
Jim Manico: [00:03:01] I think the acceleration of dev ops is very interesting. Now, Dev Ops has been around for 20 years. This is about automation around the building, testing, deploying in other aspects of the SDLC. And we were doing that in the late 90s through a lot of custom scripts and similar. And I think that today there's extremely modern tool sets like Jenkins', GitHub actions and similar, where I can build a significant security centric dev ops pipeline in a really short amount of time now, especially if I'm using GitHub actions. Click, click, click. And I got dependable that I got static analysis and some grep. I got dynamic testing and similar testing tools really rapidly in terms of setup. And I believe in a few years that when we're using GitHub in similar repositories, advanced security testing that we see today will be natural and automatic in just a few years. Other trends that I have seen are for more intellectual is the migration away from traditional session management and the movement of stateless session management using JSON Web tokens and the OS two and the open IDE Connect protocols and other JSON Web tokens centric standards. This is a very big departure and change around how secure Web and API applications are built. I also see a lot of new changes in HTP response headers, content security policy, the different response headers to delete site data at logout time, ways I can configure referrer policy or very granular now the advancement of cross origin, resource sharing and the capabilities being available in most every browser. I think that all those response headers have changed dramatically in just the last couple of years to give developers more security capability in modern browsers.
JB Aviat: [00:05:07] I definitely agree that don't get me started on JSON Web tokens, but. She already did, and that's a huge fan of the and we took in, because I think that's an interesting evolution in the world of security. It's a bit complex to configure. Right. There are several things you don't want to forget. And to me, that's a tool that has very interesting properties. But that is a bit hard to give, as is to developers like these specifically need the training and education in order not to misuse it. Right.
JB Aviat: [00:07:37] With your line. Yes. Things. So I think that's a very interesting time to be in security today because. Yes. Of things evolving. You mentioned headers, Clinton's security policy. So, yes, we have a lot of new tools that are evolving and changing the security capabilities that are into the hands of the developers. So that's a necessary step in the journey towards being more secure. There is no question about that, though. Those tools and those security primitives are still extremely complex to implement. If you take a look at the latest security headers that are centered around the Specter meltdown, protections like the complexity of those is really insane. And I feel either we need weeks of training for the developers that will have to use that properly. And Fulu is the mess of like its original house brothers, etc. though we need something in between, like a layer that will automatically configure the application. And I think this is where there is a builder between what you can teach the developers. And no one has infinite time to teach developers and what the tools should be responsible of. And so you said one very interesting thing in your introduction, Jim, is that you teach the developers to use the right tools. And I think that's that's a big part of the business, is to help them find the right tools.
Jim Manico: [00:16:03] Only some of my customers need that. Most of my customers don't use ie 11 anymore. But according to the W3 C browser statistics i.e. elevons, global use is statistically zero percent at this point as of last month. So we see I 11 finally starting to go away. But content security policy three. I was looking at the Safari Technical preview and within the last couple of weeks I see players that are building content security policy three support into Safari. So now now if we can get developers to implement CSP three, I like Anon's Pastrick, dynamic policy perspective, YOLO and Weichselbaum from Google's research and I limit what browsers I allow my customers to use. I can build some extremely rigorous security today. And I think that when we go ahead a year or two year, two or three and I have CP three everywhere and techniques to limit browsers and a little more awareness about third party libraries, that the capability of developers to build a secure application without excess is going to be more realistic. That's my hope job. At least all we have is hope. But I do agree with your conjecture. The cross site scripting and complicated Web applications is really hard to avoid, even with talented, security centric developers. And that's a problem with web development in a big way.
JB Aviat: [00:17:40] I agree it's still easier to avoid today than I think 20 years ago when you weren't using, like, templating engine server side. Yeah, the things were on one hand. Come on. And on the other hand, pretty neglected even at the beginning by security people. And so, yeah, I think things move to a very, very positive way. And we can only think Google here, who is really moving for a while, w3 C and leading implement this implementations we sickroom and I trusted. Stipe's was born from an initiative to solve the excesses problem at the Google scale internally. And so that's insane to see how well they managed to solve it internally. It's not like 100 percent solved with breathtaking. It's like 90 percent solved. And sharing that to the broader audience is amazing, as you said. Yes, it's not trivial to implement that shit within your customers. What are the strategies that you see to actually implement this kind of initiatives? It's complex at the scale of a company at scale.
Jim Manico: [00:18:46] It's extremely difficult. It requires at least today, it does require educating developers, which is not a very scalable activity. I realize that's difficult. So my goal is usually to educate the lead security champions of each developer team around content security policy using the Spagnuolo YSL bomb methodologies on top of libraries that use trust types. So who are these rock stars we're talking about? Chris Cristoff from Google is the author of Trusted Types, and Michelle Spagnolo and Lucas Shubham have been giving talks about how they roll out content security policy, which uses XP Level three on the conference circuit. I'm a big fan of their methodologies dramatised in any hero's journey you have helper's. I'm on a journey to learn about secure coding. Even though I am a teacher by trade, my real profession is being a student so I can learn these technologies enough so I may teach them properly and on my own journey of learning about this, these three individuals have helped me the most. Again, I want you to look these people up and look at their work. Michelle Spagnuolo, Lucas Shubham and Chris Cristoff. Those are the three top defenders of excess on the planet with the kind of. Knowledge and work that they are doing, and I'll credit Michael West as well from the W3 C, who has done a lot of work with content security policy at the standard level. Google is no perfect company. No one is. But a lot of the engineers at Google have led the charge in providing good security standards so we can build secure web applications.
Jim Manico: [00:20:34] And the way that I work with companies to achieve this knowledge at scale is not to influence every developer. I can't do that realistically in training, but I can influence the main security champions that reside in each team who are dedicated and responsible for secure software. So I try to influence those leaders so the knowledge trickles down to other members of the team. And that, of course, assumes that a company even has security champions embedded with their developers in the first place. But that's the best way I think, that this kind of knowledge will trickle into large companies, because as a side note, it's a lot of application. Security leaders have been telling me that education is not important or that education is not going to work. And I strongly disagree. We do not have methodologies that automatically and magically provide security without developers being involved. We still need developers to write secure software. I know that your company does some great work. I know that you're working on a product that does provide great security, but that's not magic and it's not going to work alone without developers being involved in some way. So I'm still like a lone wanderer with my cape and walking stick wandering slowly through each company that I can to influence as many technical leaders as I can to teach them about secure software as best I can.
JB Aviat: [00:22:17] I know you'll need to learn. There is no question about that. And the education is definitely a critical pillar of any security strategy. I think there is no question about that and it will likely be for a very, very long time. But you cannot disagree with the fact that some classes of vulnerabilities have disappeared from time to time. If you take the right framework with the right language, you can get rid of some classes of vulnerability.
Jim Manico: [00:22:47] Yes, I was debating on Twitter with one of the leaders of LinkedIn. Now, if I had a company that had one framework and the experts working on that one framework, then I can eliminate classes of vulnerabilities and not have to teach my developers about that class vulnerabilities. But remember, you've been around for a long time. How often do you show up to a company and they only have one framework and one way of building Web software? That's very rare.
JB Aviat: [00:23:18] Well, it happens till the day where you buy into the company. You're right.
Jim Manico: [00:23:23] We have this one framework. Oh, yeah. You have that one framework than that other version of your one framework on that project. Then on that legacy. One has an even older version of our framework. Oh, yeah, that acquisition has all those frameworks. So the idea that a company has one framework only, it's always up to date that is extremely rare. That's like less than one percent of companies. The reality job at least is I'm using twenty frameworks. I got hundreds of developers. We're all doing different things and having some knowledge around building secure software is fundamental to understand how to remediate the issues that show up in testing. I wish I only had one framework if I only had one framework that was maintained by many architects who knew application security then at I agree with you and that does show up once in a while. But it's the exception.
JB Aviat: [00:24:18] This it's not a realistic assumption. But let's look at the broader picture. So I'm an optimistic person at The Hurt. And so my thinking is that progressively most frameworks, Mr. Enbridge's will evolve towards an ecosystem that is more and more secure by design. If you take a look, for instance, at the Cerruti nineteen ninety five and I wrote a lot, I was very insecure because you had zero frameworks. Now you have things such as Symphonie all Harvell that amazing had handbells in the job of the group. It's much easier, just isn't perfect and you still need to read the documentation etc. but it is better if we take a look at a time frame of maybe ten to twenty years from now. Don't you think that most framework's. They have evolved towards a more secure version of themselves and you can call be a fool.
Jim Manico: [00:25:19] One of my dearest friends from Canada is a friend of mine, a developer named Jean Baptiste Lipless. And I haven't seen him in over a decade. So just to say the name of aTest again reminds me of my old friends. I'm gonna keep using your name I like it's a great name. But that aside, I agree with you 100 percent. In fact, Schumpeter's I'll even say this unless we have a radical transformation in the security capabilities of frameworks, there's no chance of achieving application security at scale. So not only do I agree that that's what's going to happen to the primary frameworks, we have no choice but to accomplish that. And if we don't accomplish that, we're not going to achieve appliqué security at scale. So I think big governments like the French government, the US government, whoever's got extra money lying around, I believe that if governments want to invest in cybersecurity, they should be spending billions and billions of dollars to assist. The major frameworks of the day have integrated security. Nobody wants to spend that money, though. I watch, like different governments, they'll spend billions of dollars for bull shit. Forgive me, they will, but they won't spend money to really address the heart of our security problems, which is the fact that our languages, frameworks and components that we use to build software today are all radically difficult to secure or need massive updates.
Jim Manico: [00:26:55] So not only do I agree with you, I think it's the only hope for society to solve this problem. And my belief is that if I was in government or politics or policy, I'd want to see all this money that governments are spending on cybersecurity now that they spend it on building elite developer teams who will work with the frameworks to integrate and test security at the framework level in better ways. That's my hope and dream. You don't quote me on the job when I retire from commercial activity and I'm much older and greyer than I am now, then I'd like to go work for some government with big money and funding to build teams, to work at the framework level and improve the security of frameworks so every company and organization in the world will benefit from those enhanced frameworks. I know some of that work is happening now, but it's happening slow. And the framework still all of them still require advanced, complicated knowledge to use securely. And that doesn't scale.
JB Aviat: [00:28:08] Yes, and that's a good thing. Actually, I was thinking about some of the good security traditions of the past years and thinking about like Ruby that popularized a lot of good practices in the Web. I was thinking about risks that could serve the before the Flooz instead of C, for instance. And I was thinking about Crume individual Thracian Demy, Christine, that you mentioned earlier. That's also brutal enough to goodness. And none of that, I believe, was led by a government entity, writes Rabinowitz's Basecamp, Croom's Google and the rest is musila unless I'm mistaken.
Jim Manico: [00:28:45] The point is it's all happening too slow. Ruby on rails. The only problem with Ruby on rails is that you have to use Ruby on rails. What an awful framework with one of the best security capabilities of any framework. The way that their data flow works. And I am not a fan of Rails. I can never, ever use it for an application.
JB Aviat: [00:29:07] But in Jim's opinion here.
Jim Manico: [00:29:11] But I want to be objective and they've done incredible work when it comes to security. Absolutely. But this is happening too slow. What about spring? And I can still make big mistakes in rails. I can still make big mistakes in spring and symphony and every other framework out there still requires sophisticated knowledge. And the slow progress we're making is not enough progress. And I don't even know why I'm bringing up government and policy. I rarely discuss those topics. We're in an era where governments are starting to spend big, big money on recovery around the world. And I would just like even just a couple of billion dollars directed at developers that are advanced, being paid properly, working specifically to do security in the common frameworks of the day. Just let's hit spring. Let's go hit JBoss. Let's go hit Symphony. Let's give Ray. Also, more security support the net berry needs some support, just 10 framework's one hundred million dollars worth of development effort for each of them and we can revolutionize the world. But again, nobody wants to spend that money. They'll spend it on a new choo choo train or some other like manufacturing plant or like some other like research project. But let's spend real money, real money on the most common frameworks of the day. And we can advance application security more than the slow, gradual progress that we've been making for the last 20 years.
JB Aviat: [00:30:49] And so you're a Java expert, I think. And so if you had to start from scratch and you Java project today, what would be the most secure system that you could recommend?
Jim Manico: [00:32:45] I don't want that burden. And even though it will take me some extra work to build some of the piping that comes out of spring, I'd rather have that code myself that I can work on. I'd also make sure I only have senior developers on my team. I do not believe in junior developers and that is a harsh reality. I know a lot of junior developers who are having trouble getting work because a junior developer who can't really operate in a production environment, they end up costing a company more than they benefit from that developer unless they stay there for many years. And most Start-Up developers don't stay for a few years. They become junior developers. They join the company, they get some training, they can get a bigger salary and they leave. And that ends up being an expense to a company, not a benefit. So my advice is, in your career as a developer, go from developer to middle developer and skip the junior developer part. No one needs a junior developer to skip it and go right to being an advanced developer through your own boot camp training or whatever. But nobody wants a junior developer because they end up causing more harm and taking up more time than being good. And this is I don't say this to be rude. I say this to be realistic about the state of our industry.
JB Aviat: [00:34:05] So how do you go from out of school to not general developer?
JB Aviat: [00:35:53] So what you're saying is that the universities don't do a good job at training developers, basically, right? No. Well, that's where the government could spend some of that money. Maybe.
Jim Manico: [00:36:02] Maybe so. Maybe so. But I think that if you want to be a professional developer, you're better off skipping university, go to a nine month developer boot camp on modern languages and development techniques, and you will have a better chance of getting a well-paid job than going to a university program. The problem is university professors are mostly not writing production code for a company. They're academics. And it's so difficult to keep up with modern development techniques that university, even the best ones, tend to be behind in what's needed in software development and for that matter, security and real development shops today. I feel terrible saying this, by the way, properties, I wish it was not true,
JB Aviat: [00:36:50] But I think that's the direction of the world anyway. We need more developers today than we needed 10 years ago. And 10 years from now, we will need even more developed than what we have today. So it's required as there is no choice but to have those education methods evolve. Otherwise, mechanically, the level of general developer will only go lower and lower. So what you're saying makes sense,
Jim Manico: [00:37:14] But it makes me feel filthy to say these words, though.
JB Aviat: [00:37:20] You train much more developed than I do. So I think you know what is out there very well. Thank you so much for sharing that to me. Is there anything you'd like to share before we finish?
Jim Manico: [00:37:31] I just ask that if you're listening to this podcast, please say hello to me on Twitter. That's where I do most of my public communication these days. My Twitter account is manicured m a and I c d, e. So if you're listening now, please just say hello to me on Twitter. Tell me if you care about secure software and secure development. That's all I care about.
JB Aviat: [00:37:55] If you disagree with anything that you just said, just let us know on Twitter. We'd be happy to share your thoughts. Thank you so much for joining me today, Jim. That was a really, really fun to talk about all of those value subjects with you. I really appreciate I can't wait to actually meet you when the real world comes back. And maybe in Paris,
Jim Manico: [00:38:16] Paris, one of my favorite places in the world, I will be in Paris as much as I can. So let me see if I'm pronouncing your name properly. You try to be Frenchman Jean Baptiste Aviat.
JB Aviat: [00:38:25] My God, yes. That's perfect. That's perfect. But next time you can just call me Jim. All right.
Jim Manico: [00:38:33] You've got to be perfect.
JB Aviat: [00:38:36] Thank you so much for joining us, Jim. I really appreciate. Have a good day.
Jim Manico: [00:38:40] Have a good day yourself.
Intro / Outro: [00:38:42] Thanks for listening to this episode of AppSec Builders. You can find all the resources discussed during this show on AppSec Builders dot com. Be sure to subscribe to our podcast to get updates on our upcoming episodes.