WhiteSource

Responsible Disclosure

WhiteSource is used by FINOS to automate processes around responsible disclosure of security vulnerabilities; read more on /wiki/spaces/FINOS/pages/1230176257

Near Real Time scanning

WhiteSource runs project scanning in near-real-time: every time a new CVE gets spotted on a library that is used by the project, the vulnerability is notified. Scanning can also happen:
  1. At build time, using the WhiteSource unified agent
  2. On code change, using the WhiteSource integration for GitHub.com
StatusDelivered
Linkwhitesourcesoftware.com
TopicsLegal, Security, Quality
LanguagesJava, Clojure, Javascript, C#, Python

WhiteSource automatically identifies all the open source components and dependencies in your build by constant and automatic cross-referencing of your open source components against WhiteSource’s definitive database of open source repositories.

WhiteSource provides a dedicated instance to validate and enforce security and legal compliance for all Symphony Software Foundation hosted projects.

Below are listed the main WhiteSource features that have been adopted by Foundation projects.

  1. Check libraries for outdated versions
  2. Check libraries for security vulnerabilities
  3. Check libraries for bugs
  4. Check libraries for problematic/undefined licenses
  5. Check libraries for release activity
  6. Integration with CI environments

This page gives an introduction to the WhiteSource Dashboard, see below how to request access; to enable automated scanning, project leads can use the WhiteSource Unified Agent in their build process and configure different type of actions.

Glossary

To avoid confusion, below are listed some WhiteSource concepts that differ with the definitions used within the Foundation.

  1. A Foundation repository is a Github repository hosted by the Foundation; in WhiteSource terms, this is called a project
  2. A Foundation project is a logical entity that includes
    • one or more project leaders
    • a project team
    • one or more Foundation repositories; if one, project and repository will have the same name.
    • In WhiteSource terms, this is called a product and can be accessed directly by the WhiteSource main menu; each WhiteSource product will list below the projects included.
  3. Foundation WhiteSoure dashboard - WhiteSource provides a dedicated instance for the Foundation projects that can be accessed
    • by all project leaders, to check and export project metrics
    • by Foundation Staff, to configure Foundation WhiteSource policies
  4. Foundation WhiteSource policies - A collection of rules and workflows implemented in the WhiteSource dashboard by the Foundation team to enforce security and legal compliance; below are reported the details.
  5. Alert - The visual notification that WhiteSource shows in the main dashboard when a policy violation is found

Features

WhiteSource provides the following features to Foundation project leads/committers that have been granted access:

  1. Access the WhiteSource dashboard for one or more projects
    1. Access WhiteSource Due Diligence and Risk reports
    2. Browse (and drill down) through project libraries
    3. Browse (and drill down) through licenses found in the project
    4. Check alerts and warnings triggered by policy violations
  2. Configure WhiteSource build plugins to upload project metrics
  3. Configure Travis CI (or other CI environments) to continuously
    • validate code against Foundation policies enforced by WhiteSource
    • fail the build, if any policy violation is found
    • upload project metrics to the WhiteSource Foundation dashboard

WhiteSource Policies


Legal policies disabled

Legal policies are currently disabled due to the large amount of false positive generated by dual-licensed libraries. We are working to improve such configuration

Below are the WhiteSource policies that have been configured by the Foundation and are enforced across all integrated projects; all libraries that are scanned in a project are matched against the following policies, in the order reported below, until a policy is matched.

  1. [SECURITY] Reject High Security Vulnerability Severity - any library that contains high level CVEs is marked as Rejected,
  2. [SECURITY] Reject High Security Vulnerability Score - any library that contains CVEs with score higher than 7 is marked as Rejected,
  3. [QUALITY] Reject High Bug Rating - any library high bug rating is marked as Rejected,
  4. [LEGAL] Licenses that require review - any library with unknown license is marked as Rejected,
  5. [QUALITY] Reassign Low Version Activity - any library with a low amount of versions released is Reassigned to the project lead for validation,
  6. [QUALITY] Reassign Stale (5 years) Library - any library without a release for more than 5 years is Reassigned to the project lead for validation,
  7. [LEGAL] Reject Problematic (Category X license) libraries - any library using a Category X license, as indicated in our /wiki/spaces/FINOS/pages/75530255/wiki/spaces/FINOS/pages/75530375/wiki/spaces/FINOS/pages/75530255, are marked as Rejected.

Managing requests

Every time a policy reassigns an alert (see policies above), a user gets notified with an email by WhiteSource that something needs attention; using the Dashboards > Requests it is possible to check the Pending requests.

Generating reports

WhiteSource generate a wide list of Reports and Dashboards, that can be accessed by the main menu; below are listed the ones that have been used most frequently by Foundation projects.

Reports > Risk, generates a summary a management level 1-Pager, providing a bird's-eye view of all aspects concerning the account's open source libraries; security, quality and compliance. It can be exported to PDF and attached to the project's documentation, to give consumers peace of mind.

Reports > Due Diligence, a list of all libraries and licenses, allowing to filter, drill down and spot unwanted items; it is a useful tool to perform thorough checks and validate that policies have been correctly appied.

Reports > Ignored alerts, the list of alerts that have been ignored and the comments; this list must be periodically checked/updated by project leads and preferably kept empty.

Reports > Effective Licenses, the list of licenses that have been manually defined; this list must be periodically checked/updated by project leads and preferably kept empty.

Request access

In order to access the WhiteSource dashboard, you first need to be invited by Foundation Staff; open a HELP issue or send an email to help@finos.org, with the title Request access to WhiteSource and in the description specify:

  • the email address you'd like to use to login
  • the Foundation project you would like to scan with WhiteSource

If you login for the first time in WhiteSource and no project have been registered yet, the dashboard will look empty; check how to configure your build in order to upload your first project metrics.

Need help? Email help@finos.org we'll get back to you.

Content on this page is licensed under the CC BY 4.0 license.
Code on this page is licensed under the Apache 2.0 license.