Sicherheitshinweise für deine Repositorys

Wenn jemand eine Schwachstelle in Software findet, die du pflegst, behebst du sie zuerst und informierst danach. Ein Sicherheitshinweis (Security Advisory) ist die Art, wie du informierst: eine kurze, strukturierte Aussage darüber, was betroffen ist, wie schwer, und welche Version es behebt. Scanner lesen solche Hinweise, um alle zu warnen, die von deinem Paket abhängen.

fremforge verwaltet die Sicherheitshinweise einer Organisation unter Sicherheit › Berichte › Sicherheitshinweise und über die API unter /_app/api/v1/orgs/{org}/security-advisories.

Vertraulich entwerfen

Neuer Hinweis öffnet einen Entwurf. Ein Entwurf nennt:

• das Repository, um das es geht;
• einen einzeiligen Titel und eine Beschreibung: was die Schwachstelle ist, wer betroffen ist, die Auswirkung und wie man sie behebt oder umgeht;
• die betroffenen Pakete, jeweils mit Ökosystem, Paketname, verwundbaren Versionen und der ersten korrigierten Version;
• den Schweregrad, als CVSS-Vektor oder als Stufe (kritisch, hoch, mittel, niedrig);
• die Schwächen (CWE-IDs), optional eine CVE-ID und Referenzen.

Ein Entwurf ist nur sichtbar für:

• die Owner der Organisation. Ihre Auditors sehen nur, dass es ihn gibt, sein Repository, seinen Zustand und seine Daten, nie seinen Inhalt;
• die Administratoren des Repositorys, um das es geht (siehe Repository-Administratoren);
• die Personen, die sie dazu einladen (siehe Mitwirkende).

Titel, Beschreibung, Referenzen und Kommentare werden verschlüsselt gespeichert. Die eigenen Betriebswerkzeuge und KI-Agenten von fremforge sehen weder den Text noch, wer ihn geschrieben hat.

Wer einen Entwurf sehen kann, kann ihn in vertraulichen Kommentaren besprechen. Sie bleiben privat, auch nachdem der Hinweis veröffentlicht ist.

Verwundbare Versionen

Gib die verwundbaren Versionen als eine oder zwei Bedingungen an, in derselben Form, die GitHub verwendet:

> wird abgewiesen: Das OSV-Format kennt keine exklusive Untergrenze, verwende also >=. Bei < X ist die erste korrigierte Version X. Lass Korrigierte Version leer oder verwende <= für die letzte betroffene Version.

Ökosysteme: npm, PyPI, Maven (groupId:artifactId), Go (der Modulpfad), crates.io, RubyGems, NuGet, Packagist, Pub, Hex, GitHub Actions (owner/repository), SwiftURL und CRAN.

Schweregrad

Ein CVSS-3.1-Basisvektor setzt den Schweregrad aus seinem Basiswert, den fremforge berechnet. Ein CVSS-4.0-Basisvektor wird geprüft und so behalten, wie er angegeben ist. Wähle den Schweregrad dann selbst: Der CVSS-4.0-Wert wird nicht berechnet.

Veröffentlichen

Hinweis veröffentlichen braucht einen Schweregrad und mindestens ein betroffenes Paket.

• Bei einem öffentlichen Repository (nicht privat, in einer Organisation mit öffentlicher Sichtbarkeit) wird der Hinweis sofort öffentlich: eine Seite unter https://frem.sh/_app/advisories/<id> und ein OSV-Eintrag (siehe unten). Ob das Repository öffentlich ist, wird bei jedem öffentlichen Abruf erneut geprüft. Machst du das Repository später privat, werden seine Hinweise beim nächsten Abruf nicht mehr ausgeliefert.
• Bei einem privaten Repository bleibt der Hinweis nur innerhalb deiner Organisation sichtbar. Er wird nicht öffentlich, wenn du das Repository später öffnest; veröffentliche dann einen neuen.

Gib die Korrektur frei, bevor du veröffentlichst: Der Hinweis sagt allen, wo die Schwachstelle liegt.

Die Korrektur wird vorerst außerhalb von fremforge entwickelt. Ein Hinweis enthält Text; fremforge hat dafür keinen temporären privaten Fork. Ein privates Repository in deiner Organisation wäre für jedes Team mit Zugriff auf alle Repositorys lesbar, was standardmäßig Members und Viewers einschließt, deshalb wird das nicht angeboten. Entwickle die Korrektur so, wie dein Projekt mit unveröffentlichten Sicherheitskorrekturen umgeht, und veröffentliche den Hinweis, sobald die korrigierte Version freigegeben ist.

Jeder Hinweis hat eine ID der Form FFSA-xxxx-xxxx-xxxx, die beim Anlegen des Entwurfs festgelegt wird.

Repository-Administratoren

Die Administratoren eines Repositorys bearbeiten die Hinweise und privaten Meldungen dieses Repositorys, ohne Owner der Organisation zu sein, so wie GitHub es Repository-Administratoren erlaubt. Sie finden die Meldungen an die Repositorys, die sie verwalten, unter Meldungen an Repositorys, die du verwaltest auf /_app/security-reports, können sie annehmen oder ablehnen und die Entwürfe dieser Repositorys lesen und kommentieren. Ob jemand ein Repository verwaltet, wird bei jeder Anfrage bei frem.sh abgefragt, sodass eine Änderung der Berechtigungen sofort gilt. Ein Owner der Organisation zählt als Administrator jedes Repositorys der Organisation.

Mitwirkende

Lade Personen über ihren frem.sh-Login zu einem Entwurf oder veröffentlichten Hinweis ein, zum Beispiel eine externe Forscherin oder einen Maintainer aus einem anderen Projekt. Sie müssen nicht Mitglied deiner Organisation sein. Eine eingeladene Person liest den Hinweis und seine vertraulichen Kommentare und fügt Kommentare hinzu, auf ihrer eigenen Seite unter /_app/security-reports. Sie kann ihn weder ändern noch veröffentlichen. Entfernst du sie, endet ihr Zugriff sofort. Zu einem Hinweis können bis zu 20 Personen eingeladen werden.

Private Schwachstellenmeldung

Ist die private Schwachstellenmeldung eingeschaltet, kann jede bei frem.sh angemeldete Person, die ein Repository lesen kann, dir eine Schwachstelle darin vertraulich melden, auch Personen außerhalb deiner Organisation. Ohne sie muss jemand, der etwas findet, eine E-Mail-Adresse erraten oder ein öffentliches Issue eröffnen.

Sie ist aus, bis du sie einschaltest. Owner legen einen organisationsweiten Standard unter Sicherheit › Berichte › Sicherheitshinweise › Meldungseinstellungen fest und können sie dort für einzelne Repositorys ein- oder ausschalten; eine Repository-Einstellung hat Vorrang vor dem Standard.

Was eine meldende Person sendet

Das Meldeformular liegt unter https://frem.sh/_app/security-reports/new?repo=<org>/<repository>. Verlinke es in der SECURITY.md deines Repositorys. Eine Meldung hat einen Titel, eine Beschreibung, die betroffenen Versionen, wie die Schwachstelle gefunden wurde, und optional einen Proof of Concept. Sie wird verschlüsselt gespeichert, und nur die Owner der Organisation, die Administratoren des Repositorys und die meldende Person sehen sie. Ihr Text steht nie in einer E-Mail oder im Audit-Log; das Audit-Log nennt Meldungen über ihre ID.

Damit der Kanal nutzbar bleibt, begrenzt fremforge Meldungen:

• 3 pro Person an ein Repository und insgesamt 10 pro Person innerhalb von 24 Stunden;
• keine von einem Konto, das jünger als 24 Stunden ist;
• 5 pro Minute von einer IP-Adresse.

Eine Anfrage, die eine Grenze überschreiten würde, wird abgewiesen, und nichts wird gespeichert.

Über eine Meldung entscheiden

Die Owner der Organisation erhalten eine E-Mail, wenn eine Meldung eingeht, und finden sie unter Sicherheit › Berichte › Sicherheitshinweise › Private Meldungen. Die Administratoren des Repositorys finden sie auf ihrer eigenen Seite unter /_app/security-reports.

• Meldung annehmen macht aus der Meldung einen Hinweisentwurf, lädt die meldende Person als Mitwirkende dazu ein und bittet sie, eine Nennung als reporter anzunehmen.
• Nicht annehmen schließt die Meldung mit einem Grund: keine Schwachstelle, Duplikat, außerhalb des Geltungsbereichs, Spam oder Sonstiges.

In beiden Fällen wird die meldende Person per E-Mail informiert. Eine meldende Person kann eine Meldung zurückziehen, bis über sie entschieden ist. Eine abgelehnte Meldung wird 2 Jahre nach der Ablehnung gelöscht. Angenommene Meldungen und ihre Hinweise bleiben bei deiner Organisation.

Abhängigkeits-Scanning

Ein veröffentlichter Hinweis wird jeden Tag und direkt nach der Veröffentlichung mit dem Abhängigkeitsinventar deiner Organisation abgeglichen: Ein Repository, das von einer betroffenen Version abhängt, erhält einen Befund unter Sicherheit › Befunde › Abhängigkeiten, mit der FFSA-ID des Hinweises, wie jede andere Schwachstelle. Ziehst du den Hinweis zurück, verschwinden die Befunde, die er ausgelöst hat.

Für andere Organisationen wird ein Hinweis nur abgeglichen, wenn er im Plattform-Feed von fremforge steht. Dafür muss, jeden Tag erneut geprüft, gelten:

• das Repository ist öffentlich; und
• deine Organisation besitzt nachweislich jedes betroffene Paket: ein Paket deiner Organisation in der Paket-Registry von frem.sh oder ein Go-Modul unter frem.sh/<your organisation>/; oder fremforge hat den Hinweis geprüft und freigegeben.

Der Besitz ergibt sich aus den eigenen Aufzeichnungen von frem.sh, nie aus dem Paketnamen: Ein npm-Scope oder ein Modulpfad, der dem Namen deiner Organisation nur ähnelt, zählt nicht. Verlierst du das Paket oder machst du das Repository privat, verlässt der Hinweis den Plattform-Feed beim nächsten täglichen Lauf. Der Plattform-Feed wird unter /_app/api/v1/advisories?scope=platform ausgeliefert, und fremforge führt ihn in die OSV-Datenbanken zusammen, die seine Scanner lesen.

Zurückziehen, schließen, löschen

• Ein veröffentlichter Hinweis wird zurückgezogen, nie gelöscht. Er bleibt mit gesetztem withdrawn im Feed, sodass Scanner erfahren, dass er nicht mehr gilt.
• Einen Entwurf, den du nicht veröffentlichst, kannst du schließen (und wieder öffnen) oder mit seinen Kommentaren löschen.

Nennungen

Nenne die Personen, die die Schwachstelle gefunden, gemeldet oder behoben haben, über ihren frem.sh-Login und einen OSV-Credit-Typ. Eine Nennung wird erst öffentlich gezeigt und exportiert, wenn die genannte Person sie angenommen hat, auf ihrer eigenen Seite unter /_app/security-reports. Eine Nennung deiner selbst braucht keine Annahme.

Export: OSV und CSAF

Jeder Hinweis, Entwürfe eingeschlossen, kann heruntergeladen werden als:

• OSV 1.6: das Format, das Abhängigkeits-Scanner lesen (osv-scanner, Trivy und das eigene Abhängigkeits-Scanning von fremforge);
• CSAF 2.0: ein Dokument csaf_security_advisory, das maschinenlesbare Hinweisformat, das Leitlinien zum EU Cyber Resilience Act und das BSI von Herstellern erwarten. Ein Entwurf ist TLP AMBER mit Status draft, ein veröffentlichter Hinweis TLP WHITE mit Status final.

Jeder Download wird im Audit-Log erfasst (security.advisory.exported), weil der Export eines Entwurfs eine noch nicht behobene Schwachstelle beschreibt.

Der öffentliche OSV-Feed

Veröffentlichte Hinweise öffentlicher Repositorys werden ohne Authentifizierung ausgeliefert, älteste Änderung zuerst, höchstens 100 pro Seite:

# The first page
curl -s 'https://frem.sh/_app/api/v1/advisories?limit=100'

# The next page: pass the `next` value of the previous answer as `since`
curl -s 'https://frem.sh/_app/api/v1/advisories?since=2026-10-25T00:00:00Z'

# One advisory
curl -s https://frem.sh/_app/api/v1/advisories/FFSA-xxxx-xxxx-xxxx

Jeder Eintrag folgt dem OSV-Schema, mit der CVE-ID (falls vorhanden) als Alias und database_specific.source auf fremforge gesetzt. Ob das Repository öffentlich ist, wird bei jeder Anfrage geprüft, sodass ein Hinweis eines privat gemachten Repositorys beim nächsten Abruf nicht mehr ausgeliefert wird. Die öffentlichen Abrufe sind auf 60 Anfragen pro Minute und Client-Adresse begrenzt (darüber 429).

Eine CVE-ID beantragen

fremforge ist keine CVE Numbering Authority und beantragt keine CVE-IDs für dich. Unter CVE-ID beantragen gibt dir ein Hinweis seinen Inhalt als Text für das CVE-Antragsformular von MITRE oder für die CNA, die dein Projekt abdeckt, falls es eine gibt. Sende ihn selbst ab und trag dann die erhaltene CVE-ID im Hinweis ein. Die API liefert denselben Text unter /orgs/{org}/security-advisories/{id}/cve-request.

Der EU Cyber Resilience Act

Der CRA erwartet von einem Hersteller, dass er Schwachstellen in seinen Produkten behandelt: sie behebt und Informationen über behobene veröffentlicht. Hinweise mit CSAF-Export unterstützen das. Sie machen dich nicht allein konform, und fremforge meldet nichts für dich an die ENISA oder ein nationales CSIRT. Die Meldung nach Artikel 14 des CRA bleibt bei dir.

Noch nicht verfügbar

• Ein temporärer privater Fork, um die Korrektur darin zu entwickeln: nicht angeboten, siehe Veröffentlichen.

API

findings:read liest nur veröffentlichte Hinweise öffentlicher Repositorys, und nur mit angenommenen Nennungen. Entwürfe, geschlossene Hinweise, Hinweise privater Repositorys und die Kommentare jedes Hinweises brauchen advisories:read, das in findings:read nicht enthalten ist und das für CI-Jobs ausgestellte Tokens standardmäßig nicht haben. Eine Nennung bezeichnet einen frem.sh-Benutzer: Ein unbekannter Login wird abgewiesen.

Die vollständigen Schemas stehen in der API-Referenz.