DevOps Chat: 12-Factor App and Security, with WhiteHat’s Eric Sheridan

What exactly is a chief scientist? Eric Sheridan at WhiteHat Security tells us. More than that, Eric gives us what he calls the “the security addendum to the Twelve-Factor App.” I guess to understand this, you need to understand something about the Twelve-Factor App methodology.

In this DevOps Chat, Eric lays out a well-reasoned approach to AppSec and some good research findings from WhiteHat. Have a listen.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, DevOps.com, Security Boulevard, and you’re listening to another DevOps Chat. We’ve got a really good chat lined up today. I’m happy to be joined by Eric Sheridan, who is the chief scientist at WhiteHat Security. Eric, welcome!

Eric Sheridan: Hey, Alan! Thanks for having me on.

Shimel: Great. Hey, Eric, a lot of people listening out here are probably thinking to themselves, “Hmm, Chief Scientist? That sounds like an interesting job.” Why don’t you explain to our audience kinda what is, actually, your role and responsibilities as a chief scientist, and how does one actually go about becoming a chief scientist?

Sheridan: Yeah—sure thing. So, I think the first thing you have to do to become a chief scientist is go buy yourself a nice little lab coat.

Shimel: [Laughter] No.

Sheridan:  Yeah, the [Cross talk]—yeah, it always kinda makes chuckle a little bit. But, I mean, in reality, what I specialize in and what I help customers do is integrate security throughout their development process. And my specialty is very much around building the automation technologies that are needed to perform security testing that is both fast and accurate early in the development life cycle.

And, you know, to someone who’s looking to, I guess, get to this position or get to this point, I’ll just sort of—a little bit about my background and how I got here. I started out being in security first. So, I got into the security industry, very much focused on network security. Then I was introduced to application security, but I also was a developer at heart, so, I liked to build things. And so, those combination of skills allowed me to get to this point.

So, if you or if one of your listeners is looking to become a quote-unquote Chief Scientist of Security, having a combination of those skills and those passions will go a long way.

Shimel: I agree with that. You know what? I think passion for a particular role or area is—really outweighs almost everything else at some point, right?

Sheridan: Yeah.

Shimel: If you’re jazzed to come into work every day and work on something you’re passionate about, it’s almost not work at all. That’s great, Eric. And for those listening out there who, you know, in this day where we all make up titles and everything—

Sheridan: [Laughter] Right.

Shimel:  – being a chief scientist, I think, really is—it’s something you can sink your teeth into, you know what I mean? And good for you.

Sheridan: Thank you.

Shimel: So, I wanted to talk to you a little bit about today, you know—well, we should also mention WhiteHat Security for those who aren’t familiar. I’m gonna do this one for you, Eric. You know, WhiteHat Security was probably one of the pioneers in web application security I’m gonna guess, what, starting 12 years ago or more?

Sheridan: Yeah.

Shimel: You know, they really kinda pioneered the idea of do it yourself testing, your apps, and reporting and all of that. And, of course, they’ve come a long way in there, but they’re still a leader in web app security. And Eric, if I missed anything, jump ahead, jump in.

Sheridan: Sure. Well, I think WhiteHat’s history is a great lead-in to the topic of this consultant and DevOps in general. WhiteHat Security was the first security vendor to offer security as a service, whereby, you know, at the time, was very much focused on testing websites through automation and the cloud. And, with the transition to the cloud and to DevOps via automation and collaboration, the value of that proposition just increased. And so, over the years, we’ve been expanding our offerings to include things such as scanning source code for vulnerabilities, scanning dependencies for vulnerabilities, doing this testing earlier in the development process, all with an emphasis on supporting cloud related technologies. And so, it’s been a pretty fascinating ride.

Shimel: Absolutely, it really has. And it’s rare that you see a company stay sort of at the forefront, especially with something as dynamic—no pun intended—

Sheridan: [Laughter]

Shimel: – as web application security testing and so forth. But that being said, let’s jump in here. So, you know, Eric, you’ve been talking a lot recently around a security addendum to The Twelve-Factor App. And I guess—again, for our audience and for people maybe who’ve come more from the DevOps side of the house than the security side or vice versa, we can’t really talk about the security addendum to the 12-factor app until we talk about what we mean by The Twelve-Factor App.

Sheridan: Sure. Yeah, so, a few years back, there was a manifesto of sorts put out called The Twelve-Factor App, and the idea behind The Twelve-Factor App was to really provide a checklist or an itemized list of considerations that developers and product development teams should evaluate when building their software for the cloud. And, over the years, it gained a lot of traction. It influenced a lot of design patterns and has provided a lot of benefits with cloud adoption in general.

At WhiteHat, and in my view in particular, we’ve seen a lot of our customers adopt elements of The Twelve-Factor App as they build their software. And it’s allowed them to excel in that development and achieve the more functional goals, but along the way, we notice some interesting security considerations that were not factored in—pun intended—to their efforts.

And what we’ve done is, having worked with these customers over the years, we’ve tried to consolidate some of the observations that we’ve had into a list. And, you know, there was an internal debate as to how to manage these recommendations, right? I mean, at the end of the day, we were thinking—okay, do we have another, you know, top 10 list of things to do? Does everyone really need another top 10 list?

We felt like that was the wrong approach, and instead, what we did is, we looked at The Twelve-Factor App, the concept, and said—the folks who wrote this, they hit the nail on the head. It’s a great thing for developers. What we in the security industry need to do is sort of bend and mold our recommendations to fit in the developers’ world. So, rather than coming up with a new list, what we tried to do is come up with a set of recommendations that are security centric for each of those 12 factors, and which would serve very much as an addendum to The Twelve-Factor App. And this is what we’ve been putting together, what we’ve been discussing and presenting over the past, I’d say, several months now, and we’ve gotten a lot of positive feedback from the folks that have listened in.

And so, we see this as a really great opportunity to vocalize security consideration in a context that development teams and product teams understand.

Shimel: Understood. I have to apologize, I’m getting that little bell thing on my Mac, and I don’t know how to shut it off.

So, one of the things that I spend a lot of time with, Eric, is talking to non-security team folks. Developers—well, we’re all security folks at some level, but, you know, not people who are traditionally part of the security team. Developers and ops people and QA people and architects as well as executives. And, you know, this concept of a security addendum, of adding security to their normal operating procedures is something that I think we’re in a state of flux. Some people embrace it, and some people still resist it.

And I’m wondering kinda what you’re seeing in trying to, for lack of a better word, evangelize this sort of thought pattern in the market.

Sheridan: Sure. So, yeah, with respect to resistance, any time you get into resistance, there tends to be, it tends to stem from culture, and perhaps diplomatic issues within an organization, depending on its size. And so, a lot of times when I encounter resistance, there is not a good sense of collaboration between the security team and the development team. And, you know, sort of thinking DevOps at a high level, collaboration is one of the key tenets.

And so, when those organizations are going through that process of adopting DevOps or adopting The Twelve-Factor App to move their stuff into the cloud, that collaboration becomes more important. Which is good, because it facilitates the dialogue.

Now, to work through the resistance, what I try to do—and honestly, this actually would work in personal relationships, too—you stick to the facts. Stick to data points and try not to take anything personal, and just walk into the discussion with the assumption that everybody wants to make things better.

And one of the data points I really like to discuss, and then I’m plug—pulling from our WhiteHat stats report is, the improvements that you see when you integrate security early in the development process, there’s a pretty scary statistic in a report that says only 56 percent of critical vulnerabilities are being remediated late in development. So, this is at the point when something’s already been either in staging or is in production. So, out of, I don’t know, let’s say 100 critical vulnerabilities, only 56 of them are getting remediated. When you take into account the severity of that, that’s scary.

However, when there is collaboration, when you can work through that resistance, we’ve seen actually a 50 percent drop in vulnerabilities that are found in production when you integrate security automation and technologies early in the development process. In addition, we find that there’s a 25 percent faster time to fix improvement. So, development teams are actually able to respond and fix things earlier.

So, I try to use stats like that to really grab the attention that there are tangible, measurable benefits, and these are good reasons why we should ease up on that resistance. And then, of course, the challenge is, once you get their attention and you realize that the folks on the other side of the team will realize that there’s value in where you want to be and where you want to get to, then you just—we have to plan out that journey to get there. And that’s where, you know, technical capabilities, automation, collaboration, accuracy, speed—all of that stuff becomes vitally important.

But yeah, I try to stick to the data points to work through that resistance, and just one of them happens to be the vulnerability reduction when you do security testing early in development.

Shimel: Sure, sure. And, you know, Eric, I mean, I didn’t have the luxury of the WhiteHat report—and we should mention, where can people get that report?

Sheridan: Sure! Actually, if you go to WhiteHatSec.com, right on the main page, there’s a registration form to sign up, get an e-mail, you’ll get a .pdf copy. And it’s great. A lot of the statistics that are found in that report helped us in formulating the recommendations and the security addendum to The Twelve-Factor App.

Just to cite a couple examples—the second factor in The Twelve-Factor App focuses on management of third party dependencies. If you look at our stats report, you’ll see that 21 percent of all the vulnerabilities that we find are a result of vulnerable third party dependencies or components.

And so, that’s sort of a scary stat, and that means that’s something we need to focus on. Well, if you look at the security addendum to The Twelve-Factor App and looking at second factor, there’s guidance of how to manage dependencies, identify those vulnerable third party libraries and dependencies and work through mitigating them.

Another interesting stat that I’ll throw out to your listeners is around services. So, there’s been a pretty substantial migration in development architectures towards micro services. And this is very much in line with the original Twelve-Factor App. In fact, the fourth factor is around this concept of backing services. And what we try to do is get a sense of whether or not micro services are improving the security or degrading the security based on the measurements we can capture.

And we actually found that, if you take 100,000 lines of code of a monolith application and compare it to 100,000 lines of code of a micro service application, the monolith had on average 39 vulnerabilities. The micro service had on average 180 vulnerabilities. So, the number of vulnerabilities that we’re seeing in micro services, for example, is drastically higher. And we have lots of reasoning and thoughts around that that are captured in the stats report. But, to your listeners and to those developers out there that are building and managing micro services, I would recommend checking out the fourth factor in the security addendum to The Twelve-Factor App, which very much talks about strategies and things you can do to reduce the risks when interfacing with third party backing services like a micro service.

Shimel: Agreed. And, you know, Eric, I’m gonna tell you that everything you’re telling me, No. 1, feels right, based upon my own maybe more subjective evaluation, but more importantly, kinda jibes with other studies and surveys that I’ve seen and we’ve done here at DevOps.com and Security Boulevard. So, I don’t think it’s—you know, there’s no reason to doubt any of those things.

You know, the message, though, is one that’s more overarching. You know, at RSA this year, Eric, I think for the fifth year, we’re gonna be doing DevSecOps Days the Monday of RSA Conference week. And every year, we talk about this very similar thing. You know, what are the advantages of shifting security left? What are the advantages of doing security early in the development process, of adding security in there?

And these are the same sorts of numbers that we keep reciting and reciting, and forgive me for soapboxing, but I’d almost come to the conclusion that we need to convince the security people as much as we need to convince the developers of how important this is and why they absolutely, positively must do it.

Sheridan: Yeah, I think that’s a fair observation and is very much consistent with what we’re seeing. And so, you know, if I put my sales and marketing hat on just for a moment—and it’s a very poor hat, by the way—we actively have to communicate this effectively, not only to development teams, but security teams. Development teams are the primary users of the security best practices that we often talk about because they’re building the software. But the folks on the security teams are very much the stewards of security within the organization. They’re the champions. And when these development teams have questions or comments or concerns, they’re gonna go to those security folks for guidance—as well they should, in my opinion.

And a lot of security folks have an opportunity for personal growth, if you will, to explore the security of software, of applications, and what that means for their business. And, from an attacker’s perspective, applications are a very juicy target, and you see that with all of the numbers. Any stats report from any organization is showing that the attacks against applications are consistently rising.

And I think, to your point, there is a need to continue to encourage folks on security teams to look at this with a sharper eye as they’re planning out their security programs. I think there’s a lot of emphasis on sort of classic network security protections, and I don’t dismiss the value of those at all. But I think there’s just more—unfortunately, for the security folks, they have more on their plate now. As the software is getting attacked, they now have to consider the application. It’s not the connections that are actively being attacked, it’s as much as it is the code that developers are writing, and it takes a very different mindset.

Shimel: Agreed, agreed. Eric, okay, so, now we’ve got the security addendum to Twelve-Factor App. What’s next?

Sheridan: I think it’s gonna take some time for organizations to adopt many of the factors in the Twelve-Factor App. But I think what we are seeing is, over time, less resistance from organizations and teams that are shifting towards sort of DevOps related mentalities where the development team and product teams are more open to integrated security earlier in the development process. And the security addendum to The Twelve-Factor App really provides guidance on things that they can do to help with that effort.

But I believe—and actually, I’m seeing this today in general—I believe the biggest challenge that DevOps, cloud computing, agile, all of these things, the biggest challenge that all of these things are presenting is to the security teams. And so, what I’m seeing is an increased demand for extremely fast and extremely accurate security testing so it can be 100 percent automated and integrated within build pipelines, within development pipelines so that developers and product teams only get notified when things break.

Historically, that has not been the mentality of security teams. It’s been very much sort of assessment oriented or pen test oriented or one time standing oriented. And so, the big challenges we’re gonna see and the evolution that we’re gonna see is largely in the security field and the tooling and technologies that are built. But I think if the security teams and the security industry is responsive to that challenge and building up fast, accurate, 100 percent automated solutions that are easy to use, I think we stand a real chance to change some of these statistics that I’ve been throwing out with respect to vulnerabilities and how long they linger. And I also think it’ll help with the resistance that you correctly called out earlier in our conversation.

Shimel: Got it. Hey, Michael, as I mentioned when we started, the time here goes—did I say Michael? I’m in a different world today. [Laughter] I apologize. Eric, time goes so quick here when we started. It’s past 20 minutes already, and we’ve got to call it a wrap on this one.

But you know what? It’s the end of the year. Let’s get this under our belt. Prior to RSA, let’s revisit again in a little deeper dive if we can. Maybe we can pick what you think are the three most important kind of addendums to The Twelve-Factor App and we can just focus in on those two or three of them.

Sheridan: That sounds great, and I appreciate you having me on your podcast, it is an honor, and I look forward to diving deeper with you.

Shimel: Fantastic, Eric. Hey, Eric Sheridan, Chief Scientist for WhiteHat Security, you’re on DevOps Chat. This is Alan Shimel. Thanks for listening, everyone.

Alan Shimel

Avatar photo

Alan Shimel

Throughout his career spanning over 25 years in the IT industry, Alan Shimel has been at the forefront of leading technology change. From hosting and infrastructure, to security and now DevOps, Shimel is an industry leader whose opinions and views are widely sought after.

Alan’s entrepreneurial ventures have seen him found or co-found several technology related companies including TriStar Web, StillSecure, The CISO Group, MediaOps, Inc., DevOps.com and the DevOps Institute. He has also helped several companies grow from startup to public entities and beyond. He has held a variety of executive roles around Business and Corporate Development, Sales, Marketing, Product and Strategy.

Alan is also the founder of the Security Bloggers Network, the Security Bloggers Meetups and awards which run at various Security conferences and Security Boulevard.

Most recently Shimel saw the impact that DevOps and related technologies were going to have on the Software Development Lifecycle and the entire IT stack. He founded DevOps.com and then the DevOps Institute. DevOps.com is the leading destination for all things DevOps, as well as the producers of multiple DevOps events called DevOps Connect. DevOps Connect produces DevSecOps and Rugged DevOps tracks and events at leading security conferences such as RSA Conference, InfoSec Europe and InfoSec World. The DevOps Institute is the leading provider of DevOps education, training and certification.

Alan has a BA in Government and Politics from St Johns University, a JD from New York Law School and a lifetime of business experience. His legal education, long experience in the field, and New York street smarts combine to form a unique personality that is always in demand to appear at conferences and events.

alan has 81 posts and counting.See all posts by alan