This is the first in a series of blog posts discussing how Denim Group has integrated software security into the ThreadFix development lifecycle and, specifically, how we use ThreadFix in this process. The goal is to shine a light on a “real world” ThreadFix deployment – what works well, what are the challenges, and how can those challenges be resolved. We use a number of different scanning technologies on ThreadFix – static, dynamic, and known-vulnerable-component. We’ve also rolled in the lessons we’ve learned working with those technologies on client engagements into our ThreadFix deployment. We’ve ended up with a real-world deployment of software security technologies and practices that we can actually talk about. These blog posts won’t be a standard white paper where everything is hearts, flowers and unicorns. Instead we see ThreadFix and the supporting technologies both at their best and their worst.
Portfolio: Team Layout
The first decision that needs to be made when rolling out ThreadFix is how to structure the application portfolio. At its most basic level, ThreadFix organizes the world in the context of Applications, representing a unit of deployable and testable code. This will be discussed more below. However before we look at individual applications, ThreadFix allows you to carve your portfolio up into Teams. This is a somewhat arbitrary designation, but provides some structure for making sense of an organization’s application portfolio. The original intention was to group together the folks in an organization who were working on a number of Applications and all using the same practices – agile, waterfall, etc. What we have seen across a number of deployments is that this isn’t a hard-and-fast rule, but does provide a starting point.
At Denim Group we develop ThreadFix, and we also do secure application development for a number of customers. We’re not in a position to talk about these organizations, their applications or the testing activities that are managed via ThreadFix in this series of blog posts, but those live alongside our tracking of ThreadFix inside our ThreadFix installation. For us it made sense to make our product ThreadFix its own “Team” because it consists of nine different deployable and testable software artifacts. Other “Teams” in the Denim Group ThreadFix instance typically represent a specific customer with individual applications housed below. Some customers get multiple Teams when they have a large number of applications under development and that proves to make sense given the way those development teams work together.
Team: Application Layout
So – we have a “Team” named “ThreadFix” inside our ThreadFix installation and that works well. Underneath that we have a collection of different applications. When we started development of ThreadFix there was only one application – the ThreadFix web application. Since then we have developed a number of additional components in the ThreadFix ecosystem such as the command-line interface (CLI), and various plugins for scanners and integrated development environments (IDEs). We often receive the question of what a ThreadFix “Application” should be. There are two answers to this question – one philosophical and one practical:
- Philosophical – This line of thinking says that a ThreadFix application should be a specific, deployable software artifact. Most likely a standalone application, but, in some cases, this might also be a library.
- Practical – This line of thinking says that a ThreadFix application should be whatever codebase (if you are doing SAST) or running application (if you are doing DAST) you target for a single scan.
Usually these end up being the same thing, but sometimes, for really large applications that need to be scanned in pieces, the “Practical” approach has to win out because ThreadFix’s result de-duplication and merging assumes that each scan being uploaded represents a view of the security state of an entire Application.
So when we looked at the current state of ThreadFix (version 2.1), we found that we had nine different “Applications” we needed to track. These are:
- The main ThreadFix web application
- The standard ThreadFix command-line client that wraps the ThreadFix REST API and makes it easy to script common ThreadFix interactions
- Two additional specialized command-line clients
- One that uses ThreadFix’s Hybrid Analysis Mapping technology to analyze an application’s source code and write the application’s attack surface to STDOUT
- One that allows you to manipulate scanner result files
- Two plugins for scanners that allow you to import attack surface information for an application and to export scan results directly into ThreadFix (BurpSuite and OWASP ZAP)
- Two IDE plugins that allow developers to import vulnerability data directly into their development environment (Eclipse and IntelliJ)
- The ThreadFix ScanAgent (available with the Enterprise Edition) that wraps desktop scanners and executes scans at the behest of the ThreadFix Enterprise server.
This seems like a lot of Applications, but it makes sense if you look at the different components of ThreadFix that can be deployed, as well as the different individual components that are subjected to security testing.
Now that we have the different Applications laid out, we can store some additional metadata in the system:
Obviously we have to give the application a name so we know what we’re calling it. Then, optionally, we can enter a URL for where the application is hosted. This only makes sense in the context of web applications. You can also add a “unique ID” entry for an application – this can be used as a key that references any external asset management systems where you might be tracking the same application. The Criticality of the application is important to track as well – how important is this application in the scheme of things? For ThreadFix, the web application is the most critical because it is a server-based application that hosts loads of sensitive data. Other applications associated with ThreadFix aren’t as important because they are client-side applications; don’t handle as much sensitive data and so on. There are other things you can enter as well. We’ll look at how you can provide ThreadFix with a reference to an application’s source code when we look at our use of Hybrid Analysis Mapping. And we’ll look at web application firewall and defect tracker settings in later posts, too. Also the “Disable Vulnerability Merging” option is something you typically want to leave alone because a big part of the value of ThreadFix is automatically cleaning up and de-duping vulnerabilities from various scanners. However some folks have a need to disable this, often, so that every single scanner finding is explicitly addressed, so we provide that option.
We went through the nine applications to configure all the applications and the whole setup looks like this:
Here’s a quick recap of what we did:
- Lay out the different Teams you’ll have in your organization. In our case we have a Team dedicated to the various ThreadFix applications and then teams for other clients.
- Determine the different Applications based on how you are running, or plan to run, your scanning program. Each Application will need to be a unit of testable/scannable code.
- Create your various Applications and enter their metadata. In our case we risk-ranked the various ThreadFix applications and placed a priority on the main web application and the ScanAgent, and gave the other client-side applications a lower rating.
Pretty easy. It takes a little bit of thinking and it forces you to understand a bit about how the software you’re writing will be deployed and how you want to test it, but you really needed to figure that out anyway.
Next up we’ll look at how we deployed OWASP Dependency Check to check the various ThreadFix applications for use of known-vulnerable components.