October 12, 2020

Last Updated on January 13, 2024

Starting off strong with security in the design, development and testing of a new web application is challenging. But retrofitting a security approach onto a legacy web application? That can be an even bigger challenge. 

Where do you start? What do you focus on? How do you know if it might be time to “pull the plug” and rebuild the application?

A recent episode of The Virtual CISO Podcast drilled into this topic with none other than Jim Manico, one of the world’s leading web application security experts. Jim is the founder of the web app security training company Manicode Security, and a primary contributor to multiple Open Web Application Security Project (OWASP) projects, notably the Application Security Verification Standard (ASVS), the OWASP Cheat Sheet Series and the OWASP Web Security Testing Guide. Hosting the episode, as always, is Pivot Point Security’s CISO and Managing Partner, John Verry.
Jim shares a story about “one of the big eCommerce players” and how they had been lax in updating their third-party libraries. Then they recognized that they had a major security issue on their hands. “Finally they decided, ‘We’re going to fix this problem.’ And for a year, half of their developers were just doing third-party library updating,” Jim recalls.

“The point I’m trying to make is, sometimes with legacy code there’s no cheap way to fix it,” Jim emphasizes. “You’re like, ‘Well, what’s the quick solution?’ The answer is, there is none. You can either rebuild it or you sweat blood and tears and retrofit security. It’s just massively expensive.”



John asks whether it might make sense to periodically revisit a legacy web app and proactively re-architect or re-code parts or all of it, to avoid the scenario Jim just described.
Jim answers with another cool story: “I was talking to an application architect of a large bank, one of the top 20 banks in the world. I’m like, ‘What is the architecture of the software in your organization?’ He’s like, ‘Yeah. I’ve been studying that for 10 years. What architecture do we use at this bank? That’s a great question, Jim.’ I’m like, ‘Well, what is it?’ And he’s like, ‘I have no idea.’ … I’m like, ‘Why? I don’t understand your answer?’ He’s like, ‘Well, the architecture of our software is in flux at all times. There’s no way for me to analyze it.’”
“So the more complicated your software is, the more that architecture is going to be in flux at all times,” Jim explains. “Once you’re using a framework that is no longer updatable or doesn’t have a lot of active maintenance on it, it’s known to be a legacy framework. Should you consider rewriting big portions of that software? That’s a big money question. You’re rolling the dice now with sometimes millions of dollars.” 

John offers a great insight in response: “What you’re basically saying is, look, at the end of the day application security is business security. Application security risk is business risk. If the business risk is greater than or equal to the cost of redeveloping the application, then the answer is it makes sense to do it, right?”



Jim suggests you start by evaluating the risk. “When you have legacy software, you want to onboard it into your automated security testing mechanism. So you’re checking it with dynamic analysis, static analysis and third-party library scanning on a daily basis. And as we start seeing bugs in legacy software, let’s start addressing it.” 
Anyone involved in web app security should listen to this insight-packed episode of The Virtual CISO Podcast with special guest Jim Manico.
To hear this show in its entirety, and also get access to all the other episodes in The Virtual CISO Podcast series, click here.
If you don’t use Apple Podcasts, you can find all our episodes here.