There is no one-size-fits-all to any interface, for all that we try to create the best user experience possible. Many of our customers log into Sentinel and use it exclusively for reporting, tracking, asking questions, and learning more about vulnerabilities. It is a one-stop shop for all these activities, including an Ask-A-Question feature which allows contact with the Threat Research Center at any point within Sentinel. While many, we hope, find the Sentinel interface to be all that is needed for meeting complete application security and vulnerability management needs, there can often be reasons to import the data from your DAST or SAST scanning results into other systems.
For some vulnerability management and business intelligence systems like Kenna or Archer, we have built-in integrations or connectors readily available. But there are instances where you may need or desire to import data into a different system.
The WhiteHat Sentinel Application Programming Interface (API) can help you out. Whether you’re looking to bring information into your own ticketing system, a SIEM, a new set of developer tools, or even a home-grown environment, we hope you’ll find pointers to the documentation which will help make it easy.
Our basic technical pages are designed to provide a general introduction to the use of RESTful APIs in general and to the Sentinel API in specific, including providing a general map of the inter-relationships of API Resources and an overview of how to interact with the flow of verified vulnerability information.
What is an API?
As you probably already know, an API provides an interface between different software components, allowing content to be shared between applications – for example, between the Sentinel software and your bug tracking system. (For general information about APIs, please see relevant articles on Wikipedia, readwrite, or FreeCodeCamp, or via your preferred search engine.)
What is a RESTful API
The Sentinel API is web-based, and uses a representational state transfer (RESTful) architecture in which the client sends a request when it is ready to move to a new state. While requests are outstanding, the client is “in transition.” The representation of each application state includes links that can be used the next time the client initiates a state transition.
WhiteHat uses RESTful architecture because it allows independent deployment of components, uses interface generality, is scalable, and can use intermediary components to enforce security and reduce latency.
The four actions available within the WhiteHat API resources are:
- GET (Retrieve information)
- PUT (Edit information)
- POST (Create information)
- DELETE (Delete information)
GET is used to retrieve resources. Directory resources generally return a list of sub-resources optionally filtered by query parameters.
POST is used to create new resources. In general, a POST request is accompanied by a content body like that returned by a GET, though “ID” fields are usually not required as they are assigned during the POST and the created record is returned.
PUT is used to update a resource. The content of the PUT request should match the XML or JSON schema of the resource retrieved through a GET to the same resource.
DELETE is used to remove a resource. Removal of resources is currently restricted to just a few resources. DELETE (like GET) does not take a body; all the information required for the DELETE is contained in the Request URI.