I’m about to see if I can set my AppSec career on fire. Jerry Maguire would be proud.
Application securities role has always been seen as an insurance for protecting the company from financial loss. The result of this has been some mix of self depreciating and self defeating set of phrases that have reared its ugly head.
Here are some of the worst offenders:
- Keep The Company Off the Front Page
Fear is a great persuasion. The problem is that the fear turned out to be unwarranted. There is a security breach so frequently that society is practically numb to it. The impact to nearly all of the companies is zero once the short term passes. There are rare exceptions where longer term impacts are felt. For the most part, those are only — security companies. - Security is Non-Functional
There is this notion that some how security isn’t a function of the business. And while pedantically correct, security is part of all functions. There is no fundamental difference between a UI color being wrong and some third party library vulnerability that is deemed unreachable. Put simply, security is a requirement that has a priority based on business need. Nothing more, nothing less. - Security is a Burden On Developers
In general practice, securing software is not hard. There are plenty of recommendations, guidelines, and tutorials on how to build secure software for the significant majority of use cases. I’ve worked in numerous companies and I can tell you the bulk of the threat models would be the same. What makes security hard is the non-software related factors. The relationships between those involved in the creation of the software, the desire to build with new technology to keep up or remain on old technology for fear of breaking what works, and the stories we tell ourselves about software. - Focusing on Negatives of Security Testing Strategies
Static Analysis vendors trash Dynamic testing tools. Source Composition claiming to be the best. Interactive testing tools saying the others are out dated. Threat modeling tools saying they will solve most problems. Each testing strategy has its place and its purpose. They all have their strengths and weaknesses. - Security is a Speed Bump
Security is as much of a speed bump as functional testing. It simply isn’t. When done within the confines of an engineering practice, security is an accelerator. It forces thought. Imagine trying to build a house room by room without considering structure and safety. You can’t do it. Some will argue software doesn’t need to be that. And the counter to that is – have you seen the tech debt of most projects and products? - False Positives Are A Negative
False positives are typically defined as a finding which when investigated turns out to be incorrect. An example is that static analysis would alert on hard coded passwords. A lot of times these would be found by looking for some form of the word password. This turned out to be names of variables for user interface elements. This is not a good thing. However, most of the time, there would be one or two cases in this which were hard coded passwords and sometimes it was ones that were not a standard form password from that many tools look for today. In order to push the boundaries of finding security issues, it is necessary to have rules which will not be 100% accurate. There’s a balance between false negatives and false positives and most testing tools have different context where that balance will vary. - Reachability and Exploitability
Reachability and exploitability describes the potential for a vulnerability to be reachable in code and a known exploit exist. The justification is that if a vulnerability is not reachable and not exploitable, then addressing it can be ignored in total or at the very least deprioritized. This argument ignores the that a fix could be as easy as upgrading the library. It discounts the technical debt which can grow as the library usage increases, potentially to the point where the vulnerability is reachable and remediation isn’t realistically possible. It assumes that the scanner is correct in analyzing the code and there is an awareness of an exploit. Lastly, it discounts what happens when an exploit is discovered. - Security is Expensive – There is a cost to security. There’s also a cost to quality assurance. There’s a cost to building software. This argument is a straw man. There’s a cost to everything. The reality is, security is an investment. This is similar to the speed bump discussion. When the engineering process is improved, the total cost of production goes down.
- Developers Do Not Know How To Secure Things – Every professional needs to stay up to date. That’s why continuing education exists. Even the best home contractors take time away from work to learn newer techniques. There is a difference between how this is communicated versus the software security style. This line of communication tends to be condescending. The condescending attitude toward developers is just extreme.
- Focusing on risk – Nearly all prioritization is driven by risk. Risk is important to a degree. The hyper focus on risk, however, can lead to significant opportunity costs. This can include improving the overall security posture and even real time developer training. The focus on vulnerabilities and risk of those vulnerabilities rather than the root cause of why those vulnerabilities exist.
Software security professionals need to get out of the mode of being enablers of bad software development practices. Whether this is driven by the notion that exploits and vulnerabilities sell products or services or whether its because of the fear product teams will ignore them. Sometimes, tough love is needed in conjunction with empathy.
Developers want to use the latest and greatest technology. Architects want to show they can build applications using the latest and greatest techniques.
The messaging needs to change. Investing in software security and builds better engineering practices. Better engineering practices build higher quality software. Here’s some examples of better messaging:
- Security Lowers The Cost Of Production – Implementing security requires thought. It requires planning. That planning uncovers gaps and issues and addresses them much earlier than if they are uncovered later.
- Software Security Improves the SDLC – Finding vulnerabilities gives the team an opportunity to find out where there things were missed. Make no mistake, things will always get missed. The goal of the software security program is to make improvements in the SDLC when those things do get missed.
- Software Security Builds Customer Trust – Similar with cars and home contractors. Even younger generations don’t want to share their data (https://www.aclu.org/news/privacy-technology/do-young-people-care-about-privacy).
- Software Engineers Need Continuing Education – This slight tweak changes the perception. Nearly all professions use continuing education as a way to improve. This is a significant difference in framing.
- A Comprehensive Program Leads To Success – Each security testing tool has a place and an importance to it. There is no single answer. We need to promote other testing strategies. At the end of the day, baby steps is better than no steps and not everyone is going to be aware of all the possible tools out there.
There are many factors in why software security struggles. Developers have a motivation to use the latest and greatest frameworks. Architects have the motivation to build software using the most up to date architecture patterns and technology. Sometimes these aren’t needed. And sometimes the ability to test these for security flaws is challenging.
The capabilities of software generation tools are getting significantly better. This makes even keeping up with testing software for security vulnerabilities a challenge.
It’s time for Application Security to work together to build better programs.