LASCON 2015 was last week and, as always, it was a great conference. Friday I had the opportunity to give a talk about the ThreadFix Ecosystem. It looks through a number of organizations we’ve had the opportunity to work with as we’ve developed ThreadFix and highlights the contributions of a number of the firms and individuals who have helped make ThreadFix successful.
Slides are online here:
Abstract: ThreadFix is an open source application vulnerability management system that helps automate many common application security tasks and integrate security and development tools. This presentation looks at the components of the platform and how they work together to help developers and application security analysts build more secure software. In addition to being a platform, ThreadFix is also an ecosystem of users and volunteers and the presentation will look at several case studies of how these groups have worked together to extend and improve the ThreadFix platform.
There was a great question during the presentation from Kate Brew about what sort of evaluation was applied to code contributions to ThreadFix. My response was:
- For any code we accept into the mainline ThreadFix codebase, we have to have a signed contributor agreement on file. It basically says that we will include accepted contributions in the open source ThreadFix Community Edition codebase, but that we can also license the code in other ways at our discretion. This is a bit of a hassle and we apologize, but it allows us to do things like release ThreadFix Enterprise Edition that funds the majority of the development work. This is similar to projects like OpenStack and MySQL (actually our contributor agreement is just MySQL’s contributor agreement with “MySQL” replaced by “Denim Group”)
- If someone is considering developing a feature for contribution, it is a good idea to get in touch with us so we can help make the process as easy and productive as possible. We want to do whatever is possible to make sure we can include the feature as-contributed so we can provide information about what the ThreadFix architecture and coding standards look like, help make sure that the feature is generic enough for inclusion in the mainline codebase, and identify situations where we might already have similar capabilities in development. The situation we want to avoid is one where someone does a lot of work and then sends us code that we can’t include for one reason or another.
- The best way to make the actual contributions is as GitHub pull requests. Then we can review the contribution and pull it into the mainline dev branch.
- After that the new feature(s) flow into our standard QA and testing procedures.