Managing Application Vulnerabilities Manually?

How to Identify That you Have a Problem

In spite of the fact that automation and application vulnerability resolution platforms like ThreadFix® have existed for a decent length of time, we continue to see organizations that try to muscle ahead with their existing manual processes. We continue to be surprised that organizations manage their application vulnerabilities through brute force and sheer organizational momentum. The results speak for themselves – time to resolve application vulnerabilities remains measured in weeks and months, not in hours or days.

Call it status quo bias, call it what you may, but many organizations remain stuck in the world of manually managing vulnerabilities. Yes, the first step to recovery is acknowledging you have a problem. But in order to acknowledge that you have a problem, you need to know what legacy vulnerability management looks like. If your current state of affairs includes the following, you are likely needing to take a fresh look at how you manage your application vulnerabilities.

1. You Have the World’s. Largest. Spreadsheet. Excel product managers in Redmond would have been astonished by how your organization has pushed their desktop spreadsheet application to the limits of its capabilities. If you have a ginormous spreadsheet managing the application vulnerabilities of your ginormous organization, then you are likely burning corporate resources on a spreadsheet that is the polar opposite of scalable.
2. Your Spreadsheet has a Team. Not a person, but a team. This team is doing nothing but populating the world’s largest spreadsheet. If that team numbers in double digits, you are trying to do manually what automation does by definition.
3. Your Team Spends More Time Munging Than Analyzing. You’ve put together an “A-Team” of crack application security experts only to relegate them to data munging hell. If tons of time and energy is spent by your team just to get common vulnerabilities in a central console to make comparative risk decisions, then you have a problem.
4. Scanner API Changes Break Your Hardcoded Integrations. Your team – when not manually munging individual application vulnerabilities – has been able to hard code one or more of your scanners to issues trackers or, better yet, the world’s largest spreadsheet. Of course, then your vulnerability scanning vendor changes their API because they enjoy randomly doing that to keep things interesting. Suddenly, your “integration” no longer works, which is bad because the guy who wrote it left two years ago.
5. You Are Unable to Automate Vulnerability Remediation. Because your application vulnerability spreadsheet lives in isolation, never to be connected with another system, you cannot automate vulnerabilities you identify. As a result, you fall back to PDFs (see below) and other “out of band” means to send on the most critical vulnerabilities to your dev teams via – you guessed it – email.
6. Your Application Vulnerability Spreadsheet is Unconnected (and Unconnectable) to Your CI/CD Pipeline. If you are keeping track of application vulnerabilities in spreadsheets, it’s hard to instrument a spreadsheet in the CI/CD pipeline. See the above observation on remediation and your program living in isolation.
7. PDF Reports Still Exist in Your Organization. As from a bygone era, lengthy consultant reports (in full disclosure, we still write lengthy consultant reports for those that want them…) epitomize the challenge of putting unstructured data to work within an organization. If you see security assessment reports or penetration reports in your email inbox on a frequent basis, you should consider a change.  

 If you read this article and said “yup, that’s us” quietly under your breath, then you have begun a remediation journey by admitting you have a problem. Automation in the form of application vulnerability resolution platforms like ThreadFix help solve an otherwise thorny problem. Contact us and let’s see how we can help.