# High-Risk Jurisdiction Exposure > How inspect.software turns public repository-profile evidence into an explainable high-risk jurisdiction exposure signal for repository review. Open source lets an organization inherit extraordinary capability in minutes. It can also create a governance blind spot: a small number of external accounts may shape software that sits deep inside products, infrastructure, and customer environments, while the consuming organization knows little about the repository's operating context. **High-Risk Jurisdiction Exposure** helps close that gap. It is an explainable review signal derived from high-confidence, self-published public profile locations associated with a repository owner, displayed top contributors, and public organizations shown on those contributor profiles. When the evidence matches the current policy scope, the report makes the exposure prominent and adjusts both Security and the overall rating so that strong popularity or engineering practice cannot average it away. The result answers a narrow but useful enterprise question: > **Does this repository present high-risk jurisdiction exposure that > should receive enhanced human review?** It does not answer whether a person is trustworthy. It is not an inference of nationality, citizenship, residence, political belief, malicious intent, or sanctions status. ## Why this belongs in software supply-chain governance Enterprise dependency decisions extend beyond code quality. Procurement, security, legal, resilience, and public-sector teams may need to consider: - sanctions and export-control screening obligations; - government or customer restrictions on software origin and stewardship; - state-linked cyber-threat models and enhanced provenance requirements; - continuity risk if access, payments, hosting, or release infrastructure is disrupted by regional restrictions or disruptions; - concentration risk when a critical dependency relies on a small external stewardship community; and - the need to explain why a package was accepted, monitored, isolated, forked, or replaced. Without a systematic signal, these questions are handled late and inconsistently. A visible, versioned policy result turns them into a repeatable review decision rather than an improvised search during procurement or an incident. ## Current policy scope Methodology **1.4.0** covers public profile evidence for **Russia, Iran, and North Korea**. The set reflects a convergence of jurisdiction-specific restrictions, officially documented state-linked cyber activity, and enterprise continuity concerns. Useful primary policy references include the [US Treasury sanctions programs](https://ofac.treasury.gov/sanctions-programs-and-country-information), [UN Security Council consolidated sanctions](https://main.un.org/securitycouncil/en/content/un-sc-consolidated-list), [FATF high-risk and monitored jurisdictions](https://www.fatf-gafi.org/en/countries/black-and-grey-lists.html), and [CISA nation-state advisories](https://www.cisa.gov/topics/cyber-threats-and-advisories/advanced-persistent-threats). This is a **versioned supply-chain policy**, not a ranking of nationalities or a claim that every organization faces identical obligations. A country-level location match and an identity-level sanctions match are fundamentally different signals. inspect.software currently implements the former; it does not claim to perform legal sanctions screening. ## What the scanner evaluates The scanner reuses public profile data already collected for: 1. the repository owner account; 2. the displayed top contributors, identified from contribution history—not from private GitHub maintain or admin permissions; and 3. public organization affiliations shown on those contributor profiles. Organization locations are selected inside the same batched GitHub GraphQL request. Classification then runs offline against a compact [GeoNames](https://download.geonames.org/export/dump/) gazetteer. The check adds no GitHub request and no external identity-enrichment service. Only the strongest confirmed evidence determines the multiplier: | Strongest confirmed evidence | Policy multiplier | Interpretation | | --- | ---: | --- | | Repository owner profile | 20% | Direct owner-account exposure; enhanced review has highest priority | | Displayed top-contributor profile | 50% | Material contribution-history exposure; no claim of repository permission | | Contributor's public organization profile | 75% | Public affiliation context; deliberately weaker than a direct profile match | | Assessed locations, no policy match | 100% | No score adjustment | | No assessable public location | excluded | Unknown, never treated as safe or unsafe | A clean result cannot improve weak security hygiene. Missing evidence is never scored as a failure, and multiple matches do not compound into a more severe penalty. ## How it changes the rating The signal is a policy multiplier, not another security-practice checklist: `adjusted Security posture = base Security posture × policy multiplier` A confirmed match also gives the adjusted Security posture an **At risk ceiling of 49**. The Security category reflects that adjusted posture without applying the multiplier twice. After normal category weighting, the policy multiplier and the same ceiling apply to the **overall repository rating**. This makes the governance decision explicit: a material policy exposure cannot disappear inside an average of popularity, documentation, maintenance, and engineering scores. Every report retains the base value, multiplier, multiplied value, and ceiling. A reviewer can therefore reproduce the result and distinguish technical health from the policy adjustment that changed the published rating. ## How an enterprise should use the signal A policy alert is a route into due diligence—not an automatic accusation or a universal instruction to remove the package. Proportionate responses can include: - **Review:** confirm the upstream public evidence and the dependency's role in the product. - **Verify:** require signed releases, stronger provenance, pinned artifacts, reproducible builds, or additional source review. - **Limit:** keep the dependency away from sensitive data, credentials, build authority, or production environments while review is open. - **Monitor:** watch ownership, contributor concentration, release provenance, and future policy changes. - **Plan continuity:** identify a maintained alternative, internal mirror, or viable fork for a business-critical dependency. - **Document an exception:** record why the exposure is understood and which compensating controls make continued use acceptable. The right response depends on package criticality, execution context, customer commitments, and the organization's own legal and risk framework. The signal creates prioritization and evidence; expert judgement remains responsible for the decision. ## Evidence quality and safeguards High-confidence evidence includes an explicit country name or native spelling, a country flag, an unambiguous administrative region, or a place name unique to or overwhelmingly dominant in a policy country. Conflicting country or state context is **review-only** and never changes a score. Internationally recognized Ukrainian territories are excluded from Russia place matching unless the profile explicitly self-declares Russia. Domains, language, personal names, company text, and inferred identity do not establish location. Public organization membership alone is not a match; the organization must itself publish a matching location. Public reports expose aggregate country-and-role counts, never contributor identities or raw profile locations.
△
This is an explainable governance signal, not a legal or personal judgement. Public location evidence does not establish nationality, residence, sanctions status, malicious intent, repository permissions, or individual trustworthiness. A maintainer can request correction when upstream data or place matching is wrong.
## Why the design serves the public interest Jurisdiction-risk controls are often available only through opaque enterprise databases and private scoring models. inspect.software takes a different approach: the evidence boundary, country scope, multipliers, score ceiling, and limitations are public and versioned. Commercial relationships cannot alter a published result. That transparency protects both sides of the ecosystem. Dependency consumers receive a usable governance signal; maintainers can see exactly what was measured, what was not inferred, and how to challenge incorrect evidence. The objective is disciplined open-source risk review—not suspicion by association. Related: [Security](/wiki/security) · [Security posture](/wiki/security-posture) · [methodology](/methodology) · [signals, not warranties](/wiki/signals-not-warranties)