Component Search REST APIs - v2
The Component Search API allows you to find a particular component, as well as get information back about that component. Using GET requests it allows you to retrieve component information such as application ID, application name, report URL, component hash, component coordinates, and 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.
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 stage (e.g. Build) where the component was analyzed.
Searching for Components
First, make sure your IQ 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.
Now, in addition to this, you will need to add two parameters - the stage, and then add your search parameters.
Typically the stage represents the development lifecycle of your product. There are four stages that are currently supported.
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:
The search parameters can either represent a direct hash of a component or a componentIdentifier object.
- hash - the component hash (e.g. hash=1234567890).
- componentIdentifier - this is an object that contains the the coordinates of the component and its format.
- format - this is the format of the component (e.g. "maven" or "a-name" or "python").
- coordinates - this object contains the name/value pairs for identifying coordinates (e.g. artifactId, groupId, version, extension, and classifier).
If you are working with a command line utility like curl, remember to URL encode the componentIdentifier payload.
Now, let’s look at an example. Consider a case where we wanted to find all components within the group ID "tomcat", for any applications evaluated during the Build stage. Using the information above, as well as cURL and an encoded URL, here is what we would have…
Of course the above is an encoded URL, so just for a bit of help, here is what a non-encoded URL would look like. This should help you identify the JSON in the example above.
If we want to search for a python pypi package pyOpenSSL in the version 17.0.0 we would use the below componentIdentifier
Included in our cURL example is the default IQ 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.
The response from the API is a JSON object. Assuming we ran the maven query searching for tomcat components, the JSON response will list all applications containing the tomcat component. An example output:
The data above was formatted to make it a bit more readable.
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 GAVEC (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 Policy Management.