Day 0 was Day 1 of Development
A recent study from Columbia University found that we’re bogged down by more than 70 decisions a day. That's if you only count the important ones, as previous research from Cornell University determined that we make over 200 decisions just regarding food in any given day.
Many of the decisions we make in a day are inconsequential in the long term. The impact is minimal, and most cannot be categorized as "good" or "bad". They are merely the choice we made. But some choices have significant consequences. Some are intentional and made with forethought. Others are unintended and only become obvious with hindsight.
Some unintended consequences that seems obvious with hindsight relate to the security of our applications.
CHOICES: PLATFORMS, FRAMEWORKS, and COMPONENTS
From the first day of development, choices are being made. Many of those choices revolve around platforms and frameworks, libraries and third-party components. There are a lot of these choices made during development. It is estimated today that 80-90% of an application is comprised from open/third-party source components. Each of the choices that leads to the inclusion of an open/third-party sourced component has potential consequences, particularly with respect to application security. Black Duck Software's analysis claims an average of 105 open source components per commercial software offering.
Those consequences, on the surface, are not that terrifying. After all, research from Contrast Security finds that software libraries represent just 7% of vulnerabilities. Black Duck found an average 22.5 open source vulnerabilities per application. Forty percent (40%) of those vulnerabilities were rated as 'severe.' Still, that's minimal considering the remaining 10-20% of an application - custom code - is responsible for most of the vulnerabilities in applications.
Unfortunately, the bulk of vulnerabilities aren't disclosed via CVEs and sample exploit code made easily accessible to attackers. Bad actors need not work that hard to find targets in an environment where the same components and libraries are often in use by thousands upon thousands of web applications. Right now, builtwith.com - which tracks the use of technology used to build apps and websites - counts nearly 40,000 live sites that rely on Apache Struts. Most of us are aware of the successful exploitation of published vulnerabilities in Apache Struts 2 that led to a mild panic on the Internet. Similar panics have been caused by serious vulnerability disclosures involving other heavily used open source and third-party libraries, such as OpenSSL.
But it's not just the choice of whether we include libraries or third-party components or build apps on open source frameworks that's potentially problematic. Other choices we make during development can also have serious repercussions, particularly when they lead to insecure development practices.
CHOICES: TRADING SECURITY for SPEED
It is never a surprise to hear that security has been traded for speed. It has always been the case. A 2014 McAfee survey of 504 security professionals found that "roughly a third of organizations surveyed, operators admitted that they attempt to increase network performance by routinely disabling firewall security features."
Development, it turns out, is no different. Their focus is not on execution speed, but on pipeline speed. To meet demands for more timely releases of applications and updates to the market, many admit to skipping security during development entirely. A 2017 Arxan | IBM survey of mobile and IoT developers discovered that 26% of respondents do not test mobile apps at all for security issues, and nearly half (48%) do not test IoT apps. Pressure to deliver was cited by 69% as the reason security is often skipped.
A poll of attendees at our customer event, Agility, this summer reinforced this is reality. Over half - 62% - admitted they had traded security for speed in their organization.
And then there are the choices made regarding how organizations address discovered vulnerabilities. Black Duck's analysis revealed that 10% of applications scanned in 2018 were still vulnerable to the 2014 Heartbleed vulnerability. A ServiceNow study conducted by Ponemon found a disturbing 57% of breach victims disclosed they could have prevented the breach by installing an available patch.
CHOICES HAVE CONSEQUENCES
From day one of development to post-deployment, the choices we make regarding the security of the entire application stack are important. These choices aren't on par with having a burger or salad for lunch; they are decisions whose ramifications can reverberate not just through IT and the business, but to customers that rely on app providers' taking security seriously.
There are very few of us who can claim to have never received a "Dear App User" letter informing us that our data has been exposed. That isn't a license to be lax with security; on the contrary, we should all endeavor to do better by our customers in safeguarding personal, private information.
The best way to do that is to recognize that every choice from day one of development is an opportunity to improve the security of the applications we develop. Choose consciously and wisely.