Ghostwriter

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 5139 ist passing So können Sie ihn einbetten:

Dies sind die Kriterien das Level Passing. Sie können auch die Kriterien für die Level Silber oder Gold sehen.

        

 Grundlagen 13/13

  • Identifizierung

    The SpecterOps project management and reporting engine

    Welche Programmiersprache wird verwendet, um das Projekt umzusetzen?
  • Grundlegende Informationen auf der Projektwebseite


    Die Projekt-Website MUSS prägnant beschreiben, was die Software tut (welches Problem löst sie?). [description_good]

    The project is briefly described on the welcome page of the project's wiki and in the repository's README: https://www.ghostwriter.wiki/ https://github.com/GhostManager/Ghostwriter/blob/master/README.md



    Die Projekt-Website MUSS Informationen darüber enthalten, wie Feedback erhalten und gegeben werden kann (als Fehlerberichte oder Verbesserungsvorschläge), und wie man zur Softwareentwicklung beitragen kann. [interact]

    The wiki discusses how to provide feedback and report issues: https://www.ghostwriter.wiki/known-issues-and-faq/getting-help-with-a-problem



    Die Informationen darüber, wie jemand beitragen kann, MÜSSEN den Prozess erklären (z.B. wie werden Pull-Requests verwendet?) (URL erforderlich) [contribution]

    The wiki walks through how to contribute: https://www.ghostwriter.wiki/development/contributing-to-the-project

    The wiki also documents the project's code style required for contributions: https://www.ghostwriter.wiki/coding-style-guide/style-guide



    Die Informationen darüber, wie jemand beitragen können, SOLLTEN die Anforderungen für akzeptable Beiträge (z. B. einen Hinweis auf jeden erforderlichen Programmierstandard) enthalten. (URL erforderlich) [contribution_requirements]
  • FLOSS-Lizenz

    Unter welcher Lizenz/welchen Lizenzen ist das Projekt veröffentlicht?



    Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. [floss_license]

    All code is released publicly on GitHub, the project road map is tracked publicly on Trello, and everything is under the BSD 3 license.

    https://github.com/GhostManager/Ghostwriter/blob/master/LICENSE https://trello.com/b/sF4om6Fy/ghostwriter The BSD-3-Clause license is approved by the Open Source Initiative (OSI).



    Es wird EMPFHOLEN, dass alle erforderlichen Lizenz(en) für die vom Projekt entwickelte Software von der Open Source Initiative (OSI) anerkannt werden. [floss_license_osi]

    The BSD-3-Clause license is approved by the Open Source Initiative (OSI).



    Das Projekt MUSS die Lizenz(en) seiner Erzeugnisse an einem üblichen Ort in ihrem Quell-Repository veröffentlichen. (URL erforderlich) [license_location]
  • Dokumentation


    Das Projekt MUSS eine grundlegende Dokumentation für die vom Projekt entwickelte Software liefern. [documentation_basics]

    The project team maintains a wiki that covers installation, usage, maintenance, and other required information: https://ghostwriter.wiki/



    Das Projekt MUSS Referenzdokumentationen enthalten, die externe Schnittstellen (beides, Eingabe und Ausgabe) der vom Projekt entwickelten Software beschreiben. [documentation_interface]

    The project team maintains a wiki that covers installation, usage, maintenance, and other required information: https://ghostwriter.wiki/


  • Andere


    Die Projekt-Seiten (Website, Repository und Download-URLs) MÜSSEN HTTPS mit TLS unterstützen. [sites_https]

    Das Projekt MUSS einen oder mehrere Mechanismen zur Diskussion (einschließlich der vorgeschlagenen Änderungen und Issues) haben, die durchsuchbar sind, bei denen Nachrichten und Themen durch URL adressiert werden, neue Personen an einigen der Diskussionen teilnehmen können und keine lokale Installation von proprietärer Software erfordern. [discussion]

    Project discussions (and the project team) are available via GitHub Issues, Trello, and the #ghostwriter channel in the SpecterOps BloodHound Slack Team (https://bloodhoundgang.herokuapp.com/).



    Das Projekt SOLLTE Dokumentationen in englischer Sprache zur Verfügung stellen und in der Lage sein, Fehlerberichte und Kommentare zum Code in Englisch zu akzeptieren. [english]

    The project team maintains a wiki (in English) that covers installation, usage, maintenance, and other required information: https://ghostwriter.wiki/. All discussion of enhancements, issues, etc. is in English.



    The project MUST be maintained. [maintained]

    The project team actively maintains Ghostwriter and publishes regular releases and blog posts.



(Erweitert) Welche anderen Benutzer haben zusätzliche Rechte zum Bearbeiten dieses Badge-Antrags? Derzeit: []



  • Öffentliches Versionskontroll-Source-Repository


    Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. [repo_public]

    Repository on GitHub, which provides public git repositories with URLs.



    Das Quell-Repository des Projekts MUSS verfolgen, welche Änderungen vorgenommen wurden, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    Um eine kollaborative Überprüfung zu ermöglichen, MUSS das Quell-Repository des Projekts Zwischenversionen für die Überprüfung zwischen Releases enthalten. Es DARF NICHT nur endgültige Veröffentlichungen enthalten. [repo_interim]

    The project publishes release candidates for review. Here is a recent example: https://github.com/GhostManager/Ghostwriter/releases/tag/2.2-rc1



    Es ist EMPFOHLEN, dass eine gemeinsame genutzte Versionskontrollsoftware (z.B. git oder mercurial) für das Source-Repository des Projekts verwendet wird. [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.


  • Einzigartige Versionsnummerierung


    Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. [version_unique]

    The project follows GitHub's guidelines for Semantic Versioning when naming versions. Each release has a unique version number and identifier (e.g., v2.2.0, v2.2.1-rc1).

    https://github.com/GhostManager/Ghostwriter/releases



    Es ist EMPFHOLEN, dass ein Semantic Versioning (SemVer) oder Calendar Versioning (CalVer) Versionsnummerierungsformat für Releases verwendet wird. Es ist EMPFHOLEN, dass Anwender des CalVer Formates auch die Micro Ebene mit angeben. [version_semver]


    Es wird erwartet, dass Projekte jedes Release innerhalb ihres Versionskontrollsystems identifizieren. Zum Beispiel wird erwartet, dass die Projekte, die git verwenden, jedes Release mit git-Tags identifizieren. [version_tags]

    The project tags releases using git tags: https://github.com/GhostManager/Ghostwriter/releases


  • Versionshinweise


    Das Projekt MUSS zu jedem Update Releasenotes enthalten, die eine lesbare Zusammenfassung der wichtigsten Änderungen der Version sind, damit Benutzer/innen sehen können, ob sie aktualisieren sollten und was die Auswirkungen des Updades sind. Die Releasenotes DÜRFEN NICHT die Rohausgabe eines Versionskontrollprotokolls sein (z. B. die "git log"-Befehlsergebnisse sind keine Releasenotes). Für Projekte, deren Ergebnisse nicht für die Wiederverwendung an mehreren Standorten bestimmt sind (z. B. die Software für eine einzelne Website oder Dienstleistung) und eine kontinuierliche Lieferung verwenden, können Sie "N/A" auswählen. (URL erforderlich) [release_notes]

    The project publishes a CHANGELOG.RST, release notes in the release descriptions, and an easier to read, searchable version on the wiki:

    https://github.com/GhostManager/Ghostwriter/releases/tag/v2.2.1 https://www.ghostwriter.wiki/change-logs/28-may-2021-v2.2.1 https://github.com/GhostManager/Ghostwriter/blob/master/DOCS/CHANGELOG.RST



    Die Releasenotes MÜSSEN jede öffentlich bekannte Laufzeit-Sicherheitslücke mit einer CVE-Zuweisung oder Ähnlichem kennzeichnen, die in der aktuellen veröffentlichten Version behoben sind. Dieses Kriterium darf als nicht anwendbar (N/A) markiert werden, wenn Benutzer typischerweise nicht selbst die Software aktualisieren. Diese Kirterium trifft nur auf die Projektergebnisse zu, nicht auf Abhängikeiten. Wenn keine Releasenotes vorhanden sind oder keine öffentlich bekannten Sicherheitslücken bekannt sind, wählen Sie (N/A). [release_notes_vulns]

    There have been no major vulnerabilities like this to report, but the release notes have acknowledged when changes were the result of an identified security issue in a dependency. For example:

    Updated TinyMCE WYSIWYG editor and related JavaScript to v5.7.0 * Resolved potential Cross-Site Scripting vulnerability discovered in previous version


  • Bug-Report-Prozess


    Das Projekt muss einen Prozess für Benutzer enthalten, um Fehlerberichte zu senden (z. B. mit einem Issue-Tracker oder eine Mailing-Liste). (URL erforderlich) [report_process]

    The project uses GitHub Issues as documented here: https://www.ghostwriter.wiki/known-issues-and-faq/getting-help-with-a-problem



    Das Projekt SOLLTE einen Issue-Tracker für die Nachverfolgung einzelner Issues verwenden. [report_tracker]

    The project uses a public Trello board to track issues and features: https://trello.com/b/sF4om6Fy/ghostwriter



    Das Projekt MUSS eine Mehrheit der in den letzten 2-12 Monaten eingereichten Fehlerberichte berücksichtigen; Die Antwort muss keine Korrektur enthalten. [report_responses]

    The project team always acknowledges GitHub Issues, even if the issue cannot be fixed immediately. The team cannot always respond right away, but does their best to keep up with issues and respond with complete answers.

    https://github.com/GhostManager/Ghostwriter/issues



    Das Projekt SOLLTE auf eine Mehrheit (>50%) der Verbesserungsvorschläge in den letzten 2-12 Monaten (einschließlich) reagieren. [enhancement_responses]

    The project team always acknowledges GitHub Issues, even if the enhancement cannot be implemented immediately. The team cannot always respond right away, but does their best to keep up with issues and respond with complete answers.

    https://github.com/GhostManager/Ghostwriter/issues



    Das Projekt MUSS ein öffentlich zugängliches Archiv für Berichte und Antworten für die spätere Suche haben. (URL erforderlich) [report_archive]

    All reports are in GitHub Issues which are searchable for later review.

    https://github.com/GhostManager/Ghostwriter/issues


  • Anfälligkeits-Prozessbericht


    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_report_process]

    A process for reporting a bug or security vulnerability is outlined in the wiki: https://www.ghostwriter.wiki/known-issues-and-faq/getting-help-with-a-problem



    Falls das Projekt einen Kanal zur Übertragung von Schwachstellen besitzt, dann MUSS diese Informationsübertragung privat ablaufen. (URL erforderlich) [vulnerability_report_private]

    The project team discusses these issues openly. There has been no need to discuss anything in private, but there is a method of private contact. Anyone may contact the lead developer at chris.maddalena@protonmail.com (as published on GitHub).

    https://github.com/chrismaddalena



    Das Projekts MUSS mindestens binnen 14 Tagen, auf jeden in den letzten 6 Monaten erhaltenen Anfälligkeitsbericht, reagieren. [vulnerability_report_response]

    The team has responded within days of reports received in the project's lifetime. There have been no vulnerability reports in the past 6 months, but there was one Dependabot alert for TinyMCE that the team addressed immediately.


  • Produktivsystem


    Falls die vom Projekt entwickelte Software vor Benutzung kompiliert werden muss, MUSS das Projekt ein funktionierendes Buildsystem bereitstellen, das den Quellcode automatisch in Software übersetzt. [build]

    All pieces of the project that require any building are managed and built by docker-compose: https://www.ghostwriter.wiki/getting-started/installation



    Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompilieren von Software benutzt wird. [build_common_tools]

    The project uses common tools and frameworks like Docker, Django, PostreSQL, and Redis.



    Das Projekt SOLLTE allein mit FLOSS-Werkzeugen gebaut werden können. [build_floss_tools]

    All project components are open-source and freely available, including components used to build or run the project.


  • Automatisierte Test-Suite


    Das Projekt MUSS mindestens eine automatisierte Test-Suite verwenden, die öffentlich als FLOSS veröffentlicht wird (diese Test-Suite kann als separates FLOSS-Projekt gepflegt werden). Das Project MUSS verständlich zeigen oder dokumentieren, wie die Test-Suite ausgeführt wird (z. B. durch ein Continuous Integration (CI) Script oder als Dokumentation in Dateien, wie z. B. BUILD.md, README.md oder CONTRIBUTING.md). [test]

    The project follows the Django project's recommended practices for using Django's TestCase unit tests. Test coverage is monitored using Python coverage and Codecov.

    https://www.ghostwriter.wiki/development/testing-code https://app.codecov.io/gh/ghostmanager/Ghostwriter



    Eine Test-Suite SOLLTE in einer üblichen Weise für diese Programmiersprache aufrufbar sein. [test_invocation]

    All tests are invoked using the standard Django (or Python coverage) commands as documented by those projects and in the Ghostwriter wiki:

    https://www.ghostwriter.wiki/development/testing-code



    Es wird erwartet, dass die Test-Suite die meisten (oder idealerweise alle) Code-Zweige, Eingabefelder und Funktionalitäten abdeckt. [test_most]

    Tests are run against all code, regardless of the branch. GitHub Actions runs the full suite against all pull requests or commits to master. Further, the workflow must pass before the code can be committed.



    Es wird erwartet, dass das Projekt eine kontinuierliche Integration durchführt (wo neuer oder geänderter Code häufig in ein zentrales Code-Repository integriert wird und automatisierte Tests auf diesen Ergebnissen durchgeführt werden). [test_continuous_integration]

    GitHub Actions performs a complete build and install of Docker images, runs through the "getting started" instructions to prep the database, and runs all unit tests.


  • Neue Funktionalitätsüberprüfung


    Das Projekt MUSS allgemeine Grundregeln (formal oder nicht) haben, die als wesentliche neue Funktionalität der Software des Projektes hinzugefügt werden. Tests dieser Funktionalität sollten zu einer automatisierten Test-Suite hinzugefügt werden. [test_policy]


    Das Projekt MUSS nachweisen, dass die test_policy für das Hinzufügen von Tests in den jüngsten großen Änderungen an der Projektsoftware eingehalten wurde. [tests_are_added]

    The project has started tracking testing coverage with Codecov so it is publicly viewable and updated with each push: https://app.codecov.io/gh/ghostmanager/Ghostwriter



    Es wird erwartet, dass diese Richtlinien zum Hinzufügen von Tests (siehe test_policy ) in den Anweisungen für Änderungsvorschläge dokumentiert werden. [tests_documented_added]

    Testing steps and policy is documented here: https://www.ghostwriter.wiki/development/testing-code


  • Warnhinweise


    Das Projekt MUSS einen oder mehrere Compiler-Warn-Flags, einen "sicheren" Sprachmodus oder ein separates "Linter" -Tool verwenden, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium implementieren kann in der gewählten sprache [warnings]

    No part of the project requires compilation like this, so most of this is handled by the test cases.

    The project uses a documented mix of pre-commit hooks, IDE settings, and linter settings (Python Black and Flake8) to ensure code quality. Quality is also being monitored by Code Factor to guide the team towards problem areas.

    https://www.ghostwriter.wiki/coding-style-guide/style-guide https://www.codefactor.io/repository/github/ghostmanager/ghostwriter/issues



    Das Projekt MUSS auf Warnungen reagieren. [warnings_fixed]

    As mentioned above, no part of this project requires compilation, so this does not appear to be applicable. Otherwise, it is met by way of catching these common mistakes before the code is committed. Any Python compilation issues would prevent Django from functioning and prevent a release.



    Es wird erwartet, dass Projekte Warnungen in der Software, die durch das Projekt produziert wird, sorgfältig berücksichtigen. [warnings_strict]

    The project team is actively working towards providing user-friendly warnings and help messages when various runtime errors occur. For example, when attempting to generate a Microsoft Word document with Jinja2 a user may try to divide by zero. Rather than pass along the Jinja2 compilation error, the project filters it and produces a friendlier message explaining how to resolve the issue in their template.


  • Wissen über sichere Entwicklungspraktiken


    Das Projekt MUSS mindestens einen primären Entwickler haben, der weiß, wie man sichere Software entwerfen kann. (Siehe "Details" für spezifische Anforderungen.) [know_secure_design]

    The lead developer, Christopher Maddalena, is a security consultant with a background in Computer Science, web application security testing, and secure software development.



    Mindestens einer der primären Entwickler des Projekts MUSS über weitläufige Arten von Fehlern, die zu Schwachstellen in dieser Art von Software führen, Bescheid wissen sowie mindestens eine Methode, um jede von ihnen zu beseitigen oder zu mildern. [know_common_errors]

    In addition to the lead developer, the other primary contributors also have background in information security, web application testing, secure code reviews, and more.


  • Verwende grundlegend gute kryptographische Praktiken

    Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

    Die vom Projekt entwickelte Software MUSS standardmäßig nur kryptografische Protokolle und Algorithmen verwenden, die öffentlich sind und von Experten überprüft wurden (falls kryptographische Protokolle und Algorithmen verwendet werden). [crypto_published]

    The project does not require much cryptography, but Django uses it for securing user passwords and sensitive information. Ghostwriter uses the latest recommended cryptography libraries for this.

    Django documents it here: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/



    Wenn die Software, die durch das Projekt produziert wird, eine Anwendung oder Bibliothek ist, und ihr Hauptzweck nicht die Kryptographie ist, dann SOLLTE sie lediglich Software einbinden, die speziell für kryptographische Funktionen entworfen ist; Sie SOLLTE NICHT eine eigene Implementierung vornehmen. [crypto_call]

    The project does not implement its own cryptography. Only the major supported Python cryptography libraries are used.



    Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. [crypto_floss]

    The project uses Django's cryptography implementations which is FLOSS: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/



    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software, MÜSSEN Standard-Keylängen verwenden, die die NIST-Mindestanforderungen bis zum Jahr 2030 erfüllen (wie im Jahr 2012 festgelegt). Es MUSS möglich sein, die Software so zu konfigurieren, dass kürzere Keylängen vollständig deaktiviert werden können. [crypto_keylength]

    The project uses Django's cryptography implementations which follows these standards: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/



    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software DÜRFEN NICHT von defekten kryptographischen Algorithmen abhängen (z.B. MD4, MD5, Single DES, RC4, Dual_EC_DRBG) oder Chiffre-Modi verwenden, die dem Kontext unangemessen sind, außer sie sind notwendig, um kompatible Protokolle bereitzustellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch ein Protokoll erfordert und das Zielsystem keine sicherere Alternative anbietet). Die Dokumentation MUSS auf jegliche Sicherheitsrisiken hinweisen und bekannte Vorsichtsmaßnahmen beschreiben, sollten unsichere Protokolle unumgäglich sein. [crypto_working]

    The project uses Django's cryptography implementations which uses the recommended, standard Python libraries and their algorithms: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/



    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN NICHT nicht von kryptographischen Algorithmen oder Modi mit bekannten schweren Schwächen abhängen (z.B. SHA-1-Kryptographie-Hash-Algorithmus oder CBC-Modus in SSH). [crypto_weaknesses]

    The project uses Django's cryptography implementations which uses the recommended, standard Python libraries and their algorithms: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/



    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN Perfect Forward Secrecy für wichtige Vereinbarungsprotokolle implementieren, so dass ein Sitzungsschlüssel, der aus einer Reihe von Langzeitschlüsseln abgeleitet wird, nicht beeinträchtigt werden kann, wenn einer der Langzeitschlüssel in der Zukunft kompromittiert wird. [crypto_pfs]

    The project uses Django's security recommendations and features. Where this would most likely come into play, HTTPS traffic, the project uses an nginx server and Django manages the SSL as described here.

    https://docs.djangoproject.com/en/3.2/topics/security/#ssl-https



    Wenn die vom Projekt erzeugte Software Passwörter für die Authentifizierung von externen Benutzern speichert, MÜSSEN die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z.B. Argon2id, Bcrypt, Scrypt, or PBKDF2). Siehe auch OWASP Password Storage Cheat Sheet). [crypto_password_storage]

    The project uses Django's password management and user authentication mechanisms described here: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/



    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN alle kryptographischen Schlüssel und Nonces mit einem kryptographisch sicheren Zufallszahlengenerator erzeugen und DÜRFEN NICHT mit Generatoren arbeiten, die kryptographisch unsicher sind. [crypto_random]

    The project uses Django's password management and user authentication mechanisms described here: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/


  • Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe


    Das Projekt MUSS einen Auslieferungsmechanismus verwenden, der den MITM-Angriffen entgegenwirkt. Die Verwendung von https oder ssh + scp ist akzeptabel. [delivery_mitm]

    The project uses HTTPS and WebSockets Secure for communication. Here is the nginx.conf file for the webserver with the SSL configuration:

    https://github.com/GhostManager/Ghostwriter/blob/master/compose/production/nginx/nginx.conf



    Ein kryptographischer Hash (z.B. sha1sum) DARF NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. [delivery_unsigned]

    The project does not send or receive cryptographic material.


  • Öffentlich bekannte Schwachstellen wurden behoben


    Es DARF KEINE ungepatchte Schwachstelle von mittlerer oder höherer Schwere enthalten sein, die seit mehr als 60 Tagen öffentlich bekannt ist. [vulnerabilities_fixed_60_days]

    There are no unpatched public vulnerabilities in the project's codebase.



    Projekte SOLLTEN alle kritischen Schwachstellen schnell beheben, nachdem sie gemeldet wurden. [vulnerabilities_critical_fixed]

    The project team has addressed all reported vulnerabilities. In addition to that, the project team has paid a third party to perform a penetration test against the Ghostwriter production server and features and fixed all identified issues.


  • Andere Sicherheitsissues


    Die öffentlichen Repositorys DÜRFEN NICHT gültige private Zugriffsdaten enthalten (z. B. ein funktionierendes Passwort oder einen privaten Schlüssel), die den öffentlichen Zugriff einschränken sollen. [no_leaked_credentials]

    There is no sensitive information stored in the project's code repository. This is monitored using manual validation and tools like the OSSF's Scorecard (https://github.com/ossf/scorecard/).


  • Statische Codeanalyse


    Mindestens ein Tool zur Analyse statischer Codes (über Compiler-Warnungen und "sichere" Sprachmodi hinaus) MUSS vor der Veröffentlichung auf jede vorgeschlagene größere Produktionsversion der Software angewendet werden, wenn mindestens ein FLOSS-Tool dieses Kriterium in der ausgewählten Sprache implementiert. [static_analysis]

    Es wird davon ausgegangen, dass mindestens eines der statischen Analysewerkzeuge, die für das statische Analysekriterium verwendet wurde, Regeln oder Ansätze einschließt, um nach häufigen Schwachstellen in der analysierten Sprache oder Umgebung zu suchen. [static_analysis_common_vulnerabilities]

    GitHub's CodeQL app searches for common vulnerabilities.



    Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit statischer Codeanalyse entdeckt wurden, MÜSSEN nach der Entdeckung rechtzeitig behoben werden. [static_analysis_fixed]

    None have been found, but identified vulnerabilities would be addressed with the same alacrity as mentioned previously.



    Es wird EMPFOHLEN, dass eine statische Quellcode-Analyse bei jedem Commit oder zumindest täglich ausgeführt wird. [static_analysis_often]

    The CodeQL workflow fires with each commit and pull request.


  • Dynamische Codeanalyse


    Es ist EMPFHOLEN, dass mindestens ein dynamisches Analyse-Tool auf jede vorgeschlagene größere Veröffentlichung der Software vor seiner Freigabe angewendet wird. [dynamic_analysis]

    The project team tests and fuzzes Ghostwriter using Burp Suite Pro, a web application testing tool, to test changes.



    Es ist EMPFHOLEN, dass die vom Projekt entwickelte Software, falls sie Software von einer Speicher-unsicheren Sprache (z. B. C oder C ++) enthält, regelmäßig mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Anwendungs-Scanner) in Kombination mit einem Mechanismus zur Erkennung von Speichersicherheitsproblemen wie Puffer-Overwrites verwendet. Wenn das Projekt keine Software entwickelt, die in einer Speicher-unsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). [dynamic_analysis_unsafe]

    The project does not contain any code written in a memory-unsafe language, but the team does fuzz the web application and back-end to identify potential issues that might cause serious errors or expose the potential for misuse of a feature.



    Es ist EMPFHOLEN, dass das Projekt eine Konfigurations benutzt, die zumindest etwas dynamischen Analyse nutzt (wie z.B. testing oder fuzzing), welche Assertions erlauben. In vielen Fällen sollten diese Assertions nicht in Production Builds aktiviert sein. [dynamic_analysis_enable_assertions]

    The project team uses rulesets published by PortSwigger, the creator of Burp Suite, to fuzz the Ghostwriter server for automated dynamic testing.



    Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit dynamischer Codeanalyse entdeckt werden, MÜSSEN zügig behoben werden, nachdem sie bestätigt wurden. [dynamic_analysis_fixed]

    None have been found, but identified vulnerabilities would be addressed with the same alacrity as mentioned previously.



Die Daten sind unter der Creative Commons Attribution 3.0-Lizenz oder Nachfolder (CC-BY-3.0+) verfügbar, bereitgestellt von der Open Source Security Foundation unter den Nutzungsbedingungen. Es ist allen erlaubt, die Daten zu teilen und anzupassen, müssen aber einen angemessene Hinweis auf den Urheber geben. Bitte geben Sie als Urheber Christopher Maddalena und die OpenSSF Best Practices Badge Mitwirkenden an.

Projekt-Badge-Eintrag im Besitz von: Christopher Maddalena.
Eintrag erstellt: 2021-08-11 16:44:02 UTC, zuletzt aktualisiert: 2021-08-11 20:08:12 UTC. Letztes erreichtes Badge: 2021-08-11 20:08:12 UTC.

Zurück