Manage your open source usage and security in your pipeline
The open source approach has a tremendous value for us as a technological community. The collaborative development model helps the industry evolve rapidly, increase innovation and save time and money. We all use open source components in our applications, front or back end, JavaScript, .NET or Python, whether it is a JSON serialization library or a feature flags implementation, there are libraries out there for any technology stack and for every use case, the list is nearly infinite.
But as blessed as it is …
- Can we trust each and every library we use?
- Do those libraries align with our organization security standards?
- Do we accept all types of open source licenses?
- And do we even track which OSS components get into our systems?
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
WhiteSource core features
Open Source Security
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.
Open Source License Compliance management
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.
Shift Left Your Open Source Management
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.
Open Source Inventory management
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.
Bug Tracking
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.
WHY it’s important for us?
- Deliver secure and quality products to our customers
- Identify security issues in our own open source projects (reported by the community)
- Avoid potential legal incidents with license management
- Automation over manual processes
- Managed inventory
- Security and legal gates for open source libraries by using approve/reject policies, alerts and scheduled reports
- Automate the entire process of approving new open source components therefore saving time and resources
- Shift left approach
- Catch bugs and security vulnerabilities early in the development or build phases with minimum to zero false alarms
- One tool to rule them all
- As a heterogeneous, technology-wise team, we need a solution that Supports ALL languages and tools
How can you implement it in your pipeline?
Corresponding with the “shift left”/early feedback principal of the DevOps movement, WhiteSource offers you four options (from “left to right”):
- The Selection Tool
A Browser plugin to help developers choose the best open source components for their product. The selection tool will show your developers all required information on each component, including if it meets your company policy, while they are browsing open source repositories like NuGet or npm. - Repositories
Block the usage of packages not meeting your products’ open source policy with Artifactory, Inedo ProGet or GitHub integration. - On-demand Scan
Using Maven, npm, Gradle or any of the other available plugins, you can scan your packages on demand to get a complete analysis report covering all security, legal and quality aspects. - CI servers
Detect vulnerable components in your build every time a developer commits and adds a new package. Note that WhiteSource doesn’t scan your code, but only calculates a SHA-1 hash to identify the package and pulls all relevant information from their database. So, if you are scanning your bin folder your binaries will not be sent to WhiteSource. Check out the fantastic and well-documented VSTS/TFS extension available in VSTS Marketplace. - Post Deployment
WhiteSource continues to monitor the last build of every product version even after it’s released. The reason is that many security vulnerabilities are discovered months or even years after an OSS component is released. WhiteSource can alert you to issues that show up when new vulnerabilities are discovered so you can take the appropriate actions.
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.
Step I: Install the extension
You can find the extension and all the installation details here: WhiteSource VSTS/TFS extension
Step II: Create and configure the WhiteSource build step in your build definition
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. |
Step III
After the information is sent to our WhiteSource account, users authorized to manage open source security issues within WhiteSource can check the account for:
- Automatic alerts on security vulnerabilities
- Policy violations such as license compliance or any other predefined rules
- Newly-introduced bugs and more
Hierarchies in WhiteSource
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 |
Useful tips
- To associate a build run with WhiteSource to quickly identify who introduced a new issue, see Approach 2 and Product custom attributes.
- Choose one admin who makes sure that issues are being resolved.
FYI - Screenshots of WhiteSource dashboards of all hierarchy levels
Organization view:
Product view:
Project view:
Resources
- WhiteSource TFS plugin
- WhiteSource extension in VSTS Marketplace
- Feel free to reach out to support@whitesourcesoftware.com with any technical question
Authors: Jeff Bramwell and Shmulik Ahituv