Release Security Observatory · v0.7.2

Erkennen Sie, was der Sicherheitsstatus Ihrer Git-Instanz wirklich aussagt.

VersionSec prüft genau eine Gitea- oder Forgejo-Instanz, die Ihnen gehört oder zu deren Prüfung Sie ausdrücklich autorisiert sind. Es liest und verändert nichts. Konfigurations- und Runner-Prüfung laufen vollständig offline, ganz ohne Netzwerkanfragen.

  • nur lesend
  • ein autorisiertes Ziel
  • deterministisch
  • Gitea und Forgejo
  • MD / JSON / SARIF
Von PyPI installieren Geprüfte Punkte ansehen

Apache-2.0 - kein Konto, keine gehostete Steuerebene, keine Telemetrie.

versionsecread-only
$ versionsec scan \
  --url https://git.example.com \
  --authorized --product gitea \
  --format md,json,sarif

FG-VER          PASS   1.27.3 confirmed
FG-CVE-27771    PASS   fixed in this version
FG-ANON         WARN   anonymous API reachable
FG-REG          PASS   OCI root requires auth
FG-SIGNIN       WARN   repo browser is public

# 22 stable IDs · md + json + sarif written
aktuelles Release
v0.7.2
Prüfungen
22 stabile IDs
Tests
433 bestanden
Provenienz
signierte Attestierung
Lizenz
Apache-2.0

Statusfragen, die sonst aus dem Gedächtnis beantwortet werden

Selbst gehostete Instanzen werden einmal konfiguriert und danach dauerhaft für sicher gehalten. VersionSec macht aus vier wiederkehrenden Fragen Nachweise, die Sie aufbewahren, vergleichen und einer Prüfung vorlegen können.

Ist die laufende Version tatsächlich betroffen?

Der Versionsstatus wird gegen benannte Sicherheitshinweise bewertet. Eine unbekannte Version wird als unbekannt ausgewiesen - niemals stillschweigend als bestanden.

Was erreicht ein anonymer Besucher?

Eine begrenzte Liste erlaubter Pfade wird ausschließlich per GET abgefragt, und genau der beobachtete Status wird berichtet.

Entspricht die Konfiguration unseren Annahmen?

Ein anonymisierter Konfigurations-Snapshot wird vollständig offline geprüft, die Instanz selbst wird dabei nicht berührt.

Was kann ein CI-Job auf dem Runner mit dem Host tun?

Privilegierter Modus, Docker-Socket, Host-Mounts, Netzwerkmodus und Lebensdauer der Zugangsdaten werden aus einem deklarierten Snapshot bewertet.

Vier Prüfmodi, ein deterministischer Bericht

Jeder Modus erzeugt dieselbe Berichtsstruktur, damit Ergebnisse über die Zeit vergleichbar bleiben.

Live-Statusprüfung

Ein Ziel pro Lauf, ausschließlich GET-Anfragen gegen eine feste Pfadliste. Keine Schreibzugriffe, keine Zustandsänderung, keine Suche nach weiteren Hosts.

  • FG-VER
  • FG-ANON
  • FG-HTTP
  • FG-REG
  • FG-SIGNIN

Versionsstatus zu Sicherheitshinweisen

Benannte Hinweise werden gegen die vom Betreiber bestätigte Version bewertet: betroffen, behoben oder unbekannt - ausdrücklich benannt.

  • FG-CVE-27771
  • FG-CVE-78433
  • FG-FJ-TEMPLATE-20260910

Offline-Konfigurationsprüfung

Prüft einen von Ihnen bereitgestellten, anonymisierten Snapshot. Null Netzwerkanfragen, also auch für Instanzen geeignet, die nicht live geprüft werden dürfen.

  • FG-CONFIG-REGISTRATION
  • FG-CONFIG-SIGNIN
  • FG-CONFIG-PRIVACY
  • FG-CONFIG-MFA

Offline-Prüfung des Actions-Runners

Prüft einen deklarierten Runner-Snapshot gegen ein geschlossenes Schema. Die Einstufung richtet sich nach der deklarierten Workload-Vertrauensstufe, nicht nach der Version allein.

  • FG-RUNNER-PRIVILEGED
  • FG-RUNNER-DOCKER
  • FG-RUNNER-VOLUMES
  • FG-RUNNER-NETWORK

Qualifizierte Zielversionen statt pauschaler Unterstützung

Gitea und Forgejo haben eigene Provider mit eigenen Prüfungen. Dies sind genau die Versionen, gegen die das Release getestet wurde - keine Zusage für jede Version der jeweiligen Reihe.

Provider
Qualifizierte Serverversionen
Qualifizierte Runner-Versionen
Gitea
1.26.41.27.3
3.4.2gitea-runner
Forgejo
15.0.816.0.4
13.0.013.1.0forgejo-runner

Andere Versionen funktionieren meist, werden aber außerhalb dieser Ziele nicht als geprüft dargestellt.

Ablauf einer Prüfung

1

Ziel deklarieren

Sie benennen eine Instanz und ihr Produkt und bestätigen, dass Sie zur Prüfung autorisiert sind.

2

Begrenzte Erhebung

Nur erlaubte Pfade werden abgefragt, ausschließlich per GET. Offline-Modi lesen eine Datei und senden gar nichts.

3

Deterministische Bewertung

Jede Prüfung liefert PASS, FAIL, WARN, NOT_APPLICABLE oder UNKNOWN. Fehlende Belege sind nie ein PASS.

4

Bericht und Export

Markdown für Menschen, JSON für Pipelines, SARIF 2.1.0 für Code-Scanning. Durchgängig stabile IDs.

Nachweise und Provenienz

Die veröffentlichten Artefakte sind genau die, die die CI gebaut hat. Ihre Herkunft lässt sich mit einem Befehl prüfen, eine veränderte Kopie wird abgelehnt.

Download prüfen
$ gh attestation verify \
  versionsec-0.7.2-py3-none-any.whl \
  --repo gexiro-global/versionsec

# wheel  sha256
ea7d40357d808ed490113a62b6dae7fe
4af7e655b61c687c77689b4041828f5d
# sdist  sha256
fcbacb335a17d43436c819507fdb968a
12ff0754644ea6ee7e0e73fc5221b79d

Signierte Build-Provenienz

Beide Artefakte tragen eine Sigstore-Attestierung aus dem CI-Workflow des Projekts.

Veröffentlichte Prüfsummen

SHA-256 für Wheel und sdist liegen dem Release bei und stimmen mit den attestierten Objekten überein.

Release-Vertragstests

Jeder dokumentierte Befehl wird als echter Subprozess gegen installierte Konsolenskripte ausgeführt.

Stabile Kennungen

Befund-IDs und Schema-Kennungen ändern sich zwischen Releases nicht aus Branding-Gründen.

Ausgabeformate

Markdown

Lesbarer Bericht mit vollständiger Befundtabelle, für Menschen und für Tickets.

JSON

Stabiles maschinenlesbares Dokument mit versionierter Schema-Kennung für Pipelines.

SARIF 2.1.0

Standardformat für statische Analyse, für Code-Scanning-Dashboards und CI-Annotationen.

VersionSec hieß früher ForgeGuard

Releases bis einschließlich 0.6.0 wurden als ForgeGuard veröffentlicht und bleiben unverändert verfügbar. Ab 0.7.0 lautet der kanonische Name VersionSec.

Bestehende Nutzer verlieren nichts: der Befehl forgeguard und import forgeguard funktionieren über eine Kompatibilitätsschicht weiter, die auf dieselbe Implementierung verweist, und FORGEGUARD_TOKEN wird weiterhin gelesen.

Migrationsanleitung

Warum die FG-*-Kennungen bleiben

Befund-IDs wie FG-VER und Schema-Kennungen wie forgeguard.assessment.v1 sind Vertragsidentität, kein Branding. Eine Umbenennung würde bestehende Auswertungen, Ausnahmelisten und SARIF-Baselines brechen - deshalb bleiben sie bewusst unverändert.

Erratum zu 0.7.0

In 0.7.0 fehlte der Versionsschalter, sodass versionsec --version mit einem Unbekannte-Option-Fehler abbrach. Scan, Konfigurations- und Runner-Prüfung waren nicht betroffen. 0.7.1 behebt das und ersetzt 0.7.0.

Installation

PyPI: Auf PyPI veröffentlicht und direkt installierbar. Die Kompatibilitätsbrücke <code>forgeguard==0.7.2</code> installiert für bestehende Nutzer dieselbe Implementierung.
von pypi installieren v0.7.2
$ python -m pip install versionsec==0.7.2

$ versionsec --version
VersionSec 0.7.2

# existing ForgeGuard users
$ python -m pip install forgeguard==0.7.2
erster Aufruf
$ versionsec providers
$ versionsec checks
$ versionsec config review --snapshot snap.json
$ versionsec runner review --snapshot runner.json

Was VersionSec nicht tut

Die Nutzung ist auf Instanzen beschränkt, die Ihnen gehören oder zu deren Prüfung Sie ausdrücklich autorisiert sind. Die rechtliche Zuständigkeit bleibt beim Betreiber.

Keine Ausnutzung von Schwachstellen, keine Payloads, keine zustandsändernden Anfragen.
Keine Zielsuche und kein Massenscan - ein deklariertes Ziel pro Lauf.
Keine Aussage, dass eine Instanz nicht kompromittiert ist, und keine Kompromittierungsfeststellung.
Keinerlei Sicherheits- oder Compliance-Zertifizierung.

Häufige Fragen

Werden Gitea und Forgejo gleichwertig unterstützt?
Es sind getrennte Provider mit eigenen Prüfungen und eigenen qualifizierten Zielversionen. Keiner ist ein Aufsatz auf den anderen.
Wird Netzwerkzugriff benötigt?
Für die Live-Prüfung ja, zum einen deklarierten Ziel. Konfigurations- und Runner-Prüfung senden überhaupt keine Netzwerkanfragen.
Wird ein Admin-Token benötigt?
Nein. Die Live-Prüfung ist bewusst anonym; ein Token ist optional und wird nur verwendet, wenn der Betreiber es ausdrücklich übergibt.
Verändert es etwas an meiner Instanz?
Nein. Die Live-Prüfung sendet ausschließlich GET-Anfragen gegen eine feste Pfadliste.
Was passiert, wenn eine Prüfung nicht bewertbar ist?
Sie wird als UNKNOWN oder NOT_APPLICABLE ausgewiesen. Fehlende Belege gelten nie als bestanden.
Ist eine Version außerhalb der Zielversionen nicht unterstützt?
Sie funktioniert meist, getestet sind aber nur die genannten Ziele - nur diese werden als geprüft dargestellt.
Ich nutze bereits ForgeGuard. Was bricht?
Nichts. Befehl, Importpfad, Umgebungsvariable und alle FG-*-Befund-IDs funktionieren weiter.
Unter welcher Lizenz steht es?
Apache-2.0. Quellcode, Release-Artefakte und Testsuite sind öffentlich.

Kontakt

Für Fragen zum Werkzeug, zu Integrationen oder zu einer abgegrenzten Härtungsprüfung. Wählen Sie das Thema, damit die Anfrage richtig ankommt.

Sie melden eine Schwachstelle in VersionSec selbst? Nutzen Sie die Security Policy im Repository, damit die Meldung den dokumentierten Weg nimmt. Security Policy.