Warnsignale und Richtlinien

Exposition gegenüber Hochrisikojurisdiktionen

Wie inspect.software öffentliche Profilevidenz in ein erklärbares Signal für die Exposition eines Repositorys gegenüber Hochrisikojurisdiktionen übersetzt.

Methodik v2.10.0Aktualisiert 2026-08-02

Open Source erschließt in Minuten außergewöhnliche Fähigkeiten. Zugleich kann eine Governance-Lücke entstehen: Wenige externe Konten prägen Software tief in Produkten, Infrastruktur und Kundenumgebungen, während die nutzende Organisation wenig über den operativen Kontext weiß.

Die Exposition gegenüber Hochrisikojurisdiktionen schließt einen Teil dieser Lücke. Das erklärbare Prüfsignal beruht auf hochzuverlässigen, selbst veröffentlichten Profilstandorten des Repository-Inhabers, sichtbarer Top-Contributors und der öffentlichen Organisationen in deren Profilen. Trifft die Evidenz auf den aktuellen Richtlinienumfang, hebt der Bericht die Exposition hervor und passt Sicherheit und Gesamtbewertung an. Popularität oder gute Engineering-Praxis können sie dadurch nicht herausmitteln.

Entsteht bei diesem Repository eine Exposition gegenüber einer Hochrisikojurisdiktion, die eine vertiefte menschliche Prüfung erfordert?

Das Signal beurteilt keine Person. Es leitet weder Nationalität, Staatsangehörigkeit, Wohnsitz, Überzeugung, böswillige Absicht noch Sanktionsstatus ab.

Warum dies zur Lieferketten-Governance gehört

Unternehmensentscheidungen über Abhängigkeiten reichen über Codequalität hinaus. Einkauf, Security, Recht, Resilienz und öffentliche Auftraggeber müssen möglicherweise Folgendes betrachten:

  • Pflichten zum Sanktions- und Exportkontroll-Screening;
  • staatliche oder kundenseitige Beschränkungen zu Herkunft und Trägerschaft von Software;
  • staatlich verknüpfte Cyber-Bedrohungsmodelle und verschärfte Anforderungen an die Provenienz;
  • Kontinuitätsrisiko, wenn Zugang, Zahlungen, Hosting oder Release-Infrastruktur durch regionale Beschränkungen oder Störungen unterbrochen werden;
  • Konzentrationsrisiko, wenn eine kritische Abhängigkeit auf einer kleinen externen Trägergemeinschaft ruht; und
  • die Notwendigkeit zu erklären, warum ein Paket angenommen, überwacht, isoliert, geforkt oder ersetzt wurde.

Ohne ein systematisches Signal kommen diese Fragen spät und werden uneinheitlich beantwortet. Ein sichtbares, versioniertes Richtlinienergebnis macht daraus eine wiederholbare Prüfentscheidung statt einer improvisierten Suche während einer Beschaffung oder eines Vorfalls.

Aktueller Richtlinienumfang

Die Richtlinie umfasst öffentliche Profilevidenz für Russland, Iran und Nordkorea. Die Aufnahme ist keine redaktionelle Entscheidung: Ein Land ist nur im Geltungsbereich, wenn es beide institutionellen Tests zugleich besteht.

  1. Breite, multilaterale Sanktions- und Exportkontroll-Exponierung. Das Land unterliegt länderweiten Restriktionsregimen, die parallel von den US-Treasury-Sanktionsprogrammen, den EU-Restriktionsmaßnahmen und den UK-Sanktionsregimen geführt werden — nicht bloß Einzeldesignationen. Nordkorea trägt zusätzlich UN-Sicherheitsratssanktionen; Iran und Nordkorea sind die beiden Jurisdiktionen unter einem stehenden FATF-Aufruf zu Gegenmaßnahmen.
  2. Offiziell benannte staatliche Cyberbedrohung. Das Land wird von westlichen Cyberbehörden als Quelle staatlich gesteuerter Operationen gegen Technologie und Lieferketten benannt. CISAs Advanced-Persistent-Threat-Programm führt stehende Nationalstaaten-Hinweise für genau vier Staaten — China, Russland, Iran und Nordkorea — und das ODNI Annual Threat Assessment sowie das UK NCSC benennen dieselben vier.

Die Schnittmenge beider Tests ist exakt der veröffentlichte Geltungsbereich — und sie hält ihn in beide Richtungen eng. Ein Land, das nur einen Test besteht, bleibt draußen: China steht auf jeder Cyberbedrohungs-Liste, ist aber keinen breiten länderweiten Sanktionen unterworfen; Belarus, Kuba, Syrien und Venezuela tragen Sanktionsexponierung unterschiedlicher Breite, werden von diesen Cyberbehörden aber nicht als Quellen staatlicher Lieferkettenoperationen benannt. Da beide Tests auf öffentliche institutionelle Listen verweisen, lässt sich der Geltungsbereich unabhängig nachvollziehen — und er ändert sich nur, wenn diese Listen sich ändern, über eine versionierte Methodik-Aktualisierung. Sie ist eine versionierte Lieferkettenrichtlinie, keine Rangordnung von Menschen oder Kulturen.

Ein Standorttreffer ist nicht dasselbe wie ein Identitätstreffer auf einer Sanktionsliste. inspect.software implementiert Ersteren und beansprucht keine rechtliche Sanktionsprüfung.

Was der Scanner bewertet

Der Scanner verwendet öffentliche Profildaten wieder, die bereits erhoben wurden für:

  1. das Inhaberkonto des Repositorys;
  2. die angezeigten Top-Contributors, bestimmt aus der Beitragshistorie — nicht aus privaten GitHub-Berechtigungen für Maintain oder Admin; und
  3. öffentliche Organisationszugehörigkeiten, die in diesen Contributor-Profilen ausgewiesen sind.

Organisationsstandorte werden innerhalb derselben gebündelten GitHub-GraphQL-Abfrage ausgewählt. Die Klassifikation läuft anschließend offline gegen ein kompaktes GeoNames-Ortsverzeichnis. Die Prüfung fügt keine GitHub-Anfrage und keinen externen Identity-Enrichment-Dienst hinzu.

Nur die stärkste bestätigte Evidenz bestimmt den Multiplikator:

Stärkste bestätigte EvidenzMultiplikatorInterpretation
Profil des Repository-Inhabers20%Direkte Exposition des Inhaberkontos; höchste Prüfpriorität
Profil eines Top-Contributors50%Materielle Beitragshistorie; keine Aussage über Berechtigungen
Öffentliche Organisation eines Contributors75%Zugehörigkeitskontext; bewusst schwächeres Signal
Bewertete Standorte, kein Treffer100%Keine Anpassung
Kein bewertbarer StandortausgeschlossenUnbekannt; niemals als sicher oder unsicher gewertet

Ein Treffer auf Mitwirkenden-Seite — ein angezeigter Top-Mitwirkender oder eine öffentliche Organisation auf dessen Profil — erfordert zusätzlich, dass die betroffene Person nennenswertes Commit-Gewicht trägt: mindestens 50 Commits oder mindestens 10 % der erfassten menschlichen Commits. Die Anteilsbedingung schützt kleine Repositories, in denen ein echter Co-Maintainer wenige absolute Commits halten kann; die absolute Bedingung schützt große, in denen ein substanzieller Beitrag prozentual klein bleiben kann. Ein Treffer unterhalb beider Schwellen wird im Bericht zur Prüfung festgehalten, löst aber keine Flagge aus und ändert keine Bewertung: eine Handvoll angenommener Commits ist Offenlegung, keine Exponierung. Treffer auf den Eigentümer werden nie gefiltert — der Eigentümer kontrolliert Namensraum und Release-Oberfläche bei jeder Commit-Zahl.

Ein unauffälliges Ergebnis verbessert keine schwache Sicherheit. Fehlende Daten sind kein Fehler, und mehrere Treffer werden nicht kumuliert.

Wirkung auf die Bewertung

Angepasste Sicherheit = Basissicherheit × Richtlinienmultiplikator

Ein bestätigter Treffer gibt der Sicherheitslage zusätzlich eine Gefährdet-Obergrenze von 34. Die Kategorie Sicherheit spiegelt diesen Wert, ohne doppelt zu multiplizieren. Nach der normalen Gewichtung gilt dieselbe Richtlinie für die Gesamtbewertung. Relevante Exposition verschwindet somit nicht in einem Mittelwert aus Popularität, Dokumentation und Wartung.

Der Bericht bewahrt Basis, Multiplikator, Rechenergebnis und Obergrenze. So bleiben technische Gesundheit und Richtlinienanpassung unterscheidbar.

Angemessene Nutzung im Unternehmen

Die Warnung eröffnet Due Diligence; sie ist weder Anschuldigung noch allgemeine Anweisung zum Entfernen. Angemessene Maßnahmen sind:

  • Prüfen: Evidenz und Rolle der Abhängigkeit bestätigen.
  • Verifizieren: Signaturen, Herkunft, fixierte Artefakte oder reproduzierbare Builds verlangen.
  • Begrenzen: Zugriff auf Geheimnisse, sensible Daten oder Produktion einschränken.
  • Überwachen: Eigentum, Konzentration, Releases und Richtlinienänderungen beobachten.
  • Kontinuität planen: Alternative, Spiegel oder tragfähigen Fork identifizieren.
  • Ausnahme dokumentieren: Begründung und kompensierende Kontrollen festhalten.

Die Entscheidung hängt von Kritikalität, Laufzeitkontext, Kundenpflichten und dem eigenen Rechts- und Risikorahmen ab.

Evidenzqualität und Schutzvorkehrungen

Hochzuverlässige Evidenz umfasst explizite Ländernamen, lokale Schreibweisen, Flaggen, eindeutige Regionen oder überwiegend einem Land zuzuordnende Orte. Widersprüchlicher Kontext bleibt review-only und verändert keine Bewertung — ein anderes Land, ein US-Bundesstaat oder eine genannte Stadt außerhalb des Geltungsbereichs, sodass ein Profil mit „Seoul, North Korea“ oder „London, Munich, St. Petersburg“ als mehrdeutig gilt und nicht als Erklärung. International anerkannte ukrainische Gebiete werden Russland nicht zugeordnet, sofern das Profil Russland nicht ausdrücklich nennt.

Ein Profil, das ein Land nennt, um zu verneinen, dort zu sein — „not north korea“, „Seoul, Korea (not DPRK)“ —, bleibt ebenfalls review-only. Die Verneinung muss neben dem Treffer stehen: „No. 5 Lenin St, Moscow, Russia“ erklärt Russland und nimmt nichts zurück.

Domain, Sprache, Name, Unternehmenstext und abgeleitete Identität bestimmen keinen Standort. Auch Organisationsmitgliedschaft allein genügt nicht; die Organisation muss selbst einen passenden Standort veröffentlichen. Öffentliche Berichte zeigen nur aggregierte Land-/Rollenzahlen, niemals Identitäten oder Rohstandorte.

Dies ist ein erklärbares Governance-Signal, kein rechtliches oder persönliches Urteil. Öffentliche Standortangaben belegen weder Nationalität, Wohnsitz, Sanktionsstatus, böswillige Absicht, Berechtigungen noch persönliche Vertrauenswürdigkeit. Maintainer können Korrektur verlangen, wenn Quelldaten oder Zuordnung falsch sind.

Gestaltung im öffentlichen Interesse

inspect.software veröffentlicht Evidenzgrenze, Länderumfang, Multiplikatoren, Obergrenze und Einschränkungen. Geschäftsbeziehungen können ein Ergebnis nicht ändern. Verbraucher erhalten ein nutzbares Signal; Maintainer sehen, was gemessen, was nicht abgeleitet und wie ein Fehler angefochten wurde. Ziel ist disziplinierte Risikoprüfung—nicht Verdacht durch bloße Verbindung.

Verwandt: Sicherheit · Sicherheitslage · Methodik · Signale, keine Garantien

Wo dies festgestellt wurde

1.152 Repositories im öffentlichen Register tragen diesen Befund.

Alle 1.152 im Katalog ansehen

Von inspect.software veröffentlichte Ergebnisse sind Signale, keine Garantien — siehe wie sie zu lesen sind. Die vollständige Methodik ist versioniert und öffentlich: Methodik v2.10.0.