April 3, 2023

Last Updated on January 12, 2024

When you’re getting serious about improving application security within and around your software development lifecycle (SDLC), one of the first things you really need is executive buy-in. The people who control staffing and budgets must understand not just the business need for application security—but also the business risks if applications are vulnerable to cyber-attack.

Not all execs are aware of the considerable risks inherent in application development.

“There are things that developers can do that can be very, very dangerous,” says André Keartland, Solutions Architect at Netsurit. “Like, if you’re using some library that was recommended by a buddy or that you found with a search engine, is that secure? Is there possibly malware or back doors or something similar that are enabled through that?”

Enter threat modeling
This is where practices like threat modeling come in handy. What do we need to protect ourselves against? What are the realistic, prioritized risks with this application? What are the things that could be going wrong? Finding the answers takes research and possibly expert advice. There are also formal threat modeling processes and recommendations available, as well as tools and frameworks teams can use.

“Diversity of opinion is probably your best friend,” André shares. “So don’t ask the developers what they think are the risks. Don’t ask the project stakeholder, or even your InfoSec guy. Talk to black hats, talk to penetration testers, talk to other organizations that run similar types of software. Start understanding, what are the application-specific risks?”

 

Unique factors to consider

When it comes to application security risk, every organization is different and there are many factors to consider.

Choices that fundamentally change your risk include: Are you developing your own code from scratch? Starting with an existing app that needs porting to the cloud? Deploying software written by someone else? Are you customizing code written by someone else? Will the app be used in a compute constrained environment like an IoT device?

Other considerations include: Are you beholden to a specific security tools vendor or do you have a best-of-breed strategy? Is your budget adequate or tight? Do you have any team members who know security? How standardized is your DevOps pipeline? Do you know what third-party libraries are in your code, or is that a mystery?

At the end of the day, is there any way to reduce this complexity and standardize your application security risk analysis so you know you’ve touched all the bases?

“I’m essentially a consultant, so the answer I’ll give is always going to be, ‘It depends,’ laughs André.

 

What’s next?

For more guidance on this topic, listen to Episode 114 of The Virtual CISO Podcast with guest André Keartland from Netsurit.

Free OWASP ASVS Testing Guide

If you are just learning about OWASP’s testing standard or are considering the best way to prove the security of an application, this guide is meant for you!