Runtime Agent Analysis

[stevespringett]

Add the new component (possibly a different but related project) that uses runtime agent technology (.NET, Java, Node.js) that inspects what components are actually invoked during runtime .

The runtime agent should be able to output a report of all components that were loaded and/or invoked during runtime and whether or not DC found any known vulnerabilities in them. This is similar to how the agent works in Code Pulse. However, I'd also like the agent to perform delta analysis by looking at the components that are actually used verses the components that were resolved during compilation and packaged with the application.

Recently, Contrast Security performed research using Apache Commons HTTP Client v3.1 with real-world applications and component dependencies that use it. They discovered that over 5,700 components use commons-httpclient-3.1.jar, a component that has known vulnerabilities. But their tests went further to look at real-world applications and their supposed use of third-party components. Their findings indicate:

• 78% of libraries are never even loaded. They’re dependencies of some other library that you’re using.
• 7.7% of the libraries deployed are actually used

Dependency management features in Maven and similar build systems are primitive at best and their results should be questioned by security teams. These build systems can also unnecessarily increase an applications attack surface. It's a large undertaking for teams to consistently update every component they ship, especially when statistically speaking, they are likely not using a lot of the components they've packaged.

Besides providing visibility into the components that are used (and unused) it could be used as a way to reduce the attack surface of an application. A common scenario I see is:

• Application depends on Component A
• Component A depends on Component B
• Component B has known vulnerabilities but is not invoked
• However, it may be possible to invoke Component B by tricking the Application into doing something it wasn't designed to do.

In this case, not having Component B (which would lead to a ClassNotFoundException) would be preferred over resolving the class and having the Application be exploitable.

In the marketing world, products are designed with Minimum Marketable Features (MMF) for a Minimum Viable Product (MVP). In essence, the Runtime Agent should be able to determine the Minimum Required Components (MRC) necessary for positive runtime results.

[jeremylong]

Steve - great idea! I've also been looking at things like dependency:analyze for Maven projects as a possible way to find declared, yet unused, dependencies.

[jeremylong]

@stevespringett would dependency-track able to accept a post of collected evidence for a given JAR and then do the analysis rather then having to do the analysis within the agent? So the use of the agent would be:

1. Install ODC agent in container (tomcat, not docker) running App X
2. Container is started App X is executed with the agent
3. ODC agent sends information as libraries are loaded to dependency-track for analysis

Step 3 would result in several independent posts to dependency-track. In addition, with this setup you would be testing all applications and Tomcat dependencies as a single unit. As the information on the dependencies would be coming in piecemeal over time one would also need to consider re-deployments that remove dependencies - how would that be conveyed/recorded within dependency-track. Another option might be to run the scan during the build and then the agent would report that it was in use.

Thoughts?

[stevespringett]

Testing of all applications as a single unit is already something Dependency-Track does. It does this whenever a component is added and every 24 hours as a whole.

Dependency-Track v3, currently in development, will be able to do step 3. Current version (v1) is more of a static asset management system for components without any real APIs to communicate with anything. v3 is a complete rewrite with an API-first design (defined with Swagger 2.0) that is designed to work in this type of dynamic environment.

The separation of components from applications will continue to be a feature in v3. This will allow you to send multiple requests adding in components when necessary, or as a single big request.

I plan on taking the approach that SonarQube does, an all or nothing where history is maintained for the items that exist between builds, but otherwise drop off. So if an application removes use of a component, I'll continue to monitor that component for vulns, but the application associated with it will not be reporting those vulns. Similar to how it works today, but v3 adds in the whole dynamic API aspects.

Also of potential interest is a way to use Dependency-Track as a source of evidence for a future Dependency-Check release., similar to how we use Nexus or Maven Central today. So think about what type of things you'd like here. I'm thinking of two things: MD5/SHA1 hash lookups and evidence to CPE mappings.