Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Table of Contents
maxLevel4

...

Parameter TypeDescriptionRequired Default
minSeverityLevelString

Enables users to decide whether to open a new GitHub Issue only if a certain Severity Level is available.

Available values for "minSeverityLevel" needs to be:

    • NONE - No GitHub Issues will be generated.

    • LOW - Any Low/Medium/High vulnerabilities found will generate a GitHub Issue.

    • MEDIUM - Any Medium/High vulnerabilities found will generate a GitHub Issue.

    • HIGH - Any High vulnerabilities found will generate a GitHub Issue.

NoLOW

Initiating a Scan

New users are entitled to scan each repository up to five times a day. Existing WhiteSource customers have the scan limitations that are set in their account agreement with WhiteSource.  

A scan is initiated via a valid GitHub 'push' command. A valid 'push' command meets at least one of the following requirements:

  • One of the commits in the 'push' command include added file(s) that have an extension supported by WhiteSource and/or one of the commits in the 'push' command included a removal of file(s) that have 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 modification in the package manager configuration file(s). This includes any of the following files:
    • build.gradle
    • pom.xml
    • setup.py
    • requirements.txt
    • Gemfile.lock
    • package.json
    • bower.json
    • Gopkg.lock
    • Godeps.lock
    • vendor.conf
    • gogradle.lock
    • glide.lock
    • composer.json
    • build.sbt
    • paket.dependencies
    • Any metafile with one of the following extensions: 

      • config
      • csproj
      • htm
      • html
      • shtml
      • xhtml
      • jsp
      • asp
      • do
      • aspx

...

  • Component based library (e.g., '*.tgz', '*.jar' ): The vulnerable library appears first after the heading that indicates the name of the issue.



    It includes the following information:
    • Vulnerable library: Includes the path of the library. If the path is of a transitive dependency library then only the path information of the root library is relevant to you.

    • Commit link: Includes the path to the GitHub commit link where the vulnerability was found.
    • Vulnerability details: Description of vulnerability, published date, and link to the specific CVE in the CVE website.
    • CVSS 3 score: Basic CVSS3 score matrix. If this score is not available then the CVSS 2 score matrix is displayed.
    • Suggested fix for the vulnerability: A detailed suggestion that includes type, origin, release date, and fix resolution. Note that a fix may not always be available.
  • Source file based component: The vulnerable library appears as the first item in the list:



    It includes the following information:
    • Vulnerable library: Includes a comment that indicates the possibility of a false origin recognition, and a list of all the source files of this library. 
    • Vulnerability Details: Description of vulnerability, published date, and link to the specific CVE in the CVE website.
    • CVSS 3 score: Basic CVSS 3 score matrix. If this score is not available then the CVSS 2 score matrix is displayed.
    • Suggested fix for the vulnerability: A detailed suggestion that includes type, origin, release date, and fix resolution. Note that a fix may not always be available.
    • Commit link: Includes the path to the GitHub commit link where the vulnerability was found.

...

Initiating a Merge Policy

A merge policy utilizes the app's integration with GitHub Checks API. It enables the repository's administrator to approve the merging of a pull request with 'Failed' commit statuses to a target branch in the repository. 
For more information on Checks API, see the related GitHub Checks API introduction page.

Prerequisite for the Merge Policy: Add a Branch Protection Rule

...

  • Severity: Overall score of the severity (High, Medium or Low).
  • CVSS Score 
  • CVE: A link to the related CVE page for the vulnerability.
  • GitHub Issue: A link to the WhiteSource issue that was generated for the vulnerability. For example, the following is an issue that was generated for the first vulnerability of the report on the above screenshot: 

...

  1. Go to the 'Applications' section of your GitHub's account settings, and click on the 'Configure' button next to the 'WhiteSource Bolt for GitHub' app.



  2. The 'WhiteSource Bolt for GitHub' page opens. Scroll down in order to view the 'Uninstall WhiteSource Bolt for GitHub' button.



  3. Click on the 'Uninstall' button. Uninstalling WhiteSource Bolt for GitHub removes it from all your repositories.
  4. Optionally, go to 'Authorized GitHub apps' tab, and click the 'Revoke' button next to the 'Bolt for GitHub' app.