If you're evaluating software composition analysis (SCA) tools, you've probably seen vendors cite "the Forrester Wave" as a credential. It's a legitimate and widely used analyst framework — but it's also frequently misquoted, cherry-picked, or cited out of date in vendor marketing. Before you let a Wave placement move a vendor to the top of your shortlist, it's worth understanding what the methodology actually measures, how often it's refreshed, and what it can't tell you.
This guide breaks down how the Forrester Wave methodology evaluates SCA vendors, what buyers should actually check before trusting a citation, and how Safeguard's architecture and approach to vulnerability data compare to Sonatype's on two dimensions you can verify yourself rather than take on faith. We are not asserting where any vendor currently sits on any Wave — reports age quickly and placements change between cycles. The goal here is to give you a framework for reading analyst reports critically, not to hand you a shortcut.
What Is the Forrester Wave, and Why Does It Matter for SCA Buyers?
The Forrester Wave is a comparative research methodology, not a single ranking. For each market segment Forrester covers — including software composition analysis — analysts define a set of weighted criteria across three buckets: current offering (product capabilities as they exist today), strategy (roadmap, vision, execution plan), and market presence (revenue, customer base, partner ecosystem). Vendors are scored against those criteria using a mix of vendor surveys, product demos, customer reference calls, and analyst testing, and the results are plotted on a quadrant chart with labels like Leaders, Strong Performers, Contenders, and Challengers.
Two things matter for buyers here. First, the criteria and their weights are set by Forrester for that specific report cycle — they can and do change between editions, so a vendor's position in a 2022 report is not directly comparable to a 2024 or 2025 report unless you check whether the underlying rubric changed. Second, Wave reports are point-in-time snapshots. SCA is a fast-moving category — reachability analysis, SBOM generation, malicious package detection, and AI-assisted remediation have all gone from "differentiator" to "table stakes" within a couple of report cycles. A placement that was accurate at publication can be stale within twelve months.
Because Wave methodology and eligibility criteria are periodically revised, and because we have not independently reviewed a specific current report for this piece, we're deliberately not citing a Sonatype placement here. If a vendor cites a Wave position to you, the burden is on them to show you the actual report, the publication date, and the criteria used — not just a badge on their homepage.
How Should You Read a Wave Report When Evaluating a Vendor Like Sonatype?
A few checks that separate a useful citation from a marketing graphic:
- Publication date. Ask when the report was published and whether Forrester has released a newer edition. SCA vendors ship features quickly; a two-year-old report may not reflect current capability.
- Scope of the report. Confirm the report is actually scoped to software composition analysis, and not a broader category (application security testing, or a combined AST suite) where SCA is only one scored sub-criterion.
- Access to the full report, not just the graphic. The quadrant image tells you almost nothing on its own. The narrative text explains why a vendor scored where it did — strengths, weaknesses, and the specific criteria that moved the needle. Most vendors will provide a licensed copy of the report on request.
- Criteria weighting. If your organization cares most about remediation guidance and CI/CD integration depth, but the report weights market presence and channel partnerships heavily, a "Leader" label may not reflect the dimensions you actually care about.
None of this is a knock on Forrester's methodology — it's a well-established research practice. It's a reminder that a single quadrant position is a starting point for due diligence, not a substitute for it.
Where Do Safeguard and Sonatype Differ in Deployment Architecture?
Sonatype's SCA lineage traces back to Nexus Repository Manager, an artifact repository product the company has offered for years before building its Lifecycle and IQ Server SCA capabilities on top of that repository-centric foundation. That heritage is publicly documented in Sonatype's own product literature and is a reasonable, verifiable fact to know going in: the platform's roots are in the artifact repository, and its SCA policy engine is layered onto that base.
Safeguard, by contrast, was built as an API-first, CI/CD-native platform from the outset — it doesn't require you to route builds through a proprietary repository manager to get dependency visibility. Scans integrate directly into existing pipelines (GitHub Actions, GitLab CI, Jenkins, and others) and pull manifest and lockfile data without requiring a change to how your artifacts are stored or proxied.
Neither architecture is inherently "better" in the abstract — teams already standardized on a repository manager may value the integration Sonatype's heritage provides, while teams wanting to avoid another proxy layer in their build path may prefer a lighter-weight, pipeline-native model. The concrete, verifiable question to ask any SCA vendor, including both of these, is: does adopting this tool require me to change how my build retrieves or stores artifacts, or does it observe the build as it already runs? That answer will differ by vendor and is worth confirming in a proof-of-concept rather than inferring from a data sheet.
How Do Safeguard and Sonatype Approach Vulnerability Data?
Sonatype has invested for years in its own proprietary vulnerability research, built on top of the OSS Index dataset it maintains and augments with its own research team's curation — this is publicly documented and a genuine differentiator many vendors in this space don't attempt, since maintaining an independent vulnerability database is expensive to sustain.
Safeguard's approach is to combine multiple public advisory sources (including the National Vulnerability Database and GitHub Security Advisories) with reachability analysis, so that a finding isn't just "this package has a known CVE" but "this specific vulnerable function is actually reachable from your application's call graph." The concrete, verifiable dimension to ask about here isn't "how many CVEs does your database contain" — nearly every vendor's raw count converges over time since most draw from overlapping public sources — it's what percentage of flagged findings are reachable in your specific codebase, and how is that reachability computed. That's a question you can test directly in a trial rather than take from a data sheet, for any vendor you evaluate.
What Questions Should You Ask Beyond the Wave Report?
A Wave placement is a useful signal about breadth and market execution, but the questions that actually predict whether a tool will work for your team are narrower and more concrete:
- Time to first accurate finding. How long from initial repo connection to a scan result you can act on, without a lengthy professional-services onboarding?
- Noise reduction. What's the false-positive rate on your actual codebase, not a vendor's benchmark repo — and can the tool explain why it flagged (or didn't flag) a given dependency?
- Remediation guidance specificity. Does the tool tell you "upgrade to version X, here's the diff and the breaking changes," or just "a fix is available"?
- License and SBOM support. Can it generate SPDX or CycloneDX SBOMs on demand, and does it flag license conflicts alongside vulnerabilities?
- Pricing transparency. Can you get a straight answer on cost per developer or per repo without a multi-week sales cycle?
Ask every vendor on your shortlist these questions, get the answers in writing, and weight them according to what your organization actually needs — not according to which quadrant a vendor's logo happens to sit in this year.
How Safeguard Helps
Safeguard is built for teams that want SCA to work inside the pipelines they already have, without re-platforming around a new artifact repository. Scans run directly against your CI/CD workflows, dependency manifests, and lockfiles, surfacing vulnerabilities alongside reachability context so your team can prioritize what's actually exploitable in your application rather than triaging every CVE in the dependency tree equally.
If you're building an SCA evaluation and want to test the deployment-model and reachability questions raised in this guide against your own codebase — rather than a vendor demo environment — Safeguard supports proof-of-concept trials scoped to your actual repositories. That's the same standard we'd recommend applying to any vendor on your list, including Sonatype: get past the quadrant graphic and into a trial that answers the specific questions that matter for your environment.