Vulnerability Disclosure: Find the Bugs in Your Code Before the Hackers Do
Table of Contents
Everyone deals with vulnerabilities but the question is how do you handle the situation after the news comes out?
It’s been nearly a year since news of the Equifax breach broke and the now-notorious top credit rating outfit began providing troubling details about the record breaking breach to their databases.
Whose vulnerability is it anyway?
At first Equifax attempted to shift the blame onto the Apache Foundation’s open source software framework, trying to persuade the public that the fault lay with a vulnerability (CVE-2017-5638) in an open source component.
However, it’s hard to deflect when the Apache Foundation publicly disclosed the vulnerability in early March 2017, and published a fix for it the same day, over two months before the Equifax data bases were hacked. That means that Equifax didn’t patch the known vulnerability when it was disclosed.
Equifax wasn’t alone. While nobody wants the software that they use — or the software they sell — to house risky components, most aren’t familiar with the ins and outs of vulnerability disclosure policies unless it’s part of their job. If there’s one thing that the record-breaking Equifax breach taught us, it’s that many still don’t know what to do about third-party software vulnerabilities once they are disclosed. Hackers, on the other hand, are extremely proficient in exploiting known vulnerabilities in the open source web applications that so many organizations use in their code.
Hopefully this is a wakeup call for organizations to be on top of the third-party and open source software components that they use, and keep an eye out for known disclosed software vulnerabilities.
What is vulnerability disclosure?
Though some of the details vary, a vulnerability disclosure policy is a straightforward process that ends with a vulnerability being remediated and made public.
There are many professionals out there these days searching for security vulnerabilities in software, or researching fixes for them. These may be in-house security analysts, security research firms, or the increasingly popular bug bounty hunters.
When a security researcher finds an issue, they first contact the project owner: This could be the software vendor or the project manager of an open source project. They might also notify the MITRE organization, a security advisory that will also vet the report, give it a unique ID, and add it to the CVE list.
The owner of the vulnerable software is given a grace period of between 45-90 days to come up with a fix to the vulnerability and make it public. Once a fix is found, or if the grace period is over and no remediation was offered, the full information regarding the vulnerability is released, usually along with a remediation path.
This information is then recorded in the National Vulnerability Database – or NVD, which will test the vulnerability to check how exploitable it is and come back with a vulnerability score within a few days.
Though most of us are familiar with a handful of notorious vulnerabilities that made headlines, few of us realize that there are 5000 vulnerabilities published every year.
To catch a fix
The application security ecosystem has been evolving at a hectic pace. Today there are many security researchers and analysts, and nearly as many databases and platforms documenting data about the many vulnerabilities that are found in the wild.
Both the NVD and the CVE are public databases where software teams can find known vulnerabilities, their details, and their fixes. Known vulnerabilities can also be found in various vulnerability databases, advisories and bug trackers — sometimes months before they are published in the NVD.
So how do developers know if applications contain a known vulnerability, and how to fix it?
Where can they find these disclosed vulnerabilities and their fixes once they are published?
How to win at application security
It’s time to face the facts: your software contains disclosed vulnerabilities and bugs. Organizations choosing to ignore this reality put their systems and applications at risk of attack.
Currently, there is no one central location to learn about the quality or security level of a third-party or open source component, let alone how to remediate it.
The only way to win at the application security game is to use an automated Software Composition Analysis solution throughout the software development lifecycle that aggregates all the various vulnerability databases and advisories, while continuously tracking your system and its applications.
