Malware-Scan
fremforge betreibt einen ClamAV-basierten Scanner vor den Upload-Wegen, die unter Upload-Wege aufgeführt sind. Passt eine Signatur, wird der Upload mit HTTP 422 abgewiesen, und ein Befund landet im Malware-Scan-Log des Mandanten.
Der Scanner läuft ohne Cisco Talos und ohne abuse.ch. Beide knüpfen die kommerzielle Nutzung an eine kostenpflichtige Lizenz, und wir wollen keinen Unterauftragsverarbeiter im Scan-Pfad, den wir nicht vollständig zuordnen können.
Signatur-Stack
| Feed | Was er abdeckt | Takt | Lizenz |
|---|---|---|---|
| SaneSecurity | Gängige E-Mail- und Makro-Malware, Phishing, JS-Dropper | Alle 4 h von einem EU-Mirror abgerufen | Kostenlos, spendenfinanziert |
| YARA-Forge Core | TTPs von Angreifergruppen, Packer, Web-Shells, native Payloads. Sammlung aus über 45 geprüften Repositorys mit YARA-Regeln (signature-base von Florian Roth, DidierStevens usw.) | Alle 4 h abgerufen, Upstream-Releases wöchentlich | DRL 1.1, kommerzielle Nutzung mit Namensnennung erlaubt |
| Linux Malware Detect (LMD) | Serverseitige Linux-Payloads: Web-Shells, Kryptominer, Backdoors. Statischer Datensatz von rfxn.com | Alle 4 h abgerufen, Upstream täglich | GPLv2 |
| EICAR-Testsignatur | Die Standard-Signatur für Smoke-Tests von Malware-Scans, bei jeder Aktualisierung neu eingespielt | Statisch, per ConfigMap eingebunden | Gemeinfrei |
Die Aktualität der Feeds wird von den Betreibern bei fremverk überwacht; Kunden sehen die Aktualität der Signaturen nicht direkt. Die SLA deckt die Verfügbarkeit des Scanners ab.
Namensnennung. YARA-Forge Core wird von YARA-Forge aus öffentlichen Repositorys mit YARA-Regeln zusammengestellt, und jede Regel nennt in ihren Metadaten ihre Autoren. Sie wird unter der Detection Rule License 1.1 verwendet. Die Signaturen von Linux Malware Detect stammen von R-fx Networks. Siehe Hinweise zu Drittanbietern.
Upload-Wege
Gescannt, fail-closed (der Upload wird abgewiesen, wenn der Scanner nicht erreichbar ist):
- PUT von LFS-Objekten
- POST von Anhängen an Issues und PRs
- PUT / POST in die Paket-Registry, jeder Pakettyp (npm, Maven, PyPI, NuGet, Cargo, Container-Layer und alle übrigen), einschließlich Veröffentlichungen aus Jobs auf von fremforge gehosteten Runnern in die Registry einer Organisation
Ein Upload, der größer als 4 GiB ist, kann nicht vollständig gescannt werden und wird mit HTTP 413 abgewiesen.
Nur gescannt, wenn deine Organisation es einschaltet (standardmäßig aus):
- Pakete und Container-Images, die über den Abhängigkeits-Proxy abgerufen werden. Siehe Abrufe über den Abhängigkeits-Proxy.
NICHT gescannt:
- Pushes über das Git-Protokoll (Git-Objekte). Die Erkennung von Secrets beim Push übernimmt separat der Push-Schutz.
- Workflow-Artefakte. Sie sind kurzlebig, auf den Mandanten beschränkt, und die Richtlinie sagt bereits: „Nimm keine Artefakte an, denen du nicht vertraust." Modelldateien darunter prüft das Modell-Scanning, nur als Befunde.
Abrufe über den Abhängigkeits-Proxy
Was der Abhängigkeits-Proxy aus einer Upstream-Registry abruft (Paketdateien von npm, PyPI, Maven, NuGet, Go, Cargo, Helm und RPM sowie Container-Image-Layer), wird standardmäßig nicht mit ClamAV gescannt. Das entspricht GitHub und GitLab, die Paket-Downloads ebenfalls nicht auf Viren scannen: Öffentliche Registrys erkennen Malware, wenn ein Paket veröffentlicht wird, und veröffentlichen sie als Malware-Advisory.
Was für jede Organisation weiterhin gilt, ob der ClamAV-Scan an oder aus ist:
- Bekanntermaßen bösartige Pakete. Jede Paketversion, die der Proxy ausliefert, wird gemäß deiner Paketrichtlinie mit den OSV-Malware-Advisories
MAL-abgeglichen. Ein Treffer wird für jede Organisation abgewiesen, unabhängig vom Modus der Richtlinie (seit dem 2026-10-11; für die eigenen internen Organisationen von fremforge seit dem 2026-10-10): Der Download antwortet mit403und dem Grund, und die Version wird aus den Paket-Metadaten, die der Proxy ausliefert, weggelassen, sodass Paketmanager auf eine Version auflösen, die nicht bösartig ist. Siehe Bösartige Pakete. - Inhalte, die ClamAV bereits als infiziert erkannt hat, bleiben gesperrt. Eine Datei oder ein Image-Layer, den ein Scan als infiziert erkannt hat, wird jeder Organisation verweigert, ob diese Organisation scannt oder nicht.
- Uploads und gepushte Images werden immer gescannt, wie unter Upload-Wege aufgeführt.
Damit der Proxy das, was er abruft, mit ClamAV scannt, schalte Proxy-Virenscan: abgerufene Pakete und Images scannen (ClamAV) unter Organisationsverwaltung → Build und Deployment → Abhängigkeits-Proxy ein, oder setze malware_scan: true mit PUT /orgs/{org}/dependency-proxy. Ist das eingeschaltet, wird jede Paketdatei und jeder Image-Layer, den der Proxy für deine Organisation abruft, durch ClamAV gestreamt, und was als infiziert erkannt wird oder nicht vollständig gescannt werden kann, wird zurückgehalten. Dazu gehört eine Datei, die größer als 4 GiB ist, außer einem Modell-Layer im Format safetensors oder GGUF, der seine Formatprüfung besteht. Ein Image-Layer-Scan, dem die Zeit ausgeht, ist kein Urteil: Der Layer wird zurückgehalten und in die Warteschlange des Hintergrund-Layer-Scanners von fremforge gestellt, und ein späterer Pull wird bedient, sobald dieser Scan bestanden ist. Eine Paketdatei, deren Scan die Zeit ausgeht, wird genauso behandelt: Sie wird dieser Anfrage vorenthalten, im Hintergrund gescannt und bei einer späteren Anfrage ausgeliefert, sobald dieser Scan bestanden ist. Ein RPM wird währenddessen, wie alle RPM-Inhalte, nur im eigenen Bereich deiner Organisation gespeichert und gescannt. Eine Datei, die der Proxy für eine andere Organisation ohne Scan zwischengespeichert hat, wird erneut abgerufen und gescannt, bevor sie deiner Organisation ausgeliefert wird.
Neue Images zurückhalten, bis der Malware-Scan fertig ist (block_until_scanned) wartet auf diesen Scan und braucht daher den eingeschalteten ClamAV-Scan. Eine Anfrage, die block_until_scanned eingeschaltet und malware_scan ausgeschaltet ließe, wird mit 400 scan-pair abgewiesen.
Was bei einem Treffer passiert
- Der Proxy weist den Upload mit HTTP 422 ab, mit einem Body, der die Signatur, den SHA-256 der abgewiesenen Bytes und einen Verweis auf den Ausnahme-Ablauf nennt.
- Über den Endpunkt
/internal/malware-scan/ingestder API (gegenseitige Authentifizierung, Bearer + IP-Allowlist) wird ein Befund inmalware_scan_findingsgeschrieben. - Der Befund erscheint sofort in der Mandanten-Administration unter Sicherheit, Malware-Scan, mit dem Upload-Pfad, der getroffenen Signatur, der Person, die den Upload versucht hat, und der Dateigröße.
Ausnahmen (Fehlalarme)
Manche Signaturen schlagen bei legitimen Test-Fixtures, Proben aus der Sicherheitsforschung oder harmlosen Artefakten an, die zufällig einem alten Muster entsprechen. Mandanten-Admins können eine Ausnahme anlegen, die ein bestimmtes Paar aus SHA-256-Hash und Repository freigibt.
- Mandanten-Administration → Sicherheit › Befunde › Malware. Klappe Aktive Ausnahmen auf und klicke auf Ausnahme hinzufügen.
- Füge den SHA-256 der abgewiesenen Datei ein (steht in der 422-Antwort).
- Wähle den Geltungsbereich: nur dieses Repository oder alle Repositorys der Organisation.
- Setze ein Ablaufdatum (Standard 90 Tage; höchstens 1 Jahr).
- Füge eine Begründung hinzu (Freitext, im Audit-Log der Organisation festgehalten).
Eine Ausnahme setzt nur die Entscheidung für den per Hash getroffenen Treffer außer Kraft. Passt eine andere Signatur auf dieselben Bytes, wird der Upload trotzdem abgewiesen. Die Betreiber bei fremverk prüfen Ausnahmen vierteljährlich im Rahmen des Sicherheits-Reviews.
Über die REST-API
Befunde und Ausnahmen des Malware-Scans stehen über die öffentliche API zur Verfügung. Nutze das, wenn du Alarme zu abgewiesenen Uploads an ein externes Ticketsystem anbindest, den Lebenszyklus von Ausnahmen skriptest oder einen KI-Agenten damit arbeiten lässt.
- Befunde auflisten
GET /_app/api/v1/orgs/:slug/malware-scan/findings - Einen Befund verwerfen
POST /_app/api/v1/orgs/:slug/malware-scan/findings/:id/dismiss - Ausnahmen auflisten
GET /_app/api/v1/orgs/:slug/malware-scan/overrides - Ausnahme anlegen
POST /_app/api/v1/orgs/:slug/malware-scan/overridesBody:{ "kind": "file", "signature": "sha256:...", "reason": "test fixture", "expires_at": "2027-01-01T00:00:00Z" } - Ausnahme widerrufen
DELETE /_app/api/v1/orgs/:slug/malware-scan/overrides/:id
Das Auflisten erfordert den Scope findings:read, das Verwerfen eines Befunds findings:write. Das Anlegen oder Widerrufen einer Ausnahme erfordert policy:write, weil eine Ausnahme Uploads vom Scan ausnimmt; das Runner-Token eines CI-Jobs trägt diesen Scope nie. Verwende ein Personal Access Token (PAT):
curl -X POST \
-H "Authorization: Bearer ${FREMFORGE_PAT}" \
-H "Content-Type: application/json" \
-d '{"kind":"file","signature":"sha256:abc123...","reason":"known-clean test artefact","expires_at":"2027-01-01T00:00:00Z"}' \
https://frem.sh/_app/api/v1/orgs/acme/malware-scan/overridesDie vollständige OpenAPI-Spezifikation findest du in der Referenz der öffentlichen REST-API.
SLA und Fail-closed-Verhalten
Ist der ClamAV-Daemon nicht erreichbar, werden Uploads mit HTTP 503 und einem Retry-After abgewiesen. Das ist die Fail-closed-Entscheidung gemäß unserer Acceptable Use Policy. Die Alternative (fail-open während eines Scanner-Ausfalls) öffnet ein Zeitfenster, in dem die Zusage der AUP stillschweigend umgangen wird; diesen Tausch halten wir nicht für lohnend. Fällt der Scanner aus, werden die Betreiber innerhalb von 5 Minuten alarmiert.
EICAR-Smoke-Test
Ein Canary-CronJob lädt alle 30 Minuten die Standard-EICAR-Testdatei hoch und prüft, dass der Upload abgewiesen wird. Gelingen drei Canary-Läufe in Folge (das heißt, die Abweisung bleibt aus), werden die Betreiber alarmiert. Das deckt den Fall ab, dass die Signaturdatenbank zwar sauber ausgeliefert, aber nicht geladen wurde.