The slides and recording of yesterday’s “ThreadFix 2.2 Preview” webinar are now online here:
Thanks to all the folks who attended. There were a number of familiar faces (or names, at least) and a lot of new folks as well. Also, there were a number of great questions at the end I had the opportunity to answer. In addition, there were some questions I didn’t have the opportunity fully answer and I wanted to address those here:
- Which reports are only available in ThreadFix Enterprise (vs. ThreadFix Community)? – We looked at a number of reports during the webinar. The reports that are exclusively found in ThreadFix Enterprise Edition are the PCI and HIPAA compliance reports.
- With ThreadFix’s scan orchestration, can the ZAP or Burp scans be restricted to specific paths? – ThreadFix Enterprise’s scan orchestration allows you to store the ZAP and Burp (or whatever scanner) configuration files that act as the basis for the scan. Therefore any configuration or customization the scanner allows you to store in a configuration file should be supported by ThreadFix when scheduling configured scans.
- What are ThreadFix’s capabilities for importing results from traditional vulnerability (network and infrastructure) scanners? – We currently allow imports from Nessus vulnerability scans. If the Nessus plugin has CWE data associated with the scan result, ThreadFix can import them. However, these results are associated with a ThreadFix “Application” rather than with an IP address, as Nessus and other network/infrastructure scanners would typically do. We have looked at adding support for more network/infrastructure scanners like Rapid7 and OpenVAS, but the way that ThreadFix currently manages assets – on an “Application” basis – is different than the way that most network and infrastructure scanners manage assets – on an IP-address or host basis. If we do so in the short term it will likely look like our Nessus support where scan results are associated with an “Application” rather than a specific IP/host. That model seems to work well for a number of ThreadFix users but may not work for everyone. If you have some thoughts in this are please contact us because we would love to talk more.
- Is it possible to export the attack request and response to JIRA? – At the current time the description field for defects created in JIRA – or any defect tracker – is hard-coded with set information and links to MITRE’s CWE information. To create custom defect descriptions you would have to create a custom build with a modified com.denimgroup.threadfix.service.DefectDescriptionBuilder class. We have an open feature request to add the capability for ThreadFix users to set up templates for the issues that ThreadFix creates.
- What are ThreadFix’s capabilities to import JIRA issues? – This is challenging because JIRA issues do not typically track what vulnerability type is associated with the vulnerability in a structured manner and ThreadFix needs to know that to properly track and merge. However, you can associate a vulnerability in ThreadFix with an existing JIRA issue by checking its checkbox (in ThreadFix) and selecting “Merge Defect” from the “Action” menu. In addition, ThreadFix imports of vulnerabilities in the SSVL format can associate a defect tracker issue ID. The CSV2SSVL tool – new in the 2.2 release – can be used to convert CSV and Excel files to SSVL data for upload and that upload data can include JIRA – or other defect tacker – issue IDs.
- What are the plans and timeline for additional IAST integrations? – This will largely be driven by the ThreadFix user base. If you have a specific IAST technology you want integrated, please either submit a GitHub feature request or contact us.
- Which GRC tools does ThreadFix integrate with? – Currently we support integrations with Service Now’s GRC system. If you would like to see support for additional GRC systems – and especially if you are willing to act as a beta/test user – please either submit a GitHub feature request or contact us.
- How does ThreadFix Enterprise “count” applications for licensing? – An “application” in ThreadFix is a unit of scannable, deployable code. So – if you would typically run a SAST or DAST scan of a particular unit of code that would count as an “Application.” Check out this blog post about how we laid out the “applications” for our internal use of ThreadFix to get a real-world perspective on how this works.
- Can development teams be organized in a hierarchal manner? – The “Team” construct in ThreadFix only allows for a single level of hierarchy. For organizations with larger application portfolios this was getting to be a bit limiting, so for the 2.2 release we added the concept of application tagging to allow for more flexible organization of applications in the portfolio. Tags are typically used to identify different application characteristics such as the compliance standards they are required to meet (“PCI” and “HIPAA”), the language they are developed in (“Java” and “C#”) and how they are deployed (“external” and “internal”). However, tags are very flexible and can also be used to create multi-level hierarchies for applications in the portfolio. For example, first-level tags could be created for geographic teams (“Atlanta” and “Bangalore”) and second-level tags could also be also be created (“Atlanta – Point of Sale” and “Atlanta – Mobile Commerce”) This could be continued for third-level, etc tags as well.
- Can the Checkmarx integration roll up multiple Checkmarx project into a single ThreadFix application? – No each Checkmarx project should be associated with an Application inside of ThreadFix. Because of the way the de-duplication and merge process works, each Checkmarx scan uploaded for a given ThreadFix Application will have a diff run against the previous Checkmarx scan to see which vulnerabilities are new, which went away, and which have resurfaced. Trying to upload Checkmarx (or any scanner’s) scans to the same ThreadFix application will make the vulnerability merge and tracking process behave strangely as vulnerabilities get opened and closed based on which scan was uploaded most recently.
- Are there plans to publish a RAML file (raml.org) to document the full features of the API? – There aren’t at the current time because we’ve never actually received a request for one, but we filed a task request in the GitHub issue tracker so we can keep track of the request.
Thanks to everyone who attended the webinar. We’re really excited to get ThreadFix 2.2 released here in the next couple of weeks. Please contact us with any further questions.