owasp/packmanEin Dokumentations- und Tracking-Projekt mit dem Ziel, Paketverwaltungssysteme sicherer zu machen.
Ein Dokumentations- und Tracking-Projekt mit dem Ziel, Paketverwaltungssysteme sicherer zu machen. Siehe Issues für eine sehr grobe Liste einiger damit zusammenhängender Probleme, die wir gesehen haben.
| Sprache | Name | Stufe | Kontrollen | Packman-Leitung | Packman-Seite |
|---|---|---|---|---|---|
| JavaScript | npm | 1 | npm | ||
| Ruby | RubyGems | 1 | rubygems | ||
| Python | PyPi | 1 | pip/pypi | ||
| Java | Maven Central | 2 | maven central | ||
| Java | Android Central | ? | |||
| .Net | NuGet | 2 | nuget | ||
| Docker Hub | Docker | 1 | |||
| Golang | go get | 1 | golang | ||
| PHP | Composer | ? | |||
| Cocoa | Cocoa Pods | ? | |||
| Swift | Swift Package Manager | 1 | swiftpm | ||
| Rust | Cargo | 2? | rustcargo |
Die folgenden Abschnitte beschreiben jede der in der obigen Tabelle genannten Kontrollen genauer.
Starke Authentifizierung bedeutet, dass das System Folgendes verlangt:
Da die Möglichkeit, neuen Code an einen Paketmanager zu pushen, eine mächtige Funktion ist, ist es wichtig zu wissen, dass dies nicht einfach durch Erraten des Passworts eines Maintainers erreicht werden kann. Implementierung von MFA
Um diese Anforderung zu erfüllen, muss der Paketmanager eine Möglichkeit haben, Sicherheitsinformationen aus der Community zu empfangen, sowie einen Prozess zur Bearbeitung solcher Rückmeldungen. Eine veröffentlichte E-Mail-Adresse wie security@ zusammen mit einem Mechanismus, der sicherstellt, dass die Rückmeldung erfasst und beantwortet wird, würde diese Anforderung erfüllen.
Pakete können selbst Probleme erkennen oder über Probleme informiert werden. Die Plattform sollte eine Möglichkeit unterstützen, mit der ein Paket-Maintainer eine Version mit einem Sicherheitsproblem melden kann und:
Pakete müssen in irgendeiner Weise an eine explizite Version des Codes (einen Tag?) in einem bekannten öffentlichen Repository (bitbucket.org, github.com) gebunden sein.
Wenn Pakete aktualisiert werden, sollten alle Maintainer dieses Pakets benachrichtigt werden.
Wenn Sicherheitsprobleme in einem Paket festgestellt werden, sollte es für einen Verbraucher eine Möglichkeit geben, diese zu überprüfen. Dies könnte ein Befehl sein, der es dem Verbraucher ermöglicht, nach bekannten Problemen zu suchen.
Es sollte Entwicklern möglich sein, ihren Code zu signieren. Wenn sie das tun, sollte der Paketmanager die Signaturen verifizieren und eine Möglichkeit bereitstellen, diese an die Verbraucher des Pakets zu verteilen.
Der Paketmanager stellt eine Methode zur Überprüfung der Integrität des heruntergeladenen Pakets bereit.
Keine - es findet keine Integritätsprüfung statt Teilweise - die Integritätsprüfung erfolgt mithilfe einer schwachen Methode* Ja - die Prüfung erfolgt mithilfe einer ausreichend sicheren Methode
Die Plattform kann statische Codeanalyse anbieten, um potenzielle Probleme in wichtigen Bibliotheken proaktiv zu erkennen.
Die Plattform kann Sicherheitslücken in Bibliotheken verfolgen, von denen das Paket abhängt (Upstream-Pakete), und Maintainer benachrichtigen, wenn dies der Fall ist.
Der Paketmanager sollte bei der Installation von Paketen keinen Code ausführen.
Der Paketmanager sollte keine Informationen über das Projekt sammeln, das die Abhängigkeit verwendet.
Das Paketverwaltungssystem sollte einen Leitfaden für Rollen in einem Projekt haben, der einen Nachfolgeplan und Bedingungen für die aktive Mitarbeit enthält.
Die Maintainer des Paketverwaltungssystems sollten einen Prozess zur Überprüfung der Rollen in Projekten haben, um sicherzustellen, dass die Maintainer aktiv sind.
Verbraucher von Bibliotheken sollten in der Lage sein, ihr Interesse oder ihre Zustimmung zu einer bestimmten Bibliothek zu kennzeichnen, sodass sie sicherstellen können, dass Builds nur Bibliotheken verwenden, die sie auf bestimmte Weise gekennzeichnet haben. Z. B. als code-reviewt markiert.
Der Paketmanager bietet eine gewisse Kontrolle, um zu verhindern, dass die Anmeldeinformationen / das Token / die Sitzung als Teil des Paketinhalts preisgegeben werden.
Keine - es ist keine Kontrolle vorhanden, und der Benutzer muss sich selbst schützen Teilweise - Kommentar einfügen Ja - Anmeldeinformationen / Token werden entweder von der Veröffentlichung ausgeschlossen oder durch einen automatisierten Prozess widerrufen, der durch die Veröffentlichung eines Pakets ausgelöst wird. Benutzer sollten in irgendeiner Weise benachrichtigt werden, dass eine Maßnahme ergriffen wurde.
| Kontrolle | Stufe 1 | Stufe 2 | Stufe 3 |
|---|
| Starke Authentifizierung | ☐ | ☑ | ☑ |
| MFA zum Veröffentlichen von Artefakten | ☐ | ☑ | ☑ |
| Sicherheitskontakte | ☐ | ☑ | ☑ |
| Pakete können über Sicherheitsprobleme informieren | ☐ | ☑ | ☑ |
| Codepaket an Quellcode gebunden | ☐ | ☑ | ☑ |
| Verhindert die Veröffentlichung von Anmeldeinformationen | ☐ | ☑ | ☑ |
| Update-Benachrichtigungen | ☐ | ☑ | ☑ |
| Codesignierung | ☐ | ☐ | ☑ |
| Integritätsprüfung | ☐ | ☐ | ☑ |
| Codeanalyse (statisch) | ☐ | ☐ | ☑ |
| Code-Abhängigkeitsanalyse | ☐ | ☐ | ☑ |
| Paketmanager führt keinen Code aus | ☐ | ☐ | ☑ |
| Paketmanager sammelt keine Informationen | ☐ | ☐ | ☑ |
| Leitfaden für Projektrollen | ☐ | ☐ | ☑ |
| Überprüfung der Projektrollen | ☐ | ☐ | ☑ |
| Bibliotheks-Tagging auf Kontoebene | ☐ | ☐ | ☐ |
