We first released ThreadFix in September of 2012 and recently followed up with the updated 1.1 version based on user and community feedback. Along the way we’ve had the opportunity to talk with all sorts of people and organizations about their challenges managing software risk and where they most need help. Even before that, for over a decade at Denim Group we’ve worked with a huge variety of organizations both large and small across industries so we get to see a lot of people dealing with problems as well as what works and what doesn’t work dealing with those problems.
The biggest problem we saw across all these constituents was that they didn’t feel like they had control over their software risk. All of them were undertaking various assurance activities – scanning applications and code, running penetration tests, doing threat modeling – but very few organizations were able to do a good job of tracking the results of all these activities and, more importantly, driving the changes in their organizations required to address the issues they were uncovering.
So we built ThreadFix to help these organizations manage their software security programs – to let them centralize the results of all these assurance activities, to track the data being kicked out by these activities and to help security teams get the vulnerabilities and weaknesses they identify resolved.
We saw two common scenarios of folks who really stood to benefit from what ultimately became ThreadFix:
- Software security teams in smaller organizations that needed to move their programs from being qualitatively driven (“Cross-site scripting is bad”) to being quantitatively driven (“It takes us longer to fix cross-site scripting compared to peer organizations”)
- Software security teams in larger organizations who have to deal with an overwhelming number of teams and applications as well as results coming from many different vendors’ tools.
For teams in smaller organization we saw a lot of what we’ve come to call the “dude with a scanner” pattern (note this can also be a “lady with a scanner”) The characteristics of this situation are that an organization finally realizes that they have a problem with application security so they license a desktop-based scanner for their application security analyst and consider the problem solved. Unfortunately this is the start of the journey – not the end. Desktop scanners give you a view of the security state of a single application at a specific point in time. That’s great, except most organizations – even small organization – have multiple applications. And sometimes many applications. And the security state of these applications change over time. Just because you buy a scanner doesn’t mean that you have a scanning program.
dan _at_ denimgroup.com