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 vertragliche oder regulatorische Vorgaben, staatliche Bedrohungsmodelle, Betriebskontinuität, Konzentrationsrisiken und die Nachvollziehbarkeit von Annahme, Überwachung, Isolation oder Ersatz betrachten.
Ohne ein systematisches Signal kommen diese Fragen spät und werden uneinheitlich beantwortet. Ein sichtbares, versioniertes Ergebnis macht daraus einen wiederholbaren Prüfprozess.
Aktueller Richtlinienumfang
Methodik 1.4.0 umfasst öffentliche Profilevidenz für Russland, Iran und Nordkorea. Die Auswahl spiegelt das Zusammentreffen jurisdiktionsspezifischer Beschränkungen, dokumentierter staatlicher Cyberaktivität und unternehmerischer Kontinuitätsrisiken. 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 vorhandene öffentliche Daten zum Inhaberkonto, zu sichtbaren Top-Contributors—bestimmt aus Beitragshistorie, nicht privaten Berechtigungen—und zu öffentlichen Organisationen in deren Profilen. Organisationsstandorte kommen aus derselben GraphQL-Abfrage; die Klassifikation läuft lokal mit GeoNames. Es gibt keine zusätzliche GitHub-Anfrage und keinen externen Identity-Enrichment-Dienst.
| Stärkste bestätigte Evidenz | Multiplikator | Interpretation |
|---|---|---|
| Profil des Repository-Inhabers | 20% | Direkte Exposition des Inhaberkontos; höchste Prüfpriorität |
| Profil eines Top-Contributors | 50% | Materielle Beitragshistorie; keine Aussage über Berechtigungen |
| Öffentliche Organisation eines Contributors | 75% | Zugehörigkeitskontext; bewusst schwächeres Signal |
| Bewertete Standorte, kein Treffer | 100% | Keine Anpassung |
| Kein bewertbarer Standort | ausgeschlossen | Unbekannt; niemals als sicher oder unsicher gewertet |
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 49. 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 geografischer Kontext bleibt review-only und verändert keine Bewertung. International anerkannte ukrainische Gebiete werden Russland nicht zugeordnet, sofern das Profil Russland nicht ausdrücklich nennt.
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.
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