Contrast customer Derek Fisher on how to empower dev & security teams

Derek Fisher — author of the newly published, acclaimed Application Security Program Handbook: A guide for software engineers and team leaders — is an award-winning author, speaker, leader and university instructor who’s built high-performing cybersecurity teams in a diverse range of technology fields. Fisher currently works in product security at a leading financial technology company. 

His teams’ mission: to ensure that internally developed applications — the kind of apps that are core to the organization’s business and hence pose a significant risk to the organization’s function — are developed in a secure manner. 

We’re talking about a whole lot of moving parts: His security and development departments comprise around 100 scrum teams and span multiple business units with several products, and each product has several pipelines and development life cycles. His current security team is probably one of the largest private security teams he’s ever managed, and he describes it as “very, very busy on a daily basis.”

We need to add a “for now” to that current mission. As it is, the teams have a load of financial touch points within their applications, but it’s just going to intensify as security and development start to  branch out into additional areas. 

Fisher recently joined Contrast Security Chief Technology Officer and co-founder Jeff Williams in a customer fireside chat to discuss how his teams are using Contrast technology to get their hands around this burgeoning need to secure ever more applications. What follows are some highlights from their discussion; please note that these are his own opinions and don't represent his company’s views. 

Avoiding bottlenecks

There are a number of challenges when it comes to being ready for the brave new world of modern apps, Fisher said. After all, no security team can be everywhere all the time, all at once. “We have to rely on, No. 1, our tooling,” he said. “But we also have to rely on being able to build a security mindset into our engineering processes. … Product security, application security — we're good at being able to stand up tools, to find vulnerabilities and throw them at development teams.” 

His teams know how to do that: They’ve been at it for a long time. The question is how to identify vulnerabilities that are truly exploitable and how to really give developers the ability to identify their own vulnerabilities and be able to resolve those vulnerabilities: it’s  “where I believe we really need to shift,” Fisher said. “Is it empowering the development teams to do this job for themselves? Rather than run it through a central [Application Security (AppSec)] team that kind of becomes a bottleneck — is that kind of the philosophy there?

“We have to be able to give the developers the tools to be able to identify those issues and [resolve] them on their own.”

No more Ministry of ‘No!’

One of the biggest challenges in AppSec is to get rid of security’s historical definition as “the people who say ‘No,’” Fisher said. Instead, security needs to be in a different position — the position of saying ‘Yes,’ and “to empower the developers to develop code in such a way that they feel that security is not something that they have to be concerned about. … It's there. It's baked in. It's part of the ingredients.”

So, if security isn’t the gatekeeper or guards, how do you interact with developers? As coaches? As toolsmiths? 

What Fisher’s teams have typically done is to embed somebody in the scrum teams. Unfortunately, that approach entails a lot of champions, and it just doesn’t scale. Instead, he’s trying to view the relationship as one in which AppSec is provided as a service, or where security ensures that the tools are available for the development team to use. 

Shift left vs. shift smart

Fisher’s team doesn’t just focus on pre-production, though. They also need to understand what’s going on, security-wise, in production. Hence, he and his teams also concentrate on runtime protection, including running a Web Application Firewall (WAF), vulnerability management, and some threat intelligence that helps them to stay ahead of new threats and to determine what those threats mean for products: insight they can then feed back into development.

That brings us to shift left, as in, the concept of moving security earlier in the development life cycle, into development, so as to discover vulnerabilities sooner. The idea has seen a good deal of blowback, given that shifting too far left can lead to loss of context, lots of false positives and other bad results. That’s why Contrast has been pushing away from shift left and more toward a “shift smart” strategy. 

Fisher is on board with the shift-smart evolution. 

“Take static analysis — like, the whipping boy of shifting left, right? … You integrate a [software as a service, or SaaS] tool, you find a lot of vulnerabilities,” he said. “It's noisy. … There's no context. It's not in a running environment. The SaaS tool’s flagging vulnerabilities that are just not vulnerabilities. And you spend most of your time trying to weed out the false positives. That's not a good use of time.” 

One of the things that Fisher said he’s really tried to focus on in the past few years is building product security, as opposed to application security, for the full Software Development Life Cycle (SDLC). “We don't integrate [Static Application Security Testing, or SAST] and then throw reports at development and say, ‘Go fix these’ and never talk to them again. We want to make sure that we have [an SDLC] that is robust and is able to identify findings throughout the life cycle. But more importantly, understand which one of these are actually exploitable, which one of these are actually a risk to the organization, so that we can put our focus in the right place.”

Have a listen to the fireside chat to find out more about: 

• The metrics Fisher and his teams are using to figure out which of their practices are leading to improved outcomes,
• How they’re dealing with securing open-source libraries,
• The value they’re seeing from runtime protection, and
• Fisher’s recommendations for people building web apps and web application programming interfaces (APIs) around runtime protection.