Using Reachability-Aware Risk Scoring to Gate Code Merges

The problem: too many red flags, no way to tell which ones matter

Your team is evaluating a codebase for acquisition, or you inherited a service with years of accumulated dependencies. The security scanner returns a long list of vulnerable packages, but most are transitive dependencies buried in manifests. You need to know whether any of them are actually reachable from your application code, and whether the overall codebase is stable enough to ship or merge.

Sema's platform addresses this with a Code Risk Score—a normalized 0–100 metric that combines static analysis, dependency graph traversal, and historical churn. Unlike a manifest scan, it attempts to flag only vulnerable packages that are reachable through actual call paths. The score is heuristic, not a guarantee of production safety, and it should be calibrated to your organization's risk tolerance.

What the score measures

The Code Risk Score aggregates several risk factors:

• Security vulnerabilities in dependencies, weighted by reachability
• License compliance issues
• Maintenance burden, such as outdated or unmaintained packages
• Architectural debt, including cyclic dependencies and module coupling

Key terms: static analysis inspects code without executing it. A transitive dependency is a library pulled in by another dependency, not declared directly in your manifest. Call-graph reachability determines whether vulnerable code is actually invoked at runtime, rather than simply present in a lockfile.

Reachability coverage is strongest for JVM, Go, and Node projects. Python and Ruby support is more limited, so treat scores for those languages as directional rather than definitive.

Worked example: scanning a repository before a merge

Assume you have access to a Sema organization and an API token. Run the scan from your local terminal or CI pipeline. Replace placeholders with your values.

sema scan --repo https://github.com/example/target-service --token $SEMA_API_TOKEN --format sarif --output results.sarif

Required permissions: read access to the repository being scanned, and a Sema API token with scan privileges. Expected checks: the command should exit successfully and produce a SARIF file containing a risk-score breakdown and dependency findings. A risk score above your team's threshold (for example, 70 on a 0–100 scale) can be used to block the pull request.

Relevant risks: the score may miss vulnerabilities in languages with limited call-graph coverage, and it cannot confirm that a flagged issue will or will not cause an incident. Do not treat a low score as proof that the code is safe to deploy.

Comparing reachability to manifest-only results

Limitations and how to verify

The Code Risk Score is a heuristic. Vendor documentation, rule weights, and supported language coverage change over time, so verify current behavior before relying on it for a gate.

Practical verification steps:

1. Run sema scan on a sample repository you control.
2. Inspect the SARIF or JSON output to confirm the score breakdown matches your expectations.
3. Test against a known vulnerable transitive dependency in a throwaway project—for example, a Log4j-related CVE in a Java test app—to see whether reachability flags it correctly.
4. If you are scanning proprietary code, request the vendor's SOC 2 Type II report and data-processing addendum to confirm residency and compliance controls.

Closing: set a threshold, then calibrate

Start by running Sema on a non-critical repository and comparing the score against your team's manual assessment. Use the score to prioritize refactoring or to block merges only after you have calibrated the threshold on your own codebases. Treat it as one input among code review, testing, and architectural judgment—not as a substitute for them.

Because pricing, API shapes, and rule packs change quarterly, confirm the current feature set with the vendor before rolling this out as a hard gate.