What a WhiteSource Scan Actually Checks (and How Mend Changed It)

A WhiteSource scan is a software composition analysis (SCA) run that builds an inventory of every open source component your project pulls in, then matches those components against databases of known vulnerabilities and license obligations. If you inherited a pipeline that still says "WhiteSource" in the job name, the first thing to know is that WhiteSource rebranded as Mend.io on May 25, 2022. The engine and the mental model are the same; the name on the invoice changed.

This post walks through what a WhiteSource scan inspects, where it fits in a build, and the practical gotchas teams hit when they read the results for the first time.

What a WhiteSource scan is looking for

SCA tools do not read your business logic. They read your dependency graph. A WhiteSource scan resolves the packages declared in your manifests (package.json, pom.xml, requirements.txt, go.mod, and so on), walks the transitive tree, and produces two headline outputs:

• Known vulnerabilities. Each resolved component is checked against advisory sources such as the National Vulnerability Database and ecosystem-specific feeds. A hit means a CVE is associated with the exact version you resolved.
• License findings. Every component carries a license. The scan classifies those licenses and flags anything that conflicts with your policy, for example a copyleft license like GPL-3.0 landing in a product you ship as closed source.

The distinction that trips people up: a WhiteSource scan tells you a vulnerable version is present, not that it is reachable. A CVE in a transitive dependency you never call at runtime is still a real finding, but its priority differs from the same CVE in a package on your hot path. Reachability analysis is a separate, harder problem, and no SCA tool gets it perfect.

Where the scan runs

There are three common integration points, and most mature teams use more than one:

1. Repository integration. Mend connects to your SCM (the Mend for GitHub app is the modern equivalent of the old WhiteSource Bolt) and opens pull requests or checks as dependencies change.
2. CI pipeline step. A unified agent or CLI runs during the build, fails the job on policy violations, and publishes results to the dashboard.
3. Registry or artifact scan. The tool inspects built artifacts and containers rather than source.

Running the scan in CI is where it earns its keep. A build that fails on a newly disclosed critical CVE stops the regression before it reaches production. The tradeoff is noise: without tuned policies, a strict gate blocks releases on findings nobody can fix that day.

Reading the results without drowning

The first WhiteSource scan on a legacy repo often returns hundreds of findings. That number is not a crisis; it is a backlog. Triage in this order:

• Direct dependencies first. A vulnerable package you declared yourself is one you control. Bump it.
• Then transitive dependencies with a fix available. If an upstream release resolves the CVE, the fix is a version bump away, sometimes via an override.
• Defer findings with no fixed version and no runtime reachability. Track them, but do not let them block the pipeline.

License findings deserve their own pass. A single AGPL component in a distributed binary can carry more legal weight than a dozen medium-severity CVEs. Sort by license class, not just by count.

What the Mend rebrand actually changed

The rename was not cosmetic. Alongside the WhiteSource-to-Mend transition, the company added automated remediation, so the platform moved from "here is a list of problems" toward "here is a pull request that fixes them." For an existing SCA workflow, the operational impact is:

• Old whitesource CLI names and config keys map to newer Mend tooling; check the current docs before assuming a flag still exists.
• The SCA capability you relied on is intact; SAST and remediation features were layered on top.
• Documentation, support portals, and integration marketplace listings now use "Mend," which matters when you are searching for setup guides.

If your organization is comparing SCA vendors during a renewal, it is worth benchmarking Mend against alternatives on the axes that actually bite: transitive resolution accuracy, false-positive rate, and how cleanly the tool fits your CI. Our SCA product page breaks down what a modern composition scan should cover, and if you are running a formal bake-off, the Snyk comparison covers the same evaluation criteria.

Making the scan meaningful, not just present

A WhiteSource scan that runs but whose results nobody acts on is compliance theater. Three habits separate teams that get value from teams that just generate reports:

Set a policy that fails builds on new critical and high findings in direct dependencies, and only those, at first. Widen the gate as the backlog shrinks. A gate that blocks everything gets bypassed within a week.

Pin and update deliberately. Lockfiles make scans reproducible; without them, the same commit can resolve different versions on different days and your findings will flap. An SCA tool such as Mend can only be as accurate as the dependency graph you feed it.

Feed findings into one queue. Whether it is Jira, GitHub issues, or a security backlog, vulnerabilities that live only in the scanner dashboard get ignored. The teams that close findings are the ones who route them into the same workflow as their normal engineering work. If you are ramping up on SCA generally, our academy has a primer on building that triage loop.

FAQ

Is WhiteSource the same as Mend?

Yes. WhiteSource rebranded as Mend.io in May 2022. The software composition analysis engine you knew as WhiteSource is now part of the Mend Application Security Platform, with automated remediation added on top. Older job names and config referencing "whitesource" typically still describe the same scan.

Does a WhiteSource scan check my own code for bugs?

Not in the classic sense. SCA focuses on third-party open source components, their known CVEs, and their licenses. Scanning your first-party source for injection flaws or logic bugs is static application security testing (SAST), a separate capability that Mend added alongside SCA.

Why does my WhiteSource scan report vulnerabilities I cannot fix?

Many findings live in transitive dependencies with no patched release yet, or in code paths your app never exercises. These are real but low-priority. Track them, prioritize findings in direct dependencies with available fixes, and avoid blocking releases on issues with no available remediation.

Do I need a lockfile for accurate results?

Effectively yes. Lockfiles pin exact resolved versions, so the scan reports on the versions you actually ship. Without one, resolution can drift between runs and your vulnerability list will change even when your code does not.