By Carsten Eiram
Naturally, the answer is: Yes! However, I recently participated in a discussion, which made it clear to me that even though Secunia provides the world's most accurate Vulnerability Intelligence and is great at setting the bar high in many areas, then there is one area where we can do better: Making the value of our free, publicly available vulnerability database clear.
Obviously, it doesn't matter that my team provides a lot of unique value that cannot be found elsewhere if we are not capable of properly communicating this value. Fortunately, it seems our primary target audience (i.e. organisations purchasing our commercial solutions) have a solid understanding, but after all these years it seems that some in the secondary target audience (e.g. software vendors) still do not fully understand the value of our VDB, instead believing that Secunia is just regurgitating vulnerability reports.
Hopefully, this blog will make the great and very unique value of Secunia's free, publicly available vulnerability database (VDB) clear to everyone in the community whether you are a security researcher, software vendor, penetration tester, or work in any other field of this industry where qualified Vulnerability Intelligence is key.
In order to understand the value of Secunia's VDB, I will share some information about the workflow in our advisories team and our policies. Each day our robots catch thousands of new, potentially vulnerability-related data from a wide variety of sources. On top of that we receive a lot of direct vulnerability reports to firstname.lastname@example.org. This information trickles in (sometimes it comes in a flood) all day. The initial step is removing all the obvious noise after which everything else is assigned to the security specialists' pipelines. It is then the responsibility of each security specialist to assess whether the information in the assigned pipeline pertains to potentially new vulnerabilities and whether or not the sources can be considered trusted (e.g. a software vendor reporting a vulnerability in their own product).
If a source is trusted and there is sufficient information, we can go ahead and update an existing advisory or release a new one. If not, the security specialist has to confirm the report by installing and testing the reportedly vulnerable software. This process can include everything from running a provided PoC against a vulnerable version of the product or reproduce the vulnerability based on details in the report to comparing a patch against the vulnerable open source code or closed source binary. During this testing phase, we often uncover various inconsistencies in the reports (e.g. incorrect reported impact or vulnerability type) or additional attack vectors, affected versions, workarounds, or available fixes. Often we also discover additional vulnerabilities. A very large number of the vulnerability reports you see out there either lack crucial information or are flawed to a lesser or larger extent if not completely wrong.
For these reasons, we sometimes also reach out to the researcher and/or software vendor with additional questions, allowing each party to provide comments. This may e.g. give a software vendor a chance to become aware of an uncoordinated vulnerability report and provide details on available workarounds or patch schedule. Similarly, it may give a reporter a chance to elaborate more on their discovery, clarify on affected/tested versions, or describe certain setup requirements in order to confirm the reported vulnerability.
Once an advisory is published, the more interesting advisories (i.e. describing critical vulnerabilities in popular products) are scheduled for extended analysis. This also includes advisories written based on a software vendor's own report in order to obtain more details about the fixed vulnerability and efficiency of the fix. Similar to our testing process, this also uncovers additional details about the vulnerability in general and e.g. discovery of silently fixed vulnerabilities, incomplete fixes, greater exploitation risk, and additional attack vectors. Additional details uncovered during the extended analysis process are primarily provided to customers only via the commercial advisories, but often some of these details are also added to our publicly available advisories.
This whole elaborate process is certainly not the simplest approach to provide a VDB, but it is the best approach to ensure that we provide the most accurate and reliable Vulnerability Intelligence – both to customers and the community. Following this approach we ensure that advisories in the Secunia VDB:
- Contain the most accurate details and impact/rating
- Are continuously updated with additional details, available fixes, and assigned CVEs
- Are not duplicates of existing advisories
- Do not describe fake vulnerability reports
- Do not incorrectly list multiple attack vectors to the same vulnerability as different vulnerabilities … and much more!
Furthermore, many published advisories are not based on other public vulnerability reports; Secunia's VDB is very uniquely the original source of many vulnerability reports. Each year Secunia discovers a large number of vulnerabilities either during the verification process when handling vulnerability reports, the post-advisory extended analysis process, or when a Secunia Research team member specifically decides to audit a particular application.
For the past many years Secunia has also offered to assist researchers in coordinating their discoveries and provide them with an independent 3rd party that double-checks their findings. Each year Secunia coordinates a large number of vulnerabilities and expect this effort to grow in the coming years.
I hope this blog makes the value of Secunia's VDB more clear. If you have any questions or feedback about the value of our vulnerability database then please do not hesitate to contact sales@ (if your interest is commercial) or support@ (if your interest is from a community-perspective).
Chief Security Specialist