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
The policy covers public profile evidence for Russia, Iran, and North Korea. Scope membership is not an editorial choice: a country is in scope only when it passes both of two institutional tests at once.
- Broad, multilateral sanctions and export-control exposure. The country is subject to country-level restrictive regimes maintained in parallel by the US Treasury sanctions programs, EU restrictive measures, and the UK sanctions regimes — not merely entity-level designations. Within the scope, North Korea additionally carries UN Security Council sanctions, and Iran and North Korea are the two jurisdictions under a standing FATF call for countermeasures.
- Officially named state cyber-threat activity. The country is named by Western cyber authorities as a source of state-sponsored operations against technology and supply chains. CISA's advanced persistent threat program maintains standing nation-state guidance for exactly four states — China, Russia, Iran, and North Korea — and the ODNI Annual Threat Assessment and the UK NCSC name the same four as the principal state cyber actors.
The intersection of the two tests is exactly the published scope, and it is what keeps the scope narrow in both directions. A country that passes only one test stays out: China is named on every state cyber-threat list but is not under broad country-level sanctions; Belarus, Cuba, Syria, and Venezuela carry sanctions exposure of varying breadth but are not named by these cyber authorities as sources of state supply-chain operations. Because both tests reference public institutional lists, the scope can be independently re-derived — and it changes only when those lists change, through a versioned methodology update.
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:
- the repository owner account;
- the displayed top contributors, identified from contribution history—not from private GitHub maintain or admin permissions; and
- 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 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 contributor-side match — a displayed top contributor, or a public organization on that contributor's profile — additionally requires the matched contributor to carry meaningful commit weight: at least 50 commits, or at least 10% of the sampled human commits. The share condition protects small repositories, where a genuine co-maintainer may hold few absolute commits; the absolute condition protects large ones, where a substantial body of work can still be a small percentage. A match below both thresholds is recorded on the report for review, but raises no flag and changes no score: a handful of accepted commits is disclosure, not exposure, and a policy that flagged every incidental contributor would tell a reviewer nothing about stewardship. Owner matches are never gated — the owner controls the repository namespace and release surface at any commit count.
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 34. 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 context is review-only and never changes a score — another country, a US state, or a named city outside the policy scope, so that a profile reading "Seoul, North Korea" or "London, Munich, St. Petersburg" is treated as ambiguous rather than as a declaration. Internationally recognized Ukrainian territories are excluded from Russia place matching unless the profile explicitly self-declares Russia.
A profile that names a country in order to deny being there — "not north korea", "Seoul, Korea (not DPRK)" — is likewise review-only. The denial has to sit beside the match to count: "No. 5 Lenin St, Moscow, Russia" declares Russia and retracts nothing.
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.
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 · Security posture · methodology · signals, not warranties