...

• One of the commits in the push command added a file(s) that has an extension supported by WhiteSource.One of the commits in the push command removed a /removed a source file(s) that has an extension supported by WhiteSource.
  Refer to the WhiteSource Languages page in order to find out whether or not a specific language and its extensions are supported. 

• One of the commits in the push command includes a an addition/modification in of the package manager configuration filedependency file(s).
  Refer to the list of supported configuration dependency files to find out whether your configuration dependency files are supported.

NOTE: a push command may consist of multiple commits.

Viewing Details of the Scan

...

• The Issues tab within the GitLab project.

• The WhiteSource Security/License Check within the GitHub project's Commits tab.

• The WhiteSource UI.

• Via email notifications.

• For GitLab Ultimate users:

  • The GitLab security dashboard

  • Pipeline reports

In the WhiteSource UI, WhiteSource projects will have the same name as the corresponding GitLab project, with a "GL_" prefix, unless otherwise specified in the .whitesource file using a project token.

...

Viewing the Issues Tab

If you are making performing Merge Requests or push commands via the Web browser, refresh your Web browser in order to view the issues that were foundgenerated by WhiteSource. NOTE: It may take a number of minutes for the issues to be scanned and displayed after a valid push command is initiated.

The Issues tab displays all the issues that the GitLab the WhiteSource Integration app detected with the red security vulnerability label. This proprietary label indicates a security vulnerability was detected by WhiteSource. 

As part of your workflow, you have the option to add a relevant label(s) to specific issues, and close issues that were resolved.

All Issues that were manually closed issues are not reopened as open issues during the next scan will not be re-opened during future WhiteSource scans unless their label and/or name has have been manually changed or changed via the GitLab API.

Viewing Details of an Issue

Clicking on a specific issue displays its details. The display changes according to the type of library:

NOTE: WhiteSource supports displaying multiple libraries for the same CVE; the libraries will be displayed in the same issue.

Component-based library (e.g., '*.tgz', '*.jar' ): It includes the following information:

• Vulnerable library: Includes the path of the library. If the path is of a transitive dependency, then only the path information of the root library is displayed. This section also contains a commit link, which includes the path to the GitLab commit link where the vulnerability was found.

• Vulnerability details: Description of vulnerability, published date, and link to the vulnerability source website.

• CVSS 3 score: Basic CVSS3 score metrics. If this score is not available then the CVSS 2 score is displayed.

• Suggested fix: A detailed suggestion that includes type, origin, release date, and fix resolution. Note that a fix may not always be available.

• Automatic Remediation is available for this issue - (NOTE: Supported from version 19.9.1.1 only) Part of WhiteSource Remediate. Displayed only when automatic remediation is available for the issue, and when the issue does not contain more than a single component. 

• Check this box to open an automated fix MR - (NOTE: Supported from version 19.10.1 only) Provides the ability to generate fix MRs on-demand without defining workflow rules in advance. This checkbox is displayed only if automatic remediation is available for the issue and no workflow rules were added yet for the repository. Note that after clicking the checkbox, WhiteSource Remediate immediately generates a fix MR to remediate the given issue.

Source file-based component: It includes the following information:

• Vulnerable library: Includes a description of the vulnerable source library, a link to the source library home page, a commit link, and the path to the GitLab commit link where the vulnerability was found.

• Library Source Files - A list of source files found in the vulnerability source library.

• Vulnerability Details: Description of vulnerability, published date, and link to the vulnerability source website. 

• CVSS 3 score: Basic CVSS3 score metrics. If this score is not available, then the CVSS 2 score is displayed.

• Suggested fix: A detailed suggestion that includes type, origin, release date, and fix resolution. Note that a fix may not always be available.

Viewing the Security Dashboard

GitLab Ultimate users have access to GitLab’s security dashboard.

Vulnerabilities detected by WhiteSource for GitLab can be identified by their “ - Detected by WhiteSource” suffix.

Viewing Details of a Vulnerability in the Security Dashboard

...

Description: A description of the vulnerability.

...

Project: The GitLab project the vulnerability exists in.

...

File: The manifest file the vulnerable dependency is declared in.

...

Identifiers: The original identifier of the vulnerability.

...

Severity: The vulnerability’s severity. Possible values are:

• High

• Medium

• Low

Confidence: How reliable this vulnerability’s assessment is.

...

Report Type: The security report this vulnerability belongs to (SAST, DAST, dependency_scanning, etc.).

...

Links: Any references to external documentation pieces or articles that describe the vulnerability further.

...

Solution: An explanation of how to fix the vulnerability.

Viewing the Pipeline Reports

Pipeline reports can be viewed from the following places:

• Within the CI/CD pipeline by clicking CI/CD > Pipelines > Pipeline # > Security.

• Within MRs from feature branches to the main branch by clicking Expand in the Security Scanning section of the MR.
  

  Image Removed

Commit Status Indicators

Commit Status indicators are displayed for each See here for more information.

Viewing WhiteSource Security/License Checks

Commit Status indicators are displayed for each head commit on the Commits sub-tab of the Project tab.

...

NOTE: The commit statuses above are the red X and the green check mark.

Clicking on a specific indicator will redirect you to the relevant Commit page, where you can find the WhiteSource Security Check for the selected head commit in the Changes subtab sub-tab, which contains a security report.

...

• CVE: A link to the related CVE page for the vulnerability. Displayed in a collapsible format (click the arrow to expand/collapse for more information regarding the vulnerability).

• Severity: Overall score of the severity (High, Medium or Low).

• CVSS Score

• Vulnerable Library

• Suggested Fix 

• Issue: A link to the WhiteSource issue that was generated for the vulnerability.

Types of Indicators

The following commit status indicators are available as feedback on the head commits:

• Pending: Scan  The WhiteSource scan has not begun and is scheduled to begin.

• Running: The WhiteSource scan is in progress.

• Success: The WhiteSource scan completed successfully and no vulnerabilities were detected. 

• Failed: The WhiteSource scan did not complete successfully, this is the default for all completed scans.
  Note that NOTE: a failed status may be shown due to security vulnerabilities, or due to an error that occurred during the scan.

Samples of Commit Status Indicators

...

Running

The following is a sample of a Running status, which indicates that the security check is currently scanning the head commit.

...

Success

When no vulnerabilities are found and no errors occurred during the scan, WhiteSource will display the following commit status, and a security report indicating that no vulnerabilities were detected:

...

Failed

All head commits that fail the scan due to the security check detecting vulnerabilities or due to an error that occurred during the scan will display a failed commit status.
The following screenshot displays a failure indicator for a head commit

...

Viewing Details in the WhiteSource UI

• In the WhiteSource UI, WhiteSource projects will have the same name as the corresponding GitLab repository, with a "GL_" prefix, unless otherwise specified in the .whitesource file using a project token.

• The name of the WhiteSource product will be the same as that of the GitLab grouppreceded by a "GL_" prefix if the GitLab project is under a group. Otherwise, the name will be your GitLab username preceded by "GL_".

Viewing the Security Dashboard

GitLab Ultimate users have access to GitLab’s security dashboard.

Vulnerabilities detected by WhiteSource for GitLab can be identified by their “ - Detected by WhiteSource” suffix.

Viewing Details of a Vulnerability in the Security Dashboard

• Description: A description of the vulnerability.

• Project: The GitLab project the vulnerability exists in.

• File: The manifest file the vulnerable dependency is declared in.

• Identifiers: The original identifier of the vulnerability.

• Severity: The vulnerability’s severity. Possible values are:

  • High

  • Medium

  • Low

• Confidence: How reliable this vulnerability’s assessment is.

  • Vulnerabilities detected by WhiteSource will always have “Confirmed”confidence.

• Report Type: The security report this vulnerability belongs to (SAST, DAST, dependency_scanning, etc.).

  • Vulnerabilities detected by WhiteSource will always have the “dependency_scanning”report type.

• Links: Any references to external documentation pieces or articles that describe the vulnerability further.

• Solution: An explanation of how to fix the vulnerability.

Viewing the Pipeline Reports

Pipeline reports can be viewed from the following places:

• Within the CI/CD pipeline by clicking CI/CD > Pipelines > Pipeline # > Security.

• Within MRs from feature branches to the main branch by clicking Expand in the Security Scanning section of the MR.
  

  Image Added