Contrast concepts and architecture
This topic provides basic Contrast concepts and details about the high-level architecture for Contrast Assess and Protect.
Contrast concepts
These concepts are specific to the Contrast platform.
Application: An application is one deployable artifact of your code.
If you are using microservices, Contrast considers each microservice a single application that is allocated a license. You can merge multiple microservices modules into a single, primary application. <QUESTION: HOW DOES MERGING AFFECT LICENSING?>
Server: A server is a process running one or more applications in your environment. It varies by language, but this process could be Tomcat, IIS, WebSphere, UWSGI, and others.
Servers don't represent physical hardware or virtual machines. A physical server could run a Tomcat process that hosts two Spring Boot WAR applications and a UWSGI process that hosts one Python application. Contrasts consider this to be two servers and three applications.
If you're using containers, Contrast usually considers the server to be the entrypoint application to which you attach an agent.
Environments: Environments represent the stage of your deployment lifecycle in which a specific server is running. You specify either Development, QA, or Production. Contrast lets you specify rules and configurations for each environment.
Routes: A route, as reported in Contrast Assess, is a function signature of the method that handles requests to one or more URL patterns. The exact format can vary, depending on the language of the Contrast agent you are using. A route can have multiple URLs associated with it.
For best results from Contrast, set up tests that make a request to every route in your application. Contrast provide data to help you determine what routes are (or aren't)
Vulnerabilities: Vulnerabilities tell you what you need to be remediate in your application. Ideally each vulnerability should represent one thing that you need to change.
Most vulnerabilities are associated with a specific route. However, some rules can apply to many or all routes in an application (for example, Cross Site Request Forgery).
Instrumentation: During instrumentation, Contrast places an agent into your application to analyze behavior, data flow, and operational context.
Runtime: Contrast actively monitors and analyzes application behavior in real-time, identifying and potentially blocking threats as they occur. Contrast supports runtime behavior for IAST, RASP, and runtime SCA technologies.
Contrast Assess architecture
This diagram shows the connections between the different components for Contrast Assess.
Contrast Protect architecture
This diagram shows the connections between the different components for Contrast Protect.
Contrast deployment patterns
Multi-application server deployment
These diagrams show how a multi-application server could be deployed.
This example shows two applications running in a single server process. The server process could be Tomcat, WebSphere, IIS, or a similar service.
This example shows four applications running in two server processes.
Single-application server deployment
This example shows a single application running in one server process. The application could be a self-executable Spring Boot, microservice, or Go application.
K8S deployment
This example shows a K8S deployment where you have three applications running in four server processes.
Pod A is scaled for two applications and Pods B and C are scaled to one application.
The sidecar could use software such as Istio.
The application could be any containerized application.
