Ask Learn
Preview
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
But as blessed as it is …
The bigger your organization is, the harder it would be for you to answer these questions.
We asked ourselves these questions and ended up evaluating an open source management solution Called WhiteSource.
From WhiteSource VSTS/TFS extension page:
WhiteSource integrates with your CI servers, build tools and repositories to detect all open source components in your software, without ever scanning your code. It provides you with real-time alerts on vulnerable or problematic components, generates comprehensive up-to-date reports in one-click and enables you to streamline your entire open source management process with automated policies
Don’t ship your code to customers without knowing ALL security vulnerabilities.
WhiteSource helps you identify all vulnerable open source components in your products and they guarantee zero false-positives.
WhiteSource not only alerts you when a known open source security vulnerability is discovered, it also provides you with actionable suggestions on how to fix it, like links to patches, specific source files and updated versions, recommend code changes which block vulnerable methods and can even recommend changes to your system configuration that blocks exploitation.
When you use open source components, you sign implicit legal contracts. Every open source component, as well as any component on which it may depend, has a license with which you must comply under its own terms and conditions.
WhiteSource detects all licenses, including dependencies’ licenses, and automates all license documentation needed for deployment to save you time and hassle.
The earlier you find out about issues in your product the easier and less expensive it is to fix it. After all, who wants to find a sever bug in their code days, or even hours before release?
WhiteSource integrates throughout your software development lifecycle (SDLC) to alert you in real time on vulnerabilities and other issues to help you take immediate action.
In addition, WhiteSource offers a browser plugin that shows developers all required information on each component while they’re browsing online repositories like GitHub and NuGet. Developers can see if someone in their team is already using this component, whether it meets their organization’s policy, if it’s vulnerable and more.
Legal issues or just your CTO request?
One day, you will be asked to provide an open source inventory report, a detailed list of your open source components build of materials (BOM) in your code, including all dependencies and affiliated licenses. WhiteSource can generate comprehensive BOM reports for your last build and status of your repositories at any given moment with only one click.
WhiteSource can provide you with alerts on newly created bugs for OSS libraries in your inventory as well as the availability of new versions that resolve the issue(s). It also gives you a sort of a quality rate calculated by: bug statistics, fix rating and source control activity.
All the core features are backed up with automated policy enforcements, alerts and notifications, dashboards and reports.
Corresponding with the “shift left”/early feedback principal of the DevOps movement, WhiteSource offers you four options (from “left to right”):
We chose the most common approach: CI servers.
Below, we will list step-by-step instructions on how you can add these features to your VSTS pipeline.
NOTE: You must first create a WhiteSource account before you can use the VSTS/TFS extension to enable the WhiteSource scans.
You can find the extension and all the installation details here: WhiteSource VSTS/TFS extension
Add the WhiteSource build task to your build definition and fill in the remaining fields to configure it per the example below. Add the WhiteSource build step after the build steps that build your application, e.g. MSBuild, Maven, etc.
Parameter | Meaning |
Work directory | The path of the root directory which contains the desired files to scan.Recommended value: $(Build.SourceDirectory) |
Extension list | List of file extensions to scan (e.g. .dll, .js).
Common value for .NET and JavaScript build definitions: .dll, .js |
Check policies | Select whether to only send alerts or also to fail the build in case of policy failure.Recommended value: Send Alerts |
Product name or Token | Name or token to uniquely identify the product to update.Specify the name of the product (e.g. CountdownWidget) |
Product version | Version of the product to update. (Read the ‘Hierarchies in WhiteSource’ section below)
Recommended value: $(Build.BuildNumber) |
Requester email | Email address of the WhiteSource user that requests to update WhiteSource.
Recommended value: $(Build.RequestedForEmail) |
Project token | Unique identifier of the WhiteSource project to update. If omitted, the default naming convention will apply.
Recommended value: $(Build.DefinitionName) |
Force check all Dependencies | Policies will be checked only for new dependencies introduced to the project. |
Check only new libraries | Check that only newly-introduced open source libraries conform with organization policies. |
Fail on error | Indicates whether to fail the build on a general error (e.g. network error). Setting this to false means that the plugin will fail the build only for policy violations. |
After the information is sent to our WhiteSource account, users authorized to manage open source security issues within WhiteSource can check the account for:
Let’s quickly discuss the hierarchy of entities in a WhiteSource account.
The highest hierarchy level is organizationwhich is the equivalent of a collection in VSTS/TFS. One can have one or more organizations in their account (e.g. Visual Studio ALM Rangers & Payoneer).
The second Level is product which, you guessed it, is the equivalent of a team project. An organization can be associated with one or more products.
The third level is project which can be an application or a service.
Another approach and the recommend one with the same analogy would be:
One organization , same as a collection.
Product, can be mapped to an application or a service.
With this approach you can store custom attributes such as build URL and to store your product version.
Projects, Can be the latest build run (or job execution if you are Jenkins fans).
To summarize the Hierarchies approaches with our VSTS/TFS analogy:
WhiteSource | VSTS/TFS | |
Approach 1 | organizationproductproject | collectionteam projectproduct, solution |
Approach 2 (Recommended) | organizationproductproject | collectionproduct, solutionbuild, latest product state |
Organization view:
Product view:
Project view:
Authors: Jeff Bramwell and Shmulik Ahituv
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign in