This page provides WhiteSource notices for its customers.
To ensure that you remain updated, WhiteSource recommends that you subscribe to the Customer Community Portal Announcements section in order to receive immediate email notifications on important announcements, and follow the biweekly release notes.
File System Agent
The WhiteSource File System Agent (FSA) has been renamed to the WhiteSource Unified Agent.
The name of the Sun license was changed to Sun Public License. (21.3.2, 4/11/21)
New and/or Modified Documentation
New API Documentation (version 21.6.3)
New and updated documentation has been published for Reports APIs and Licenses and Library APIs.
New API Documentation (version 21.6.2)
New and updated documentation has been published for Alerts APIs and Groups and Users APIs.
New AVM Documentation (version 21.6.2)
New and updated AVM documentation has been published.
Unified Agent Parameter Merging (version 21.4.2)
Beginning in this version, nuget.runPreStep and nuget.restoreDependencies will be combined. This works the following way: if nuget.runPreStep = true, then dotnet restore will be performed on found .csproj files. As a result of this merge, nuget.restoreDependencies will be deprecated.
New Unified Agent Documentation (version 20.10.2)
Beginning in version 20.10.2, a modified and updated Unified Agent documentation repository has been launched, with the intent to increase usability, update existing content, fill in missing gaps, and create a linear flow.
The documentation is now spread over 4 contiguous topics (pages), in this order:
An overview page – this text will replace the current text on the page in Confluence to which the Web GUI links, so there will be no issues with broken bookmarks, missing pages, SEO issues etc. This page will also provide links to the following three topics listed here.
A Getting Started page, with prereqs, download info, config info, etc
A Parameters page
Advanced Topics (similar to an appendix)
New Policies Documentation (version 20.10.2)
Beginning in version 20.10.2 (approximate release - November 8), a modified Policies page has been launched, with the intent to update existing content, fill in missing gaps, and create a linear flow.
This page merges the two existing policies topics - Automated Policies and Managing Policies Throughout Your SDLC. The latter has been archived and therefore no longer in use.
Notices of Deprecation
The contents of the following topics will be moved. The pages of those topics will be deprecated. Note that after being moved, no changes to the information contained will be made
The contents of Triggering a new Scan in Bitbucket will be moved to WhiteSource for Bitbucket Server.
The following pages were deprecated:
In the Image Registries section:
UA - Amazon Elastic Container Registry (ECR) - Docker Integration
UA - Azure Container Registry Integration
UA - Docker Image Integration
UA - Google Container Registry Docker Integration
UA - JFrog Artifactory Docker Registry Integration
In the AVM section:
Migrating Fortify/ThreadFix Agent to the AVM Agent
Beginning in this version the following pages were archived and are therefore no longer in use:
Requesting an Arbitrary File
GitHub Related Topics
The License Identification page - its content was merged with Changing a Library’s License
TheLicense Analysis page - its content was merged with Understanding Risk Score Attribution
The Policies API page has been deprecated, and a new and updated Policies API page has replaced it.
Beginning in this version the following pages were archived and are therefore no longer in use:
High Severity Bugs Report
Automate the Process by Using the Unified Agent
Deprecated Features was deprecated and the content was moved to the Notices page
Setting the Home Page was deprecated and the content was moved to the WhiteSource Home Page topic.
Beginning in this version the following page was archived and is therefore no longer in use.
WhiteSource Advise for Visual Studio Codespaces
Beginning in this version the following page was archived and is therefore no longer in use.
Fortify Software Security Center Integration
Beginning in this version the following integration pages were archived and are therefore no longer in use. The material contained therein is contained in the Unified Agent parameter documentation.
Selecting a Plugin for Integration
Providing only a Project name in a Unified Agent Scan
Configuration Recommendation Mode
Unified Agent Scan Steps and Summary
Unified Agent JSON Report Example
The following topics have been completely deprecated and are therefore no longer in use:
Fortify Software Security Center Integration
Beginning in version 20.12.2 the following integration pages were archived and are therefore no longer in use. The material contained therein is contained in the Unified Agent parameter documentation.
Beginning in version 20.12.1 the following integration pages will be archived and therefore no longer be in use. The material contained therein is contained in the Unified Agent parameter documentation.
Additionally, the following pages will be archived:
Previous Versions of the Unified Agent
Previous GitHub Integration
TeamCity Plugin End-of-Life
The TeamCity plugin will reach its End Of Life starting November 1, 2021. After this date, WhiteSource will no longer provide standard support, including updates and fixes, for the deprecated plugin. Extended Support, which is limited to configuration and Support troubleshooting, will continue until May 1, 2022. Following this date, the TeamCity plugin will no longer be supported by WhiteSource. Please make sure to migrate to the Unified Agent before the end of standard support on November 1, 2021 to maintain full support o
API Version 1.0 and Below
Beginning on February 15, 2020, WhiteSource will deprecate API version 1.0 and below for new developments to make way for the more advanced and secure versions 1.1, 1.2 and 1.3. Support for 1.0 versions and below will end six months from that date (August 15, 2020).
Additionally, on February 15, 2020, WhiteSource will begin enforcing the quota limits for API usage per customer according to the contract. Please prepare accordingly for these changes. For any questions or concerns, contact WhiteSource support.
IntelliJ Old Plugin End of Life
On July 12, 2020, WhiteSource will deprecate the old plugin version of WhiteSource Advise for IntelliJ (see here).
A new WhiteSource Advise plugin is already available directly from the IntelliJ IDEA Marketplace (see here), which besides offering the same features as the old plugin, includes functionality improvements as well as performance-related enhancements.
Please make sure to migrate to the new plugin by deleting the old plugin and then only installing the new one. See our documentation for more information.
NuGet Plugin End of Life
With the wide functionality of the WhiteSource Unified Agent providing support for more than 200 languages, the NuGet plugin will reach its End Of Life starting October 1, 2020.
After this date, WhiteSource will no longer provide standard support, including updates and fixes, for the deprecated plugin. Extended Support, which is limited to configuration and Support troubleshooting, will continue until April 1, 2021. Following this date, the NuGet plugin will no longer be supported by WhiteSource. Please make sure to migrate to the Unified Agent before the end of standard support on October 1, 2020 to maintain full support of your product.
Jfrog Xray Integration Support
JFrog's vulnerability data integration strategy has changed: Integration with third-party providers of solutions that scan open-source libraries will no longer be available. Therefore, WhiteSource’s Xray Integration will be deprecated.
Shared customers integrating Xray with WhiteSource will no longer be supported or maintained by JFrog. Note that existing integrations with JFrog Artifactory (independent of JFrog Xray) are not affected.WhiteSource invites you to continue to use its variety of supported integrations for detecting vulnerabilities in open-source software. For more information, contact firstname.lastname@example.org.
NPM and Maven GitHub Repositories - Visibility Change
Following the deprecation of NPM and Maven Plugins, the visibility of existing GitHub repositories was changed to 'private'.
Deprecation of the Vulnerable Methods
In some cases, vulnerabilities are fixed by the deprecation of the vulnerable classes or methods. To that extent, WhiteSource, as other official advisories, will mark the vulnerabilities as fixed with the relevant version. In these cases, the vulnerabilities are fixed by adding "@Deprecated" to the vulnerable method.
In version 21.2.2, a newparameter, fileSystemScan, replaces the deprecated ignoreSourceFiles.
Azure DevOps Services Integration
Major improvements to the Azure DevOps integration have been introduced. The underlying scanning mechanism has been modified to allow a direct WhiteSource scan from within the Azure DevOps pipeline. As part of this change, the following updates have been introduced:
The extension activation procedure has been moved to the Organization settings section by navigating to Organization settings > Extensions > WhiteSource page.
The WhiteSource tab under Project > Pipelines has been deprecated.
The WhiteSource Open Source Risk Report is available at the Azure DevOps build level only, deprecating the project level aggregated report.
The direct WhiteSource scan from within the Azure DevOps pipeline is now the only scanning option.
GO Scan Results
There are three main challenges that should be taken into consideration in order to understand WhiteSource’s support for GO projects:
Commits are pushed to GO repositories at a high rate (several times per day).
GO repositories are relatively large in size.
GO provides an option to use the “latest” package, meaning the latest commit pushed to the repository.
The combination of these three factors create difficulty when scanning GO projects, and retrieving the exact commit that was used would cause WhiteSource scans for GO projects to take an exceptionally long time.
In order to overcome the challenges described above, whenever the given SHA-1 isn’t immediately recognized by WhiteSource, an approximate result is provided while WhiteSource imports the exact requested commit. Whenever a library displayed in the WhiteSource UI as an approximated result, it will be displayed as such with a disclaimer in the library details page while the exact commit is imported in the background. Once the exact commit is imported, it will automatically replace the approximate result in your inventory.
In the next Unified Agent release, the behavior of the includes and excludes and parameters will be fixed with respect to the use of the projectPerFolder parameter by matching their values relative to the main root path.
Within the next two releases of the Unified Agent, several improvements to the default configuration will be introduced:
The includes parameter will have a default value (comprises of all the WhiteSource supported extensions) that will be applied to all the Unified Agent's configuration methods (environment variables, config file, etc)
The excludes parameter will have a default value of **/.*, **/node_modules, **/src/test, **/testdata, **/*sources.jar, **/*javadoc.jar
Within the next two releases of the Unified Agent, the Go dependencies detection will be improved by enabling the optimized resolver for Go Modules by default. In addition, the Go resolution will no longer be triggered by Go source files and will be aligned to the other resolvers to be triggered only by the package managers' manifest files.
Starting August 1, Unified Agent versions will be available for a year after their release.
Within the next two releases of the Unified Agent, the default value of the php.removeDuplicateDependencies parameter will be changed from false to true.
Within the next two releases of the Unified Agent, the gradle.additionalArguments parameter for specifying additional arguments to be added to the Gradle commands executed by the agent - will be applied to all Gradle commands (not only to the gradle dependencies command).
Within the next two releases of the Unified Agent, the Maven, OCaml, Modules and the R resolvers will be aligned to the behavior of the other detectors when failErrorLevel is set to ALL by failing the scan if the relevant package manager is not installed.
Notice for Customers Using the Direct Link to Download the Unified Agent .jar File
Note that beginning in release 19.7.1 only the new Unified Agent .jar download link will be operational.
If you are using PowerShell, you might encounter an issue where downloading files from GitHub.com fails with HTTP 403 when going through BITS, and a signed URL is required. Refer here for a description of the issue and the solution.
Contact WhiteSource Support if further assistance is needed.
Spring HTTP Invokers
Note to Customers: Spring has announced that vulnerability CVE-2016-1000027, found in version 4.1, will not be fixed for future versions. For more information, please see below.
Spring HTTP invokers are both lightweight protocols that use their own slim serialization mechanisms and use the standard Java serialization mechanism to expose services through HTTP. This has a huge advantage if your arguments and return types are complex types that cannot be serialized by using the serialization mechanisms Hessian uses (see the next section for more considerations when you choose a remoting technology).
Under the hood, Spring uses either the standard facilities provided by the JDK or Apache HttpComponents to perform HTTP calls. If you need more advanced and easier-to-use functionality, use the latter. See hc.apache.org/httpcomponents-client-ga/ for more information.
Be aware of vulnerabilities due to unsafe Java deserialization: Manipulated input streams can lead to unwanted code execution on the server during the deserialization step. As a consequence, do not expose HTTP invoker endpoints to untrusted clients. Rather, expose them only between your own services. In general, we strongly recommend using any other message format (such as JSON) instead.
The issues mentioned above refer to several names and versions of NuGet packages containing vulnerable DLL libraries, along with the NuGet package versions containing a fixed DLL library. However, according to their SHA-1 identifiers, some of the vulnerable DLL libraries still exist in other directories of the fixed NuGet packages. Therefore, the fixed version for each NuGet package refers to a package that isn'tunconditionally vulnerable, but ispotentially vulnerable depending on the specifications of the run-time environment.
Taking into consideration the fact that the vulnerable DLL libraries may still be loaded and that WhiteSource retrieves the SHA-1 identifiers of the DLL libraries after the NuGet package is built, the vulnerabilities mentioned above will continue to be reported by WhiteSource so users can ensure their environment isn't vulnerable.
According to Microsoft, the vulnerability found in CVE-2017-0247, referring to the vulnerable DLL library with the SHA-1 identifier below, was present in versions 4.0.1 and 4.3.0, and fixed in versions 4.0.2 and 4.3.1 of the 'System.Net.Http.WinHttpHandler' NuGet package. However, you can see below that version 4.4.0 of the 'System.Net.Http.WinHttpHandler' NuGet package still contains the vulnerable DLL files.
Version 4.3.0 of System.Net.Http.WinHttpHandler NuGet package:
Version 4.4.0 of 'System.Net.Http.WinHttpHandler' NuGet package:
CVE and WS Vulnerability Identifiers
As many of you know, OSS vulnerabilities are published in multiple advisories.The National Vulnerability Database (NVD) is commonly acknowledged as a primary database for known security vulnerabilities but has been arguably slow in adopting data from advisories. In order to attain broader coverage of reported security vulnerabilities, WhiteSource has not been relying solely on the NVD but has been reviewing vulnerability data from dozens of additional sources as well. Whereas the NVD publishes security vulnerabilities using a "CVE-" prefixed identifier, WhiteSource classifies non-NVD security vulnerabilities using a "WS-" prefix.Recently, we have noticed that the NVD features support for additional sources, potentially enabling it to encompass security vulnerabilities that are already flagged by WhiteSource using a designated "WS-" identifier.
What is being changed?
To avoid duplicate, redundant identifiers for vulnerabilities (i.e., "WS-" and "CVE-" entries that refer to the same vulnerability), WhiteSource will replace non-NVD, "WS-" entries with the corresponding NVD, "CVE-" entries featuring associated CVE metadata, thereby enabling customers to benefit from the extended coverage of pertinent vulnerabilities directly from the NVD. The new CVEs were assigned by NVD with a “CVE-2018-” prefix.
Are my reports or alerts affected?
(npm packages only) Customers may notice that some or all of the "WS-" entries previously featured in WhiteSource displays and reports are no longer listed in their inventory. Such "WS-" entries are now listed with corresponding "CVE-" identifiers and feature the vulnerability metadata from the NVD.For these vulnerabilities, the severity and score may change.New alerts associated with vulnerabilities that were previously marked using a "WS-" identifier will be triggered as well with "CVE-" information.
HTTP/2 Denial of Service Vulnerabilities
HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. The HTTP/2 specification was published as RFC 7540 in May 2015. HTTP/2 makes our applications faster, simpler, and more robust by allowing us to undo many of the HTTP/1.1 workarounds previously done within our applications and address these concerns within the transport layer itself. Even better, it also opens up a number of entirely new opportunities to optimize our applications and improve performance!
The primary goals for HTTP/2 are to reduce latency by enabling full request and response multiplexing, minimize protocol overhead via efficient compression of HTTP header fields, and add support for request prioritization and server push. To implement these requirements, there is a large supporting cast of other protocol enhancements, such as new flow control, error handling, and upgrade mechanisms, but these are the most important features that every web developer should understand and leverage in their applications.
HTTP/2 does not modify the application semantics of HTTP in any way. All the core concepts, such as HTTP methods, status codes, URIs, and header fields, remain in place. Instead, HTTP/2 modifies how the data is formatted (framed) and transported between the client and server, both of which manage the entire process, and hides all the complexity from our applications within the new framing layer. As a result, all existing applications can be delivered without modification.
Denial of Service Vulnerabilities Discovery
Netflix has discovered several resource exhaustion vectors affecting a variety of third-party HTTP/2 implementations. These attack vectors can be used to launch DoS attacks against servers that support HTTP/2 communication. Netflix worked with Google and CERT/CC to coordinate disclosure to the Internet community. A number of vendors have announced patches to correct this suboptimal behavior.
There are three broad areas of information security: confidentiality (information can’t be read by unauthorized people), integrity (information can’t be changed by unauthorized people), and availability (information and systems are available when you want them). All of the changes announced today are in the “availability” category. These HTTP/2 vulnerabilities do not allow an attacker to leak or modify information.
Rather, they allow a small number of low bandwidth malicious sessions to prevent connection participants from doing additional work. These attacks are likely to exhaust resources such that other connections or processes on the same machine may also be impacted or crash.
CVE-2019-9511 “Data Dribble”: The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service. CVSS 3.x Score: 7.5 HIGH
CVE-2019-9512 “Ping Flood”: The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service. CVSS 3.x Score: 7.5 HIGH
CVE-2019-9513 “Resource Loop”: The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU, potentially leading to a denial of service. CVSS 3.x Score: 7.5 HIGH
CVE-2019-9514 “Reset Flood”: The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both, potentially leading to a denial of service. CVSS 3.x Score: 7.5 HIGH
CVE-2019-9515 “Settings Flood”: The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service. CVSS 3.x Score: 7.5 HIGH
CVE-2019-9516 “0-Length Headers Leak”: The attacker sends a stream of headers with a 0-length header name and 0-length header value, optionally Huffman encoded into 1-byte or greater headers. Some implementations allocate memory for these headers and keep the allocation alive until the session dies. This can consume excess memory, potentially leading to a denial of service. CVSS 3.x Score: 7.5 HIGH
CVE-2019-9517 “Internal Data Buffering”: The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both, potentially leading to a denial of service. CVSS 3.x Score: 7.5 HIGH
CVE-2019-9518 “Empty Frames Flood”: The attacker sends a stream of frames with an empty payload and without the end-of-stream flag. These frames can be DATA, HEADERS, CONTINUATION and/or PUSH_PROMISE. The peer spends time processing each frame disproportionate to attack bandwidth. This can consume excess CPU, potentially leading to a denial of service. CVSS 3.x Score: 7.5 HIGH
Occasionally, NuGet packages that do not contain vulnerable elements are marked as vulnerable by multiple Microsoft advisories. This occurs for one of two reasons:
The package is a metapackage. A metapackage is a package that does not contain any code, but only references other packages. Due to the fact that the package does not contain any code, the package itself cannot contain any vulnerable elements and WhiteSource will not display any vulnerable elements.
For example, according to this Microsoft Advisory, Microsoft.NETCore.App is vulnerable to CVE-2020-0603. However, this is only the case because Microsoft.NETCore.App references Microsoft.AspNetCore.All and Microsoft.AspNetCore.App which are the actual vulnerable packages. Microsoft.NETCore.App itself does not include any actual vulnerable code, and therefore will not be marked as vulnerable by WhiteSource.
The package is only vulnerable if you are using a specific runtime dependency.
For example, according to this Microsoft advisory, Microsoft.AspNetCore.Mvc is vulnerable. However, when comparing the vulnerable and fixed versions of Microsoft.AspNetCore.Mvc, you can see that they contain the same exact code implementation, meaning no vulnerable code exists in the Dlls within this package, but rather in the runtime dependencies it utilizes.
WhiteSource contacted Microsoft officials regarding the above, and Microsoft officials verified that WhiteSource’s analysis is correct. Microsoft treats the cases mentioned above as vulnerable in order to raise awareness. Microsoft encourages updating the metapackage to ensure all vulnerable dependencies are updated, rather than updating only specific packages. The same approach is encouraged for runtime dependencies, where Microsoft encourages updating the entire runtime crucial environment packages, rather than referring to specific packages.
Major improvements to the Azure DevOps integration will be introduced in July 2021. The underlying scanning mechanism will be modified to allow a direct WhiteSource scan from within the Azure DevOps pipeline. As part of this change, the following updates will be introduced:
The extension activation procedure will be moved to the Organization settings section by navigating to Organization settings > Extensions > WhiteSource page.
The WhiteSource tab under Project > Pipelines will be deprecated.
The WhiteSource Open Source Risk Report will be available at the Azure DevOps build level only, deprecating the project level aggregated report.
The direct WhiteSource scan from within the Azure DevOps pipeline will be the only scanning option.