Identifying and resolving software vulnerabilities: A balancing act

Leading a software security group (SSG) is a balancing act. Most decisions come down to how to apply an extremely limited amount of resources to what seems like an insurmountable problem. To give you an example, a question I have been asked in past roles, and continue to hear from clients today is: "Is it better to go looking for new vulnerabilities or to fix the ones we already know about?" In other words, how should priorities line up between the remediation of issues and the expansion and management of defect discovery?

Take off your security blinders.

One of the scariest arguments I've heard is that if a vulnerability isn't discovered, it somehow generates less security liability than an issue that has been discovered and isn't resolved—and is eventually exploited. This is an argument for putting on blinders and running into whatever is waiting ahead. There is certainly a need for a solid risk-based approach when it comes to remediating known issues. This includes a strategy for applying those limited resources and resolving the riskiest security issues. However, don't blind yourself from the issues leaving your software vulnerable.

Be proactive about security.

Coming across organization after organization that assumes this "ignorance is bliss" approach has helped me arrive at the following conclusions:

• It’s best to have different people working these problems.
• A vulnerability you know about and choose not to fix is not as scary as the risks you don’t know about.
• Healthy remediation programs are focused on providing systemic solutions to systemic problems, not running down a list of issues one at a time.

One way to address this problem is by choosing a specialization approach. This means having different resources aligned to defect discovery than those aligned with defect remediation. A divide and conquer approach tends to work quite well. In most cases that I've come across, the traits of an engineer who is best at finding issues don’t align with the engineer who’s best at fixing issues.

Make widespread improvements.

Remediation programs need leaders who can stay organized, gather support from stakeholders and system owners, and above all, prioritize efforts. This leads me to the best way to actually fix things. That doesn't mean running down a list of known vulnerabilities and demanding individual remediation plans. It means finding ways to avoid the risk in the first place. Think about the known vulnerabilities by class of issue versus the individual instance. This helps a remediation team to make more widespread improvements like fixing an existing—or implementing a new—framework to avoid cross-site scripting (XSS) or cross-site request forgery (CSRF) issues. Quite simply, systemic issues require systemic solutions.

Prioritize your remediation.

What do you do when you still have too many issues and not enough time to dig your way out of that remediation hole? If forced into a decision to identify and fix vulnerabilities, take a risk-based approach to tooling and prioritizing the highest priority issues first. For example, you may be focusing on a high-risk threat perspective such as that of an external attacker. In doing so, your focus is exhausting all potential issues through that lens. You can also potentially tune your testing tools to high and critical risks first. With tools executing the highest priorities first, you gain broader coverage—albeit losing information on medium and low risks.