One of the reasons we created ThreadFix was that we worked with a lot of organizations that were struggling to manage software vulnerability data from an ever-expanding set of sources:
- Web application scanners
- Static code scanners
- Network scanners
- SaaS providers
- Manual penetration tests
- Threat models
- And so on…
Also we found that different groups were adopting different tools and services so there was vulnerability data coming from different parts of organizations:
- Security teams
- Development teams
- Internal IT audit teams
- External auditors
- And so on…
The net result is that there is a lot of data on software vulnerabilities floating around the organization, but no one has a consolidated view. Vulnerabilities are found by multiple sources and then reported and re-reported to development teams, giving them an excuse to ignore these reports because security is “wasting their time” Lots of one-off Excel spreadsheets get created and lots of swear words get used. Pretty standard situation, but, as an industry, I think we can do better.
Fortunately there are some movements in a positive direction:
- Obviously, as mentioned above, we hope that ThreadFix is a tool organizations will find valuable for addressing these issues. We’re starting to publish information about the different static and dynamic scanners we support as well as the SaaS services (WhiteHat and Veracode) we can import data from. Also we’ve published our internal data model and how we do merging and consolidation. Like what we’ve done? Don’t like what we’ve done? Let us know!
- A while back we published a proposed draft for a Simple Software Vulnerability Language (SSVL). This reflects a lot of the work we had done on ThreadFix and proposes a standard way for static scanners, dynamic scanners and manual test results be communicated in an XML format. It ties everything back to the MITRE CWE. Everyone should be able to view that document – if anyone would like write access to provide comments and updates just email me (dan at denimgroup dot com) with your Google ID and I can set you up.
- The MITRE folks have SAFES (Software Assurance Findings Expression Schema) but there isn’t a lot of public information out there yet.
- The HoneyApps/Risk I/O folks have a SaaS application that also tackles some of these issues.
- OWASP has the OWASP Data Exchange Format project run by Psiinon. This is an even more ambitious project than what has been discussed here because they are looking at communicating information above and beyond vulnerability data including sessions, request/response pairs, web application layout, etc. Check out their Google Code site for more information. We’re hoping we can fold some of the lessons we’ve learned building ThreadFix into their vulnerability data format.
The practice of software security is growing up. Given so many high-profile breaches as well as increasing pressure from their customers I find we spend far less time trying to convince security managers that they need to be concerned about application-level vulnerabilities. Instead, our conversations have shifted to treating these issues in a structured and strategic manner rather than an ad hoc and tactical manner. An important step in making this possible – let alone manageable – will be the creation and adoption of standards.
dan _at_ denimgroup.com