The CLM Book - Optimized Component Lifecycle Management with Sonatype CLM

20.1. Component Search REST APIs (v1)

[Warning]

Sonatype CLM APIs are versioned. This document represents a deprecated version (v1) and we highly recommend updating to the latest version of Sonatype CLM and using the latest version of this API.

You may reach a point where you would like to search for a particular component that has been identified during a CLM evaluation. In other words, you have already completed an evaluation (more likely you have done several or many evaluations), and either the CLM server has identified, or you have claimed, at least one component in that application.

The likely scenario is that CLM has identified many components across all of your applications. Even more likely, a few of the same components show up in several (maybe all) of your applications. In these instances, the Sonatype CLM Component Search API allows you to both find a particular component, as well as get information back about that component.

This API consists of GET requests, which allow you to retrieve component information such as application ID, application name, report URL, component hash, component coordinates, and perhaps most importantly, it provides the highest threat level of the policy violations (for the found component).

Below, we’ve provided an example of the GET request. We’ve done this using the HTTP client cURL. Of course, you could use any HTTP client tool. Additionally, to help demonstrate use of the API, we’ve broken out the various pieces for this request and provided an example of data that is retrieved.

[Note]

Compared to the other APIs, Component Search is fairly simple. However, you should have some basic information about the component coordinates, as well as the Sonatype CLM stage (e.g. build) where the component was analyzed.

Searching for Components

First, make sure your Sonatype CLM server is started. Also, as we mentioned, you will need to have evaluated at least one application. With those two things completed, let’s take a look at the GET API call.

GET /api/v1/search/component

Now, in addition to this, you will need to set the stage, and then add your search parameters. Let’s take a look at stage first.

Stage

Typically the stage represents the development lifecycle of your product. There are four stages that are currently supported. These include:

  • build
  • stage
  • stage-release
  • operate

Entering any of these for the stage ID will pull from that specific stage’s evaluation data.

Next up, you need to set the component search parameters using any combination of these options:

Parameters
  • hash - the component hash (e.g. hash=1234567890)
  • groupId - the Group ID as part of the GAV (e.g. groupId=com.mycompany)
  • artifactId - the Artifact ID as part of the GAV (e.g. artifactId=example-library)
  • version - the Version as part of the GAV (e.g. version=1.6.1)

Now, let’s consider an example where we wanted to find all components within the group ID "tomcat", for any applications evaluated during the build stage. Using the above, as well as cURL, we should have something like this…

curl -u admin:admin123 -X GET "http://localhost:8070/api/v1/search/component?stageId=build&groupId=tomcat"
Note
Included in our cURL example is the default CLM server location (localhost:8070) as well as the default username and password for the admin account. Your account credentials may vary, but are necessary in order for the request to be processed. The results provided will be filtered based on the permissions of the credentials you use. For example, if you are not included in at least the developer role for an application, no results will be returned for that application. Given this, some results may be obscured.

Alright, so in our case, the API above produced the following results. If you have any tomcat component, you could expect something similar…

{
    "results": [
        {
            "applicationId": "bom1-12345678",
            "applicationName": "dev",
            "reportUrl": "http://localhost:8070/ui/links/application/bom1-12345678/report/75492b2ce44e4cfc94594eedf9d30895",
            "hash": "1249e25aebb15358bedd",
            "groupId": "tomcat",
            "artifactId": "tomcat-util",
            "version": "5.5.23",
            "threatLevel": 8
        },
        {
            "applicationId": "demo-app-1",
            "applicationName": "CLM",
            "reportUrl": "http://localhost:8070/ui/links/application/demo-app-1/report/ee5d569f75864acc98321c68ed3ad76a",
            "hash": "1249e25aebb15358bedd",
            "groupId": "tomcat",
            "artifactId": "tomcat-util",
            "version": "5.5.23",
            "threatLevel": 8
        },
        {
            "applicationId": "demo-app-2",
            "applicationName": "Nexus",
            "reportUrl": ""http://localhost:8070/ui/links/application/demo-app-2/report/7ab76c4f15da4bdab82c37c09b125078",
            "hash": "1249e25aebb15358bedd",
            "groupId": "tomcat",
            "artifactId": "tomcat-util",
            "version": "5.5.23",
            "threatLevel": 8
        }
    ],
    "criteria": {
        "stageId": "build",
        "hash": null,
        "groupId": "tomcat",
        "artifactId": null,
        "version": null
    }
}
[Tip]

These results should be self explanatory, though it is important to note that the criteria specified as part of the call is provided as well.

Using Wildcards

Of course, you may come across instances where you want to produce more results with less specific component details. If this is the case, the Component Search API does support the use of wildcards when searching using the GAV (coordinates).

If you are familiar with the coordinates policy condition, it follows the exact same logic. You can read more on the Coordinates condition in Step Five in Policy Management chapter.