Runtime Agent Analysis

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](https://www.contrastsecurity.com/security-influencers/iast-the-villainous-library-named-commons-httpclient-3.1.jar) 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.