Safeguard
AppSec

What Is a Mend Scan and How Does It Work?

A Mend scan analyzes your open-source dependencies and code for known vulnerabilities and license risk. Here is what it covers and how to run one in CI.

Marcus Chen
DevSecOps Engineer
6 min read

A Mend scan is a software composition analysis run that inventories your project's open-source dependencies, matches them against known vulnerability and license databases, and reports the CVEs and licensing risks you have inherited from third-party code. Mend, formerly known as WhiteSource, is a commercial application security vendor, and "Mend scan" usually refers to running its SCA — and increasingly its SAST — engine against a repository or build. This guide explains what such a scan actually does and how to fit it into a pipeline, whichever tool you land on.

What a dependency scan is really looking for

Most of the code in a modern application is not code your team wrote. A typical service pulls in hundreds of open-source packages transitively, and every one of them carries the vulnerability history of the project behind it. A composition scan exists to answer a deceptively simple question: given everything on my classpath or in my node_modules, which components have publicly disclosed vulnerabilities, and are any of them a licensing problem?

To do that, a Mend scan performs a few steps:

  1. Dependency resolution. It reads your manifests and lockfiles — pom.xml, package-lock.json, requirements.txt, and so on — and resolves the full dependency tree, including transitive dependencies you never named directly.
  2. Component identification. It fingerprints each resolved component down to its exact version.
  3. Vulnerability matching. It compares those components against vulnerability databases (the National Vulnerability Database and vendor-curated advisory feeds) to find known CVEs affecting those versions.
  4. License analysis. It identifies each component's license and flags terms that may conflict with your distribution model, such as copyleft licenses in a proprietary product.

Reachability and the transitive problem

The most valuable thing a good composition scan does is surface transitive risk. When your build fails a scan because of a vulnerable library you never added to your manifest, that library got pulled in by something you did add. Finding those chains by hand is impractical, which is the whole reason composition analysis is automated.

Mend's SCA, like its peers, resolves the full tree so a vulnerable transitive dependency several levels deep still gets caught. Some engines go further with reachability analysis — determining whether your code actually calls the vulnerable function — to prioritize findings you can genuinely be exploited through, rather than treating every CVE in every dependency as equally urgent. Reachability data is the difference between a report you can action and a report that overwhelms the team.

Running a scan in CI

A Mend scan is most useful when it runs automatically, not as a quarterly audit. The common pattern is a unified agent invoked during the build. The exact command depends on your license and setup, but the shape looks like this:

# Illustrative unified-agent invocation
java -jar wss-unified-agent.jar \
  -c ./wss-config.properties \
  -d ./my-project

The config file points at your organization token and defines policies — for example, fail the build if any critical-severity vulnerability or any GPL-licensed component is found. In a pull-request pipeline you typically want the scan to comment findings inline and block a merge only on new, high-severity issues so the historical backlog does not freeze development.

What a scan report gives you, and how to act on it

A composition scan report is essentially a prioritized list of "you are running version X of library Y, which has CVE-Z, and here is the fixed version." The remediation is almost always the same shape: upgrade the affected component to a patched release, or if you cannot upgrade directly, override the transitive version through your build tool's dependency management.

For a Maven project that means pinning the safe version in a dependencyManagement block. For npm it might mean an overrides entry. The scan tells you the target version; your job is to upgrade, run your tests, and re-scan to confirm the finding clears. Where a direct upgrade is not yet possible, document the risk acceptance with an expiry date rather than silently suppressing it.

Choosing and comparing SCA tools

Mend is one of several credible composition analysis platforms, alongside options like Snyk, and open-source scanners such as OWASP Dependency-Check and Trivy. When teams evaluate them, the differentiators that matter are advisory feed quality and freshness, reachability analysis, false-positive rate, and how cleanly the tool integrates into the SCM and CI they already use. Pricing models vary widely, so verify current terms directly with each vendor before committing.

If you are weighing options, our SCA product overview explains what to look for in a composition scanner, and the Snyk comparison breaks down how the commercial platforms differ on reachability and developer workflow. The right answer is usually the one that fits your existing pipeline with the least friction, because a scanner developers route around protects nothing.

Beyond dependencies

It is worth noting that Mend, like several vendors, has expanded beyond pure SCA into SAST and other categories. So "Mend scan" can mean a dependency scan, a static code scan, or both, depending on which product you have licensed. When someone hands you a "Mend finding," clarify whether it is a third-party CVE or a flaw in your own code, because the remediation paths are entirely different — one is an upgrade, the other is a code fix.

FAQ

Is Mend the same as WhiteSource?

Yes. Mend is the rebranded name of the vendor formerly called WhiteSource. A "Mend scan" and an older "WhiteSource scan" refer to the same lineage of tooling.

What does a Mend scan detect?

Its core capability is software composition analysis: it inventories open-source dependencies, flags known CVEs affecting the versions you use, and reports license risks. Mend also offers static analysis of your own code, so a scan may cover both depending on your license.

How do I fix a vulnerability a Mend scan finds?

Almost always by upgrading the flagged component to a patched version, or by overriding a vulnerable transitive dependency through your build tool's dependency management. Upgrade, run your tests, then re-scan to confirm the finding clears.

Is Mend free?

Mend is a commercial platform with paid tiers, though it has offered free capabilities for open-source projects. Verify current pricing and free-tier terms directly with the vendor, since these change over time. Open-source alternatives like OWASP Dependency-Check exist if budget is the constraint.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.