Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel3
Info

NOTES:

  • API capability requires an additional WhiteSource license. Contact your CSM for more details.

  • For customers who have enabled vulnerability-based alerting, there are several changes to API version 1.3 -  refer here for details.

  • This page covers APIs for version 1.3. All version 1.3 APIs must include:

...

This document describes the WhiteSource HTTP API v1.3. The API URL can be obtained by copying the 'WhiteSource Server URL', which can be retrieved from your 'Profile' page on the 'Server URLs' panel. Then, add the path '/api/v1.3' to it. For example: https://saas.whitesourcesoftware.com/api/v1.3.

Regarding version numbers, if there are 3 or more version parts, (for example, x.y.z or x.y.z.w) both x and y are considered a major version (x.y).
If there are 2 major parts (x.y), then x is considered a major version.

...

  • When performing API calls, the time recorded for the action is in GMT time zone, therefore, this is the time displayed in the relevant reports. 

  • Date format in all responses is "yyyy-MM-dd".

  • None of the The API results are not sorted in any order.

API Execution Scope

Generally, each level of the administrator (Organization, Product) can get/set the API attributes in the API calls that refer to their scope and/or under their scope. For example, Product administrators can execute API calls related to their Projects/Products that are defined in WhiteSource, but they cannot execute Organization-related API calls which are outside their scope. However, there are two API calls that are exceptions to this rule:

  • getProjectVitals – getProjectVitals Product administrators can use the Organization level call and get the product/project vitals related to their products/projects.

  • getRequestState – Although an Organization token is required in the call, a product administrator can also execute it.

...

Parameter

Description

requestType

For details, see Supported Requests.

orgToken

Your organization API key.

productToken

A unique identifier for your product.

projectToken

A unique identifier for your project.

Character Sets

WhiteSource HTTP API v1.x supports Accept-Charset header.

...

Vulnerability-Based Alerts

Info

The following APIs are only available in an organization set to vulnerability-based alerting mode. 

Get Security Alerts by Vulnerability Report

Generates security alerts report detailed by vulnerability, in the scope of the organization, a specific product or a specific project. 

The "status" parameter allows filtering of specific alerts statuses ("Active", "Ignored", "Resolved") and by default is set to all statuses. 

Organization

Code Block
{
	"requestType" : "getOrganizationSecurityAlertsByVulnerabilityReport",
    "userKey": "user_key", 
	"orgToken" : "organization_api_key",
    "status" : "active",
    "format" : "xlsx"
}

Product

Code Block
{
	"requestType" : "getProductSecurityAlertsByVulnerabilityReport",
    "userKey": "user_key", 
	"productToken" : "product_token",
	"status" : "ignored",
    "format" : "xlsx"
}

Project

Code Block
{
	"requestType" : "getProjectSecurityAlertsByVulnerabilityReport",
    "userKey": "user_key", 
	"projectToken" : "project_token",
    "format" : "xlsx"
}

Response

The response will have the following headers:

  • Content-Type = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

  • Content-Disposition: attachment; filename=<organization name>-alerts-report.xlsx

Get Security Alerts by Library Report

Generates security alerts report detailed by library, in the scope of the organization, a specific product or a specific project. 

The "status" parameter allows filtering of specific alerts statuses ("Active", "Ignored") and by default is set to all statuses. A library that is marked as "active" has at list 1 active alert. A library that is marked as "ignored" has at list 1 ignored alert. 

Organization

Code Block
{
	"requestType" : "getOrganizationSecurityAlertsByLibraryReport",
    "userKey": "user_key", 
	"orgToken" : "organization_api_key",
    "status" : "active",
    "format" : "xlsx"
}

Product

Code Block
{
	"requestType" : "getProductSecurityAlertsByLibraryReport",
    "userKey": "user_key", 
	"productToken" : "product_token",
	"status" : "ignored",
    "format" : "xlsx"
}

Project

Code Block
{
	"requestType" : "getProjectSecurityAlertsByLibraryReport",
    "userKey": "user_key", 
	"projectToken" : "project_token",
    "format" : "xlsx"
}

Response

The response will have the following headers:

  • Content-Type = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

  • Content-Disposition: attachment; filename=<organization name>-alerts-report.xlsx

Response Structure

Structure of the vulnerability in each security vulnerability alert object:

Vulnerability

Each vulnerability object has the following fields:

...

name - the name of the vulnerability (e.g. CVE-2008-0983).

...

severity - the CVSS severity (as taken from NVD), can be one of:

  1. HIGH

  2. MEDIUM

  3. LOW

...

score - the CVSS score (as taken from NVD), values range from 0-10.

...

cvss3_score - the CVSS score 3 (as taken from NVD), values range from 0-10.

...

cvss3_severity - if cvss 3 score is between 0-3.9 - low, if cvss 3 score is between 4-6.9 - medium, if cvss 3 score is between 7-10 - high

...

scoreMetadataVector - a text representation of a set of CVSS metrics. See also related specification.

...

description - the vulnerability description.

...

publishDate - the publish date.

...

sourceFile - in case the vulnerability was matched to a source file, not the binary library, the sourceFile field will be populated (see details below).
Note: only libraries with type SOURCE_LIBRARY have source files.

...

vulnerabilityFix - the top fix of the vulnerability (see details below).

...

fixResolutionText - the actual resolution text to display for the given fix.

Info

The 'vulnerabilityFix' and 'fixResolutionText' fields are populated only when there is an available fix.

Library Details Overview

...

type

...

groupId

...

artifactId

...

version

...

name

...

filename

...

ActionScript

Alpine

Arch Linux

Debian

Java Archive

JavaScript

javascript/Node.js

Nuget

Python

RPM

Ruby

...

Package name

...

Filename

...

Package version

...

Package name

...

Filename (taken from artifactId)

...

Java

...

Maven groupId

...

Maven artifactId

...

Maven version

...

Maven project name

...

artifactId + version + extension

...

javascript/Bower

...

Project owner

...

Package name

...

Package version

...

Package name

...

artifactId + version

...

.NET

...

Owner / Organization

...

.NET project name

...

Package version

...

.NET project name

...

artifactId + version + extension

...

Source Library

...

Project owner

...

SCM project name

...

Repository version / tag

...

artifactId + version

...

artifactId + version

...

Unknown Library

...

-

If the artifact has owner, it will be displayed as groupId

...

filename + extension.

...

-

Will be shown only in case the artifact has version when uploaded

...

filename + extension

If the artifact has artifactId and version, the name will consist of them

...

Filename + extension

Source File

Each source file object has the following fields:

  1. name - the name of the source file.

  2. sha1 - the SHA-1 checksum.

Vulnerability Fix

Each vulnerability fix object has the following fields:

...

vulnerability: The name of the vulnerability (e.g. CVE-2008-0983).

...

type: The type of fix available. Can be one of the following:

  1. CHANGE_FILES

  2. PATCH

  3. UPGRADE_VERSION

...

vulnerabilityFixOrigin - the site, service or provider of the fix, can be one of:

  1. GITHUB_COMMIT

  2. JIRA

  3. BUGZILLA

  4. NODE_SECURITY_ADVISORY

  5. PIVOTAL_VULNERABILITY_REPORT

  6. FFMPEG_SECURITY

  7. STRUTS_SECURITY_BULLETIN

  8. XFORCE_VULNERABILITY_REPORT

  9. SECURITY_TRACKER

  10. WHITESOURCE_EXPERT - Used whenever a WhiteSource security researcher discovers that a vulnerability can be fixed by upgrading to a newer version, and there are no other sources for the vulnerability fix.

...

url - the URL of the fix.

...

fixResolution - the fix resolution. Depending on the origin the fixResolution field may vary:

  1. GITHUB_COMMIT - comma separated file names to change.

  2. JIRA - comma separated list of versions, e.g. “1.0.5,1.1.3”.

  3. BUGZILLA - comma separated list of versions.

  4. NODE_SECURITY_ADVISORY - text taken as-is from the origin, e.g. “>= 1.0.4” or “Upgrade to version 0.2.5 or greater.”

  5. PIVOTAL_VULNERABILITY_REPORT - text taken as-is from the origin.

  6. FFMPEG_SECURITY - comma separated list of versions.

  7. STRUTS_SECURITY_BULLETIN - text taken as-is from the origin, e.g. “Developers should upgrade to Struts 2.0.12”.

  8. XFORCE_VULNERABILITY_REPORT - text taken as-is from the origin, e.g. “Refer to ASA-2007-010 for patch, upgrade or suggested workaround information. See References.”.

  9. SECURITY_TRACKER - text taken as-is from origin, e.g. “The vendor has issued a fix (2.3.17, 2.4.11).”.

...

date - publish date of the fix (not always available).

...

messsage - the title / description of the fix as taken from the origin.

...

extraData - extra data stored for each fix in key_1=value_1&key_2&value_2 pairs. Depending on the origin the extraData field may vary:

  1. key - the short commit SHA-1.

  2. committerName - the name of the committer.

  3. committerUrl - a link to the committer’s page on GitHub.

  4. committerAvatar - a link to the committer’s avatar.

  5. key - the issue id.

  6. assignee - the person assigned to the issue.

  7. key - the issue id.

  8. assignee - the person assigned to the issue.

  9. key - the advisory id.

  10. key - the report id, which is simply the CVE name.

  11. key - the bulletin id.

  12. key - the report id.

  13. key - the alert id.

  1. GITHUB_COMMIT

  2. JIRA

  3. BUGZILLA

  4. NODE_SECURITY_ADVISORY

  5. PIVOTAL_VULNERABILITY_REPORT

  6. FFMPEG_SECURITY - no extra data available.

  7. STRUTS_SECURITY_BULLETIN

  8. XFORCE_VULNERABILITY_REPORT

  9. SECURITY_TRACKER

Project State

  1. SETUP - Initializing project.

  2. DIFF - Calculating inventory changes.

  3. UPDATE - Updating inventory.

  4. CHANGE_EXCLUSIONS - Updating dependency exclusions.

  5. CHANGE_LOCAL_PATHS - Updating library paths.

  6. REMOVE - Removing libraries.

  7. PARTNER_UPDATE - Updating inventory.

  8. UPDATE_ALERTS - Updating alerts.

  9. CREATE_ISSUES - Creating external tickets

Assignments

...

ADMIN

...

ALERTS_IGNORER

...

ALERT_EMAIL_RECEIVER

...

DEFAULT_APPROVER

...

LEGAL_ASSIGNER

...

USER

...