ThreadFix 2.2 Preview Webinar – Slides and Recording Online

threadfix

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.

About Dan Cornell

A globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application vulnerability management platform.
More Posts by Dan Cornell

2 Responses to “ThreadFix 2.2 Preview Webinar – Slides and Recording Online”

  1. Vasu

    Hi,

    Can Threadfix pull the data from Fortify SSC server directly, instead of uploading the FPR file on the Threadfix UI?

    Thanks in advance.

    Regards.

  2. Dan Cornell

    Currently it can only upload FPR files. We are looking at adding support for Fortify SSC – and Fortify on Demand – as “Remote Providers” where we can pull vulnerability data over the network. This is how we can work with Veracode, WhiteHat, AppScan Enterprise and others. Just need to extend that to Fortify SSC.

Leave a Reply

Your email address will not be published. Required fields are marked *