Versions Compared

Key

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

 OverviewOverview

The WhiteSource platform enables security and compliance professionals to enforce policies automatically throughout their Software Development Life Cycle.

...

For every new library that is added to a project, WhiteSource generates a library approval request (pending task). The WhiteSource Unified Agent automatically scans the open-source library code for vulnerabilities and security issues, creating an update request.

...

According to the user-defined match and actions, a policy can be configured to approve or reject the library, depending de on its level of risk.

NOTE: You can set up customized Workflow Rules for all or a selected list of WhiteSource products or projects which will generate fix Pull Requests based on vulnerability severity or CVSS score. For details, see here.

...

Each organization can decide its own policies (at the organizational, product or project level) about which security issues and vulnerabilities are acceptable or not, depending de on their severity level, and which specific actions should be taken to handle them. For example, if the policy matches a library that contains specific licenses, you can approve or automatically reject it. 

...

Applying Actions to a Library

The Action is the operation the policy runs on a matched library.

NOTE: A library or request can be matched to only one type and execute only one action.

You can apply one of the following actions on a matched library:

Action

Description

Approve

Automatically approves the library.

The request will be automatically closed.

Reject

Automatically rejects the library:

  • By default, a Policy Violation alert is created in the system.

  • In the case of a policy violation, the build will fail (if the build server is configured to do this).

Reassign

Workflow - reassigns the request to a designated user or group in the system which is not the default approver.

NOTE: For a Reassign action to take effect, the Open pending tasks for new libraries check box (Integrate tab > Advanced Settings) must be selected.

Conditions

Workflow - automatically assigns conditions and open tasks on libraries.

NOTE: For a Conditions action to take effect, the Open pending tasks for new libraries check box (Integrate tab > Advanced Settings) must be selected.

A request is opened for the default approver and sub-tasks are opened as “conditions” for the different assignees according to the policy definition. Conditions will be automatically sent to assignees when libraries are matched.

Conditions can be assigned to a single user/group or to different members of a group/organization.

The Conditions are added to the Pending Tasks panel and the Request Details page where assignees can view the original library request and update the status of the conditions after handling their assigned conditions.

By clicking one of the following check boxes, you can choose to set conditions to trigger the automatic approval or rejection of the original request based on the resolution of the relevant assignees:

  • Automatically approve when all conditions are satisfied

  • Automatically reject when one condition is rejected

The assignee can mark the condition as Satisfied or Rejected. The assignee can also suggest to the approver another user to review the condition, by clicking Propose Reassignment. Only the approver is allowed to change assignees.

The Default Approver can perform the following actions on conditions: Edit, Reassign, Override and Approve, or Override and Reject.

Issue

Workflow: Issue tracker integration.

WhiteSource policies can integrate with Ticket Management Systems (such as, JIRA or Work Items), enabling the automatic creation of tickets for tracking issues. When scanning the open source code, if vulnerabilities are found that need fixing, a ticket is automatically created in the issue tracker with all relevant information, addressed to the specific developers that need to fix the issue. After resolving the issue, the Security officer must check that the risk was mitigated.

NOTE: For an Issue action to take effect, the Open pending tasks for new libraries check box (Integrate tab > Advanced Settings) must be selected.

When creating an ‘Issue’ policy you can select the Jira Project to open the issue for the Issue Type (such as, bug), Priority and Assignee.

The JIRA describes the level and match type of the policy, including the organization, product and project to which the library belongs. Additional information is also displayed that can help to identify why this library matched the policy (for example, if the policy match type is high severity vulnerability, the vulnerability severity and link will appear).

When working with JIRA, if the issue type in the project requires mandatory fields, those fields are displayed and must be filled in.

NOTES:

  • After Jira issues are created, there are no further updates between WhiteSource and JIRA. If the issue status is changed (for example, Done/Obsolete) it will not be updated in WhiteSource. If the policy changes or the project is deleted, the issue will remain in JIRA and will not be closed by WhiteSource.

  • Information about created issues is stored in the WhiteSource database and is used to prevent creating duplicate issues for the same library and policy name in a specific project. If the policy name is modified, another JIRA issue will be created when the mechanism is triggered.  

...

NOTE: A Product Admin has higher permissions than an ORG Admin, as project and product policies are the first policies that WhiteSource will look at for a match.

Managing Policies

Organizational policies are managed via the Policies menu item from the main menu. 

In the Policies page, you can view, add, edit, change the priority of, enable/disable, and remove policies.

Product-level policies are available for products that want to set their own policies which override the organizational ones. Product policies are managed from the product page, under the Policies button.

...

Creating a New Policy

To create a new WhiteSource policy, do as follows:

  1. In the Policies page, click the Add Policy button. The Add Policy page is displayed.

  2. Match your policy to a library. From the Match drop-down list, select the library type to which you want to match the policy. 

  3. Specify the action to be performed on the matched library. In the Action section, click the action you want to apply to the library. 

  4. Click the Add button to revert to the Policies page showing the newly-created policy.

  5. If required, you can reorder the policy according to priority by selecting it and clicking the Raise Priority/Lower Priority buttons. 

...

  • You can apply newly created policies to pending requests by clicking Apply to Pending Requests. This action will apply them only to pending requests, and not to approved inventory items.

  • If there are new libraries that do not match a policy and the Open pending tasks for new libraries check box (Integrate tab > Advanced Settings) is selected, a new task will be created for the Default Approver.

  • By clicking Apply to Existing Inventory, you can apply newly created policies that have been assigned the Approve, Reject or Issue actions, to the existing inventory. 

...

  1. Reject libraries with vulnerabilities.

    • Any vulnerability can be exploited, so we cannot recommend a “minimum level.” You will need to decide for yourself how to set this, but you can always start with High Severity vulnerabilities and create policies down the line for less severe vulnerabilities.

  2. Consult with a legal expert and reject any licenses that are too restrictive.

    • Again, while we cannot provide legal advice, Risk Scores are available for a subset of licenses - determined by legal experts that specialize in open source compliance, so that is a good place to start!

  3. Enable pending tasks to ensure that any new libraries which are introduced are subject to manual review, if they are not resolved by the existing policies. And then…

  4. Create a group(s) of users as necessary that should review the pending tasks and assign the these users to the relevant Products (via Product>>Product Default Approvers) . These groups should be restricted to personnel with the authority to make decisions, such as security experts, managers or team leaders. The more you delegate to reviewers, the more visibility you will have, resulting in fewer neglected pending tasks. Groups are more easily administered and as such, they are more highly recommended than individual user assignments.

  5. Consult with a legal expert and approve any licenses that are deemed permissible. This will help to resolve any pending tasks for new libraries.

  6. Ensure that the order of your policies correctly reflect the Priority you require. The higher the policy on the list, the higher the priority. A library will be subject to the first policy it matches.

  7. Establish organization-level policies and only use product and project-level policies where there are exceptions, to limit complexity. 

  8. Issue” policies at the product or project-level that create JIRA or Work Item tickets can be assigned to the relevant team in your organization. This allows you to seamlessly integrate remediation tasks into your development process.   

Unified Agent 

The Unified Agent is a Java command-line tool that scans directories' open source components for vulnerable libraries and source files, as well as license compliance, and uploads the results to the WhiteSource web application. 

...