thecrowler

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 8344 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 CROWler is a specialized web crawler developed to efficiently navigate and index web pages. This tool leverages the robust capabilities of Selenium and Google Chrome (to covertly crawl a site), offering a reliable and precise crawling experience. It is designed with user customization in mind, allowing users to specify the scope and targets of their crawling tasks.

    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]

    On the repository README.md we have:

    What is it? The CROWler is a specialized web crawler developed to efficiently navigate and index web pages. This tool leverages the robust capabilities of Selenium and Google Chrome (to covertly crawl a site), offering a reliable and precise crawling experience. It is designed with user customization in mind, allowing users to specify the scope and targets of their crawling tasks.

    To enhance its functionality, CROWler includes a suite of command-line utilities. These utilities facilitate seamless management of the crawler's database, enabling users to effortlessly add or remove websites from the Sources list. Additionally, the system is equipped with an API, providing a streamlined interface for database queries. This feature ensures easy integration and access to indexed data for various applications.

    Please check: https://github.com/pzaino/thecrowler#the-crowler



    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]

    On the contributing.md we have this section:

    Report bugs using Github's issues We use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy!

    Please check: https://github.com/pzaino/thecrowler/blob/main/CONTRIBUTING.md



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

    Non-trivial contribution file in repository: https://github.com/pzaino/thecrowler/blob/main/CONTRIBUTING.md.



    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]

    In the contributing.md file it's clearly explained that we use:

    Use a Consistent Coding Style 4 spaces for indentation rather than tabs You can try running gofmt for style unification

    Please check: https://github.com/pzaino/thecrowler/blob/main/CONTRIBUTING.md


  • 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]

    The Apache-2.0 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 Apache-2.0 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]

    Non-trivial license location file in repository: https://github.com/pzaino/thecrowler/blob/main/LICENSE.


  • Dokumentation


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

    Some documentation basics file contents found.



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

    The project provides comprehensive documentation on how to install, build from source and use.

    The README.md provides insight on how to build and instal and configure. While the Doc section shows how to use it.

    Link to README.md: https://github.com/pzaino/thecrowler#the-crowler Link to full documentation: https://github.com/pzaino/thecrowler/tree/main/doc Specifically on how to use: https://github.com/pzaino/thecrowler/blob/main/doc/usage.md


  • Andere


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

    Given only https: URLs.



    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]

    GitHub supports discussions on issues and pull requests.



    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]

    Documentation as linked above is ALL in English Language and reviewed to ensure clarity to the best of our abilities. Bug report is accepted through the usual github Issues.



    The project MUST be maintained. [maintained]


(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 includes interim releases (and also pre-releases for testing) as well as having an official Develop branch that is used to push code that needs also human testing, not just automated. On top of all this the repository has plenty of automated quality tests, the code comes with unit tests which are mandatory also for new features and has also automated coding style checks.



    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 does have unique versions numbering and we version also RCs when and if available.



    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]

    Developers and contributors push their PRs against Develop branch, not Main (Main is protected and requires a PR from Develop with approval). Devs and contributors PRs against Develop are tested automatically and reviewed by humans before code gets merged into Develop (same happens for code that gets merged from Develop to Main). Devs and Contributors are also required to install pre-commit which is configured to run a lot of tests (and run also all unit tests) at every got commit. When code has passed ALL automated tests and human reviews and merged in Main, then an RC tag is emitted for testing on 3rd party systems. an RC has a period of a month, to give time to user to test. If no issues are reported, then the Main gets released again with the final release number

    Checks in pre-commit here: https://github.com/pzaino/thecrowler/blob/main/.pre-commit-config.yaml Tags here: https://github.com/pzaino/thecrowler/tags

    Project is new, so not official releases has been emitted yet.


  • 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]

    Each release (and pre-release) have a fully detailed release note: https://github.com/pzaino/thecrowler/releases/tag/v0.9.3

    Full changelog example: https://github.com/pzaino/thecrowler/compare/v0.9.2...v0.9.3



    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]

    The release note will indeed include all publicly known run-time vulnerabilities when we'll start releasing production versions.


  • 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]

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

    We use GitHub Issues number to track each individual issue



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

    We aim to have ALL found issues public (we use GitHub for users to report them) and we acknowledge them all as soon as we are able to reproduce, so it could be even minutes.



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

    We do our best to respond to enhancement requests as fast as possible, but the project if fully free, so involved people also need to ensure they do their jobs first to then have time for the project.



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

    We use GitHub issues and Discussions, so everything is public. https://github.com/pzaino/thecrowler/issues?q=is%3Aissue+is%3Aclosed


  • Anfälligkeits-Prozessbericht


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

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

    Private vulnerability reports are supported and they can be submitted via email to the project author.



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

    We check the project GitHub and the emails every day. So, every vulnerability found and reported will be checked certainly within 14 working days.


  • 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]

    The project provides a working build system to rebuild the entire set of micro-services at once:

    https://github.com/pzaino/thecrowler/blob/main/docker-rebuild.sh



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

    The project uses Docker and Docker compose to create containerized builds of all the required components and it also offers build scripts that add platform detection so to help Docker to pull or build containers appropriately.

    https://github.com/pzaino/thecrowler/blob/main/docker-compose.yml

    https://github.com/pzaino/thecrowler/blob/main/docker-build.sh



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

    The project IS buildable using ONLY FLOSS tools, to build it one needs go lang only. Database is based on PostgreSQL and SQLite, components are packaged in Docker images at build time and using freely available tools. It works fine with Docker provided with Linux Distribution (aka doesn't requires to install docker from docker.io)


  • 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]

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

    A user can run go test to run unit tests locally on their system and at any time.



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

    The entire suite of tests covers everything. And we are also adding system tests to measure performance under stress.



    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]

    The project allows to do continuous integration. Contains can be built off-line and replace existing containers too.


  • 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]

    From the CONTRIBUTING.md file:

    "If you've added code that should be tested, add tests."

    link here: https://github.com/pzaino/thecrowler/blob/main/CONTRIBUTING.md



    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]

    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]

    It is:

    "If you've added code that should be tested, add tests. For more information on testing, see Test Policy for TheCROWler."

    From the CONTRIBUTING.MD file, link here: https://github.com/pzaino/thecrowler/blob/main/CONTRIBUTING.md


  • 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]

    Project is written in go (and gofmt) and pre-commit forbid a developer from even being able to push their code in a develop branch. tests are executed even when code compiles fine and we have all go lang warning.



    Das Projekt MUSS auf Warnungen reagieren. [warnings_fixed]

    As mentioned, we do address warnings.



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

    We use Go lang and gofmt as well as: - go-fmt - no-go-testing - golangci-lint - go-unit-tests

    https://github.com/pzaino/thecrowler/blob/main/.pre-commit-config.yaml


  • 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]

    We do have a primary developer with multiple courses and more than 30 years of experience in coding and secure coding.



    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]

    Our primary developer works in the Cyber Security field and has experience in developing and designing IDS, IPS, Firewalls and Anitvirus software and deals daily with vulnerabilities and CVEs, CWEs and CPEs


  • 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]


    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]

    Software uses standard HTTPS for the few cryptographic elements and for that uses the standard go lang libraries.



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


    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]


    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]


    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]


    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]


    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]


    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]

  • 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]


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

  • Ö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]

    We also use a vulnerability bot that automatically creates pull-requests with updated dependencies when one is found having a vulnerability.



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

  • 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]

    we check for private credentials from the developer local system using pre-commit and re-check on GitHub as well


  • 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]

    SonarQube (locally), CodeQL, Codacy on GitHub.com



    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]


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


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

    We also use SonarCube LINT in VSCode studio so security issues are detected as we write code (real time), we check again with sonar-scanner before commit and with CodeQL and Codacy at every commit on gitHub


  • 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]


    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]

    project is fully written in Go Lang, so no memory-unsafe code.



    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]


    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]

    Not only we do, we also generate our containers hardened and code is executed with low privilege accounts inside the containers. Where applicable containers have also read only filesystem enabled.



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 Paolo Fabio Zaino und die OpenSSF Best Practices Badge Mitwirkenden an.

Projekt-Badge-Eintrag im Besitz von: Paolo Fabio Zaino.
Eintrag erstellt: 2024-01-25 23:46:04 UTC, zuletzt aktualisiert: 2024-06-04 01:29:01 UTC. Letztes erreichtes Badge: 2024-06-04 01:29:01 UTC.

Zurück