This article applies to:
Java applications hosted on web servers where multiple applications can be loaded into the same JVM, such as:
Managing multiple Java applications running in the same JVM.
By default, the Contrast Java agent will attempt to catalog and onboard any supported web applications found in the JVM. Each application will have its libraries, routes and basic environmental information cataloged and sent to the Contrast UI. In order to upload this information, an application name must be set or created by the agent. How that name is chosen will be discussed in more detail below.
Application naming within agent configurations
Avoid grouping applications together via agent configuration options like
standalone_app_nameshould no longer be used with current Contrast Java agents. This configuration setting will be deprecated in the future.
Utilizing properties like
standalone.app.namewill force the agent to treat all applications found in the JVM as one single monolithic app. When onboarded into the Contrast UI only one application will be seen consisting of all vulnerabilities and routes found in each of them. Additionally, as the Java agent finds new web applications in the JVM it will send a list of libraries to the Contrast UI. This list can overwrite previous lists if the application name is overused.
In this situation, use of these naming configurations obfuscates quite a bit of information. This can make it difficult to determine which application had vulnerabilities or CVEs associated with it. Route coverage may also be harder to track per application. It will also include any application-specific management tools and services that you may not wish to analyze. (Their routes, libraries and vulnerabilities can be added.)
You can read how the agent automatically selects a name for the application in this article: How does the Java Agent handle application naming.
We also provide application specific configuration in this situation via
Servletinitialization parameters: Multi-Application configuration with Contrast Profiles
To group or not to group...
You may have multiple monolithic-style applications running on the application server or many microservices. As noted, our Java agent will discover each of these applications as they are exercised and onboard this into our UI. It may or may not be desirable to manage them in this fashion.
A few points to consider when grouping applications.
- Merge, if you have multiple micro-services that do not act independently and require one another to run a single web application.
- Merge, if you wish to manage all micro-services as one application. (vulnerability scores, libraries, routes and vulnerabilities)
- Do not merge if each application can stand alone as its own fully functioning web application.
- Do not merge if you wish to manage user access per micro-service.
- Do not merge if you wish to grade or manage each micro-service independently.
Merging two or more applications creates a single application called a primary application and is a common practice for Organization Administrators responsible for bringing applications online.
In some situations merging microservices into one application within the Contrast UI allows for the best of both worlds.
- When several apps (or "modules") are merged under a parent application, you can use filters in the agent configuration and UI to identify data from each application independently of the whole by using tags:
- Tags an application in the Contrast UI
- Tags vulnerabilities in the Contrast UI
- Tags SCA/OSS libraries in the Contrast UI
By default when merging applications you must pick one application to represent the primary or parent, however it is possible to create an "empty" application to act as the parent, with a name of your choosing, as detailed in this article: How to create a custom name for a merged group of Applications
Dealing with application server management programs and services
As noted, all supported web applications running in the JVM will be onboarded into the Contrast UI. That can include administrative consoles and services that come with the application server. Generally, it's not desired to have these analyzed by the Java agent. However, if exercised, they will be onboarded into the Contrast UI. We suggest archiving these applications and leaving them in this state, as it will stop the agent from doing any analysis on them. If they are deleted the agent will onboard them again on the next restart of the application server.