| Table of Contents |
|---|
Overview
The WhiteSource Mend 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 Mend generates a library approval request (task). The WhiteSource Mend Unified Agent automatically scans the open-source library code for vulnerabilities and security issues, creating an update request.
...
NOTE: You can set up customized Workflow Rules for all or a selected list of WhiteSource Mend products or projects which will generate fix Pull Requests based on vulnerability severity or CVSS score. For details, see here.
How Do Policies Work?
When a new inventory request is uploaded to the WhiteSource Mend server, the policies mechanism is triggered. The open-source library code is automatically scanned to see exactly which licenses, libraries and security vulnerabilities are in the code. Security or compliance professionals can decide whether any new library that does not match an In-House or Whitelist rule should be permitted or not.
...
A policy check summary report of the results is generated in HTML and JSON formats (located in the whitesourceMend folder created in the directory from where the Agent was run) and can also be presented within the build server console via API.
...
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 | If the library matches an Approve policy action, the library will be automatically approved and the request will be closed. |
Reject | If the library matches a Reject policy action, the library will be automatically rejected and the request will be closed. NOTES:
|
Reassign | If there is a policy match on a Reassign action, the request will be automatically reassigned to a designated user or group in the system which is not the default approver. NOTE: The Open pending tasks for new libraries check box (Integrate tab > Advanced Settings) must be selected in order for tasks to be created. A new pending task will be created whether or not the library matches any of the policies. |
Conditions | If there is a policy match on a Conditions action, sub-tasks are automatically created as “conditions” for the different assignees according to the policy definition. NOTE: The Open pending tasks for new libraries check box (Integrate tab > Advanced Settings) must be selected in order for tasks to be created. A new pending task will be created whether or not the library matches any of the policies. Conditions will be automatically sent to assignees when libraries are matched. They can be assigned to a single user/group or to different members of a group/organization. The Conditions are added to the 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:
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 | Issue tracker integration. WhiteSource Mend can integrate with Issue tracking systems in order to automatically create issues in those systems when a policy match occurs. As a result, issues automatically open in the Issue tracking system and are automatically filled with the relevant WhiteSource Mend information required to mitigate the risks that triggered the creation of the issue. When a policy is matched with a library (as a result of a scan or when applying policy changes to existing inventory), an issue is created in the WhiteSource Mend application. The Jira plugins periodically query the WhiteSource Mend application for “Issue” matches. These matches represent issues that the plugin should create in Jira. A corresponding WhiteSource Mend issue (of type WS_Issue) is created in Jira for each match with all the relevant information in dedicated fields that can be sorted and filtered. The ticket created by WhiteSource Mend 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). NOTES:
|
Scope and Prioritization of Policies
WhiteSource Mend enables you to define a hierarchy for the policies in your organization according to the severity of rules in different projects and products.
...
The level at which a policy is applied dictates the order in which it will be checked by WhiteSourceMend. Project level policies have the highest priority; whereas, global organization policies have the lowest priority. For each level, the policy which is topmost in the list has the highest priority.
...
NOTE: A Product Admin has higher permissions than an ORG Admin, as project and product policies are the first policies that WhiteSource Mend 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 Mend policy, do as follows:
In the Policies page, click the Add Policy button. The Add Policy page is displayed.
Match your policy to a library. From the Match drop-down list, select the library type to which you want to match the policy.
Specify the action to be performed on the matched library. In the Action section, click the action you want to apply to the library.
Click the Add button to revert to the Policies page showing the newly-created policy.
If required, you can reorder the policy according to priority by selecting it and clicking the Raise Priority/Lower Priority buttons.
...
The following use case examples illustrate how you can use WhiteSource Mend policies to test the security of your open source code after scanning it.
...
Use Case 2: Ticket Creation Workflow
WhiteSource Mend integrates with Issue tracking systems to automatically create tickets for tracking issues in those systems when a policy match occurs. As a result, issues automatically open in the Issue tracking system and are automatically filled with the relevant WhiteSource Mend information required to mitigate the risks that triggered the creation of the issue.
This use case provides an example of a ticket creation flow from the time a high-security vulnerability (as defined by the NVD) is discovered when scanning the user’s open source library code. This high security vulnerability needs to be fixed in the user’s code. An issue is created in the WhiteSource Mend application. The plugins will fetch this information and create the corresponding issue in a Jira project which can be assigned to the relevant team in your organization. This allows you to seamlessly integrate remediation tasks into your development process.
NOTE: Jira policies created in WhiteSource Mend will only take effect once the plugin has been set up by your administrator. For details, see Issue Tracker Integration Generic Platform and Plugins .
To create an issue in JIRA that can be managed externally to WhiteSourceMend, do as follows:
In the Policies page, click the Add Policy button.
Create the required policy and select the Issue action.
Select the Fail plugin policy check check box if you want to fail the scanned policies that have the Reject action type according to the Unified Agent configuration, before they are uploaded to the WhiteSource Mend server.
In the Issue Settings, select the Tracker Type as Issue Tracker Plugin.
Click Add to revert to the Policies page showing the issue created in WhiteSourceMend.
In the Jira itself, the issue will describe the level and match type of the policy, including the organization, product and project to which the library belongs. Additional information will also be displayed that helps to identify why this library matched the policy (in this example, since the policy match type was High Severity Vulnerability, the vulnerability severity and link appears).
...
This example illustrates how you can accomplish tiered policy enforcement by creating a different WhiteSource Mend product for each phase of the SDLC. For example, say you have an ERP product that uses an artifact repository to store its open source components, a CI (build) server to continuously run team builds, and a CI server build for deployment - you can use WhiteSource Mend policies to govern each of these products differently.
...
All of these connections can (and should) be done with WhiteSource Mend native plugins.
Setting Up the Policies
...
As described previously, your WhiteSource Mend Inventory is intended to be an accurate representation of your open source liabilities - both from security and legal perspectives. In order to remediate appropriately, it is important to control which libraries are approved and which are rejected.
As a general rule, WhiteSource Mend promotes the shift-left strategy which preempts the introduction of problematic dependencies long before they reach the build stage, using Advise for Chrome/Edge, IDE integrations: Intellij, Eclipse, Visual Studio, and GitHub/GitLab integrations. However, policies are an equally powerful last defense against introducing recently discovered vulnerabilities into your code.
...
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.
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!
Enable 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…
Create a group(s) of users as necessary that should review the 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 tasks. Groups are more easily administered and as such, they are more highly recommended than individual user assignments.Consult with a legal expert and approve any licenses that are deemed permissible. This will help to resolve any tasks for new libraries.
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.
Establish organization-level policies and only use product and project-level policies where there are exceptions, to limit complexity.
“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 the Mend web application.
For a detailed explanation of the Unified Agent's configuration parameters, please refer to the Policies section in Unified Agent Overview.
...