We recently announced the release of ThreadFix 2.4 which includes our patent-pending HotSpot technology that identifies where internal teams are sharing code among themselves and where that code has vulnerabilities. Similar to what solutions like BlackDuck, Sonatype, and OWASP Dependency Check do for vulnerabilities in known open source components – but for code developed inside your organization. Let’s look at the Why and the How.
HotSpot: The Why
At a macro level, the ThreadFix platform lets organizations manage their application security programs. A huge part of running an effective application security program is making the hard decisions about what vulnerabilities to fix and when. You will never have enough resources to fix everything so you have to be smart about what you do fix. HotSpot helps give you better information about what vulnerabilities might be the most impactful to fix – because if you can fix a vulnerability developed by one team and then have that code make its way down to multiple consuming teams your code-level fix of one vulnerability will result in multiple vulnerabilities being addressed. Identifying opportunities for leverage like this can be critical as you struggle to make progress reducing your risk exposure from application-level vulnerabilities. Knowing that a specific vulnerability is repeated across applications isn’t the only factor that goes into a remediation decision, but having that knowledge provides valuable context.
More specifically, the idea for HotSpot came about the way most great features do – from working with customers addressing challenges in their environments. As part of our consulting practice, we do a lot of work with organizations helping them remediate vulnerabilities identified in their applications. A big part of this is helping organizations roll out static analysis programs (SAST in Gartner-speak). Typically when we help a team get their application put through its first static analysis run, we’ll sit down with team leaders to help characterize the results – working with them to prioritize the findings and provide insight on the most efficient ways to address the issues. What we noticed over time is that we had a lot of conversations that went something like this:
Security Analyst: This one is a very serious vulnerability and you’ll want to get it fixed as soon as possible.
Customer: We can’t fix that. We don’t own that code.
Security Analyst: Could you be more specific?
Customer: We get that code from the [XYZ] team. We can’t change it.
Security Analyst: So I guess we’re going to need to talk to the [XYZ] team…
After we had enough of these conversations we had the idea: Can we proactively identify situations where this type of inter-team code sharing is happening and where the code being shared is responsible for serious vulnerabilities? Because if we could then we could get out in front of these conversations, and, more importantly, we could start to map out how code was flowing within these organizations and identify risky situations where code with vulnerabilities was “infecting” additional applications.
HotSpot: The How
Let’s look at how most enterprise applications are constructed as well as a couple of scenarios where you would find vulnerabilities in those applications:
Most modern enterprise applications don’t solely consist of code specifically written for that application. In fact, most the code probably consists of both open source and commercial libraries and frameworks. In a large enterprise, this code is likely augmented by code developed internal to the organization, but shared across teams and applications. Finally, applications have whatever code is specific to that application.
In Scenario (1) we are looking at a vulnerability where an attack attempting to exploit that vulnerability will enter the application in application-specific code, possibly flow through enterprise-specific components, but the vulnerability data or control flow stops somewhere in a generally-available commercial or open source library or framework. As mentioned above, these are the types of vulnerabilities that are identified by Component Lifecycle Management (CLM) solutions like BlackDuck, Sonatype, and OWASP Dependency Check.
In Scenarios (2) and (3) we are looking at vulnerabilities where an attack would enter the application via the application-specific code, but also where the attack data or control flow also ends within code developed within the organization. These are the types of vulnerabilities typically identified by Static Analysis Security Testing (SAST) tools like Checkmarx or HPE Fortify. The difference between Scenarios (2) and (3) is that in Scenario (2) the team developing the application “owns” or is responsible for all the code reflected in the data or control flow path associated with the vulnerability. Therefore, the application team is in a position to make the necessary changes to remediate the vulnerability.
In Scenario (3), however, we see the situation described above where the bottom end of the data or control flow ends up in code that is “owned” and maintained by another team within the organization. This leads to the remediation issues also described above.
So how can we identify these situations? In ThreadFix, we have access to static analysis results across the various teams and applications within the organization and across the various SAST technologies that might be in use. So – instead of looking at the SAST results for a specific application, we can compare across the entire enterprise and look for commonalities. What we find often looks like this:
Looking through these example data/control flow traces, what we see is that the last four entries are shared between these two vulnerabilities. Doing this type of analysis within the static results for an application can help highlight situations where there may be “chokepoints” that provide opportunities to remediate multiple vulnerabilities by making changes in one specific place. When you perform this analysis across an organization’s portfolio it allows us to identify similar situations where there is an opportunity for remediation leverage, but by looking at associated data such as file names, package names, directory names and the line of code contents, that allows us to potentially identify situations where multiple teams are making use of the same codebases to make up part of their application code.
So that is how HotSpot identifies potential situations where internal code reuse is leading to vulnerabilities spreading throughout an organization’s enterprise-wide codebase. On top of this we do some confidence-scoring and prioritization to make the raw data more valuable when driving remediation decisions, but at its core, this is the technique we’re exploiting.
Contact us to talk about how your organization can use HotSpot and other ThreadFix capabilities to increase the efficiency of your application security program and address more risk, faster.