Sourcing-time, not detection-time
Scores OSS projects before adoption, not after. Programs catch unhealthy dependencies before they enter the build instead of finding out months later when CVEs accumulate.
Checkmarx • Application security
Checkmarx Repository Health scores open-source projects on maintenance frequency, contributor diversity, vulnerability response time, license trust, and project provenance, giving AppSec a sourcing-time verdict on whether to depend on the project at all before SCA evaluates the artifact.
When Merito stands up Checkmarx Repository Health, the engagement covers grandfathering existing dependencies, tuning score thresholds to the customer's risk tolerance, and wiring PR-time sourcing gates so unhealthy OSS projects get caught before they enter the dependency tree.
What it is
Checkmarx Repository Health is the sourcing-time scoring engine inside the Checkmarx One Supply Chain pillar. Where SCA evaluates artifacts after they enter the build, Repository Health scores the OSS projects feeding the dependency tree before adoption. Inputs include maintenance frequency, contributor diversity, vulnerability response time, license trust, project provenance (who controls the repository, where the maintainers are based, what the funding model is), and historical security posture. Outputs are project-level scores AppSec can gate on.
The premise is that not all OSS dependencies are equally trustworthy. A library with active maintainers, fast vulnerability response, and a healthy contributor base is a different risk than a library with a single maintainer who has not committed in two years. Both might pass an SCA scan today; only one is a defensible dependency tomorrow. Repository Health makes that distinction explicit and scorable rather than leaving it to developer intuition.
Comparison to OSSF Scorecard is fair. Scorecard provides similar signals as an open-source project. Checkmarx Repository Health adds curated scoring, integration with Checkmarx One findings, policy gates inside CI/CD, and a richer feed than the public Scorecard data. Programs running OSSF Scorecard manually can keep doing so; programs that want a productized score with policy enforcement adopt Repository Health.
Overrestrictive defaults are the main risk. Scoring every OSS project against a strict policy floods the team with warnings on dependencies the program has run for years and still relies on. A Repository Health rollout therefore grandfathers existing dependencies, applies the score gate only to newly introduced ones, and tunes thresholds to the customer's actual risk tolerance. Without that, the program looks like SCA all over again, with noise overwhelming signal.
Ideal use cases
What it is best at
Scores OSS projects before adoption, not after. Programs catch unhealthy dependencies before they enter the build instead of finding out months later when CVEs accumulate.
Maintenance frequency, contributor diversity, vulnerability response time, license trust, project provenance. CVE-only scoring misses projects that look clean today but have no maintainer behind them.
PR-time gates can require minimum Repository Health score before a new dependency is merged. Sourcing decisions become enforceable rather than aspirational.
Repository Health scores cross-reference with SCA CVE findings inside Checkmarx One. AppSec sees both the CVE and the project hygiene context in one view.
Malicious Package Protection blocks known-bad packages at fetch time; Repository Health scores project hygiene before adoption. Together they cover sourcing-time governance from both directions.
Core capabilities
Multi-factor health scoring grounded in real project signals.
Maintenance frequency scoring
Recent commits, release cadence, and active branch activity. Stalled projects score lower regardless of CVE history.
Contributor diversity
Number of distinct contributors, commit concentration, and bus-factor risk. Single-maintainer projects flagged for review.
Vulnerability response time
How fast the project has historically patched reported vulnerabilities. Slow responders score lower.
License trust and provenance
License clarity, attribution discipline, repository ownership, maintainer geography, funding model where known.
Turning scores into enforceable sourcing decisions inside the build.
Configurable score thresholds
Programs set minimum scores per application, business unit, or risk tier. Customer-facing services gate stricter than internal tooling.
PR-time sourcing gates
A pull request that adds a dependency scoring below the threshold cannot merge. Existing dependencies grandfathered.
Override workflow
Auditable override workflow with rationale capture for cases where a low-scoring project is the right choice.
Where project scores show up once they are calculated, beside SCA findings in Checkmarx One.
Cross-product correlation with SCA
Repository Health scores attached to SCA findings so AppSec sees CVE and project hygiene together.
Triage and Remediation context
Scores feed into Triage and Remediation clustering so high-risk-project findings rank above low-risk-project findings.
Compliance reporting
Audit-ready evidence for OSS-provenance requirements in federal, healthcare, and financial-services programs.
Where it fits in the stack
Deployment and implementation
Licensing and packaging
Checkmarx One Advanced
Adds Repository Health alongside DAST, API Security, IaC Security, and Malicious Package Protection to the Essentials baseline.
Best for: Programs adding sourcing-time governance to an existing SCA footprint.
Checkmarx One Enterprise
Advanced plus Software Supply Chain Security, AI Supply Chain Security, Triage and Remediation to rank findings by project health, Developer Assist and premium SLAs.
Best for: Programs that govern open-source sourcing, provenance and AI models on one Checkmarx One tenant.
Merito services
Pick the engagement that matches where you are in the lifecycle.
Policy threshold design, grandfathering, PR-time gate wiring, override workflow setup, and CI/CD integration.
Explore serviceOSS sourcing governance scoping for Repository Health alongside OSSF Scorecard and manual review.
Explore serviceSourcing gates integrated into PR-time CI and source-control review.
Explore serviceDeveloper enablement around OSS sourcing standards and override discipline.
Explore serviceNamed engineer, priority SLAs, and release-time coverage for Repository Health.
Explore serviceScore thresholds adjusted as risk tiers change, the grandfathered list reviewed, and override requests handled with an audit trail.
Explore serviceScoring-policy and grandfathering workshops for AppSec architects, override-workflow design for DevSecOps owners, and gate onboarding for engineering leads.
Explore serviceSupply-chain engineers from Merito who review overrides and keep score thresholds tuned while OSS adoption grows.
Explore serviceCheckmarx Repository Health licensing
Repository Health pricing arrives with policy-threshold design, grandfathering, PR-time gate wiring, and override-workflow setup that turn sourcing-time scoring into enforceable OSS governance.
Merito point of view
Dependency trees can pass SCA cleanly and still contain libraries with one stalled maintainer, no recent commits, and vulnerability reports left unanswered for a year. The library is fine today and a future incident waiting for circumstance. Repository Health makes that risk visible and scorable. SCA evaluates the artifact, and Repository Health evaluates whether the project should be in the tree at all.
Repository Health is built for programs where OSS adoption is growing faster than manual review can keep up, where regulated workloads require provenance evidence, and where sourcing-time governance is part of the security posture. For programs that already run OSSF Scorecard with policy gates and have manual review discipline, Repository Health adds productized scoring and Checkmarx integration, but the delta is modest.
Repository Health covers half of sourcing-time governance, and Malicious Package Protection covers the other half. One blocks known-bad packages at fetch time, and the other scores hygiene before adoption. Programs running one without the other are filtering downstream risk without screening upstream provenance, so any program serious about supply-chain governance should run both.
What buyers usually underestimate
Related from Merito
Related solutions
Related services
Related products
Frequently Asked Questions
Consultation request
Share your OSS dependency-tree shape, current sourcing review process, and supply-chain governance posture. A Merito Checkmarx specialist follows up within one business day.
Sourcing-time scoring
Multi-factor scoring on maintenance, contributors, response time, license trust, and provenance. SCA cannot do this.
Policy gates
PR-time gates require minimum scores. Auditable override workflow for legitimate exceptions.
Next step
A Merito Repository Health engagement starts with grandfathering and policy-threshold design. Sourcing-time governance prevents what detection-time scanning catches after the fact.