repository-scanner

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 7799 ist silver So können Sie ihn einbetten:

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

        

 Grundlagen 17/17 ●

  • Identifizierung

    The Repository Scanner (RESC) is a tool used to detect secrets in source code management and version control systems (e.g. GitHub, BitBucket, or Azure DevOps). Among the types of secrets that the Repository Scanner detects are credentials, passwords, tokens, API keys, and certificates. The tool is maintained and updated by the ABN AMRO Bank to match the constantly changing cyber security landscape.

    The Repository Scanner was created to prevent that credentials and other sensitive information are left unprotected in code repositories. Exposing sensitive information in such a way can have severe consequences for the security posture of an organization. An attacker can use the data to compromise the organization's network. This can be prevented by scanning a repository with the RESC tool. It marks all the instances of exposed sensitive information in the source code.

  • Voraussetzungen


    Genug für ein Badge!

    Das Projekt MUSS ein bestimmtes Level erreichen. [achieve_passing]

  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

    Die Informationen darüber, wie man mitwirken kann, MÜSSEN die Anforderungen für akzeptable Beiträge (z.B. einen Hinweis auf einen erforderlichen Codierungsstandard) enthalten. (URL erforderlich) [contribution_requirements]

    https://github.com/abnamro/repository-scanner/blob/main/contributing.md


  • Projektüberwachung


    Genug für ein Badge!

    Das Projekt SOLLTE einen rechtlichen Mechanismus haben, wo alle Entwickler von nicht-trivialen Beiträgen versichern, dass sie rechtlich ermächtigt sind, diese Beiträge zu machen. Der häufigste und leicht umsetzbare Ansatz, ist die Verwendung eines Developer Certificate of Origin (DCO) , wo Benutzer "signed-off-by" in ihren Commits und die Projektlinks zur DCO-Website hinzufügen. Allerdings DARF dies als Contributor License Agreement (CLA) oder als ein anderer rechtlicher Mechanismus implementiert werden. (URL erforderlich) [dco]

    All the RESC PRs required verified signature. https://github.com/abnamro/repository-scanner/pulls?q=


    Genug für ein Badge!

    Das Projekt MUSS eindeutig sein Projekt-Governance-Modell (die Art, wie es Entscheidungen fällt, einschließlich der wichtigsten Rollen) definieren und dokumentieren. (URL erforderlich) [governance]

    We use GitHub to track proposed changes via its issue tracker and pull requests. pull request: https://github.com/abnamro/repository-scanner/pulls issues: https://github.com/abnamro/repository-scanner/issues


    Genug für ein Badge!

    Das Projekt MUSS einen Code of Conduct etablieren und an einem üblichen Ort veröffentlichen. (URL erforderlich) [code_of_conduct]

    https://github.com/abnamro/repository-scanner/blob/main/code-of-conduct.md


    Genug für ein Badge!

    Das Projekt MUSS klar und deutlich die Rollen- auf Aufgabenverteilung dokumentieren, inklusive einzelnen Tätigkeiten, die von den Rollenträgern ausgeführt werden müssen. Es MUSS eindeutig sein wer welche Rolle hat, auch wenn es in anderer Form dokumentiert ist. (URL erforderlich) [roles_responsibilities]

    ABN AMRO is the owner of the project, who decides who will be working on the project. https://github.com/abnamro


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, mit minimaler Unterbrechung fortzufahren, wenn eine beliebige Person nicht in der Lage ist oder stirbt. Insbesondere MUSS das Projekt in der Lage sein, Probleme zu lösen, vorgeschlagene Änderungen zu akzeptieren und Versionen der Software freizugeben, innerhalb einer Woche nach der Bestätigung, dass eine Person nicht mehr in der Lage ist oder gestorben ist. Dies DARF sichergestellt werden, indem man jemandem anderes notwendige Schlüssel, Passwörter und gesetzliche Rechte gibt, um das Projekt fortzusetzen. Einzelpersonen, die ein FLOSS-Projekt ausführen, DÜRFEN dies durch die Bereitstellung von Schlüsseln in einer Lockbox und einer Willenserklärung zur Bereitstellung von erforderlichen gesetzlichen Rechten (z. B. für DNS-Namen). (URL erforderlich) [access_continuity]

    The project is maintained under ABN AMRO, ABN AMRO will take care of project. https://github.com/abnamro/repository-scanner/graphs/contributors


    Genug für ein Badge!

    Das Projekt SOLLTE einen Bus-Faktor von 2 oder mehr haben. (URL erforderlich) [bus_factor]

    The project is maintained under ABN AMRO, ABN will take care of project. https://github.com/abnamro/repository-scanner/graphs/contributors


  • Dokumentation


    Genug für ein Badge!

    Das Projekt MUSS eine dokumentierte Roadmap, für mindestens das nächste Jahr haben, die beschreibt, was das Projekt beabsichtigt zu tun und nicht zu tun. (URL erforderlich) [documentation_roadmap]

    https://github.com/abnamro/repository-scanner/blob/add-roadmap/docs/roadmap.md


    Genug für ein Badge!

    Das Projekt MUSS in der Dokumentation die Architektur (alias High-Level-Design) der vom Projekt entwickelten Software bereitstellen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [documentation_architecture]

    https://github.com/abnamro/repository-scanner/tree/main/images example: https://github.com/abnamro/repository-scanner/blob/main/images/RESC_HighLevel_Diagram.png


    Genug für ein Badge!

    Das Projekt MUSS dokumentieren, was der/die Benutzer/in in Bezug auf die Sicherheit der Projektsoftware (seine "Sicherheitsanforderungen") erwarten kann und nicht erwarten kann. (URL erforderlich) [documentation_security]

    Genug für ein Badge!

    Das Projekt MUSS eine "Quickstart"-Anleitung für neue Benutzer/innen haben, um ihnen zu helfen, schnell mit der Software umgehen zu können. (URL erforderlich) [documentation_quick_start]

    examples: https://github.com/abnamro/repository-scanner/blob/main/deployment/resc-helm-wizard/images/RESC_Installation.gif https://github.com/abnamro/repository-scanner/blob/main/images/RESC_Preview.gif


    Genug für ein Badge!

    Das Projekt MUSS sich bemühen, die Dokumentation mit der aktuellen Version der Projektergebnisse (einschließlich der vom Projekt produzierten Software) stehts zu aktualisieren. Jegliche bekannte Dokumentationsfehler, die es inkonsistent machen, MÜSSEN behoben werden. Wenn die Dokumentation in der Regel aktuell ist, aber fälschlicherweise einige ältere Informationen enthält, die nicht mehr wahr sind, behandeln Sie diese als Störung, dann verfolgen und beheben Sie diese wie üblich. [documentation_current]

    All the details are listed in the release versions https://github.com/abnamro/repository-scanner/releases


    Genug für ein Badge!

    Die Projekt-Repository-Titelseite und / oder Website MUSS alle Errungenschaften, die erreicht wurden, einschließlich dieses Best Practices Abzeichens, innerhalb von 48 Stunden nach der öffentlichen Anerkennung ausweisen und verlinken. (URL erforderlich) [documentation_achievements]

    https://github.com/abnamro/repository-scanner#readme example: https://www.bestpractices.dev/en/projects/7799 https://github.com/abnamro/repository-scanner/actions


  • Zugänglichkeit und Internationalisierung


    Genug für ein Badge!

    Das Projekt (beide Projektwebsite und Projektergebnisse) SOLLTE den bewährten Praktiken der Erreichbarkeit folgen, damit Personen mit Behinderungen noch an dem Projekt teilnehmen und die Projektergebnisse nutzen können, wo es vernünftig ist. [accessibility_best_practices]

    The product and the documentation are straight-forward text-based and don't require UI colors/changes.


    Genug für ein Badge!

    Die Projektsoftware SOLLTE internationalisiert werden, um eine einfachen Zugang für die Kultur, Region oder Sprache der Zielgruppe zu ermöglichen. Wenn die Internationalisierung (i18n) nicht andzuwenden ist (z. B. die Software keine für Endbenutzer beabsichtigte Texte erzeugt und keinen menschlich lesbaren Text sortiert), wählen Sie "nicht anwendbar" (N/A). [internationalization]

    N/A its designed for english language.


  • Andere


    Genug für ein Badge!

    Wenn die Projektseiten (Website, Repository und Download-URLs) Passwörter für die Authentifizierung von externen Benutzern speichern, 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). Wenn die Projektseiten hierfür keine Passwörter speichern, wählen Sie "nicht anwendbar" (N/A) aus. [sites_password_security]

    We are not using any cryptographic mechanism, because we dont have functionality to store any sensitive data


  • Vorherige Versionen


    Genug für ein Badge!

    Das Projekt MUSS die am häufigsten verwendeten älteren Versionen des Produkts beibehalten oder einen Upgrade-Pfad zu neueren Versionen bieten. Wenn der Upgrade-Pfad schwierig durchzuführen ist, muss das Projekt dokumentieren, wie das Upgrade durchgeführt werden kann (z. B. die Interfaces, die sich geändert haben, detaillierte Anleitung für die Aktualisierung des Upgrades). [maintenance_or_update]

    https://github.com/abnamro/repository-scanner/releases


  • Bug-Report-Prozess


    Genug für ein Badge!

    Das Projekt MUSS ein Issue-Tracking-System zur Verwaltung einzelner Issues verwenden. [report_tracker]

    https://github.com/abnamro/repository-scanner/issues?q=


  • Anfälligkeits-Prozessbericht


    Genug für ein Badge!

    Das Projekt MUSS die Reporter/in von allen in den letzten 12 Monaten bekanntgegebenen Schwachstellenberichte aufführen, mit Ausnahme der Reporter, die Anonymität erbeten. Wurde in den letzten 12 Monaten keine Schwachstelle festgestellt, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [vulnerability_report_credit]

    Till now no one has reported any vulnerabilities. https://github.com/abnamro/repository-scanner/security/policy


    Genug für ein Badge!

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

    We have the security bug reporting policiy/guidelines https://github.com/abnamro/repository-scanner/security/policy


  • Programmierstil


    Genug für ein Badge!

    Das Projekt MUSS die spezifischen Codierungsstilrichtlinien für die primären Programmierprachen, die es verwendet, einhalten, und erfordern, dass die Beiträge die Bedingungen generell erfüllen. (URL erforderlich) [coding_standards]

    PEP 8 styling guide is used for Python by using Pylint and Flake8. Pipeline code url: https://github.com/abnamro/repository-scanner/blob/main/.github/workflows/backend-ci.yaml#L65 https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/tox.ini#L9 Prettier is used to format and styling Vuejs code. Example - https://github.com/abnamro/repository-scanner/blob/main/components/resc-frontend/.prettierrc.json


    Genug für ein Badge!

    Das Projekt MUSS automatisch dafür sorgen, dass die ausgewählten Stilrichtlinien eingehalten werden, wenn mindestens ein FLOSS-Tool vorhanden ist, welches das in der gewählten Programmiersprache tun kann. [coding_standards_enforced]

    ESLint for VueJS - https://github.com/abnamro/repository-scanner/blob/main/components/resc-frontend/.eslintrc.js Prettier for VueJS - https://github.com/abnamro/repository-scanner/blob/main/components/resc-frontend/.prettierrc.json Pylnt for Python - https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/.pylintrc Sorting using isort - https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/.isort.cfg Datree for Kubernetes misconfigurations - https://github.com/abnamro/repository-scanner/blob/main/deployment/kubernetes/datree-policies.yaml


  • Produktivsystem


    Genug für ein Badge!

    Build-Systeme für native Binärdateien MÜSSEN die relevanten Compiler- und Linker- (Umgebungs-) Variablen, die an sie übergeben werden (z.B. CC, CFLAGS, CXX, CXXFLAGS und LDFLAGS), respektieren und an Compiler- und Linker-Aufrufe weiterleiten. Ein Build-System DARF sie mit zusätzlichen Flags erweitern; Es DARF NICHT einfach die mitgelieferten Werte ersetzen. Wenn keine nativen Binärdateien erzeugt werden, wählen Sie "nicht anwendbar" (N/A). [build_standard_variables]

    N/A native binaries are not generated.


    Genug für ein Badge!

    Das Build- und Installationssystem SOLLTE Debugging-Informationen beibehalten, wenn sie in den entsprechenden Flags angefordert werden (z. B. "install -s" wird nicht verwendet). Wenn kein Build- oder Installationssystem vorhanden ist (z. B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). [build_preserve_debug]

    Present if debug mode is enabled.


    Genug für ein Badge!

    Das Build-System für die Software, die durch das Projekt erzeugt wird, DARF NICHT rekursive Unterverzeichnisse aufbauen, wenn es Querverweise in den Unterverzeichnissen gibt. Wenn kein Build- oder Installationssystem vorhanden ist (z.B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). [build_non_recursive]

    N/A Python and Vue.js is used


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, den Prozess der Generierung von Informationen aus Quelldateien zu wiederholen und genau das gleiche Bit-für-Bit-Ergebnis zu erhalten. Wenn kein Build auftritt (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N / A). [build_repeatable]

    N/A Python and Vue.js is used


  • Installationssystem


    Genug für ein Badge!

    Das Projekt MUSS eine Möglichkeit zur einfachen Installation und Deinstallation der Software haben, unter Benutzung einer häufig verwendeten Methode. [installation_common]

    Installation instructions - https://github.com/abnamro/repository-scanner/tree/main/deployment/resc-helm-wizard


    Genug für ein Badge!

    Das Installationssystem für den/die Endbenutzer/in MUSS Standardkonventionen zur Auswahl des Zielortes, in dem gebildete Artefakte zur Installationszeit geschrieben werden, folgen. Zum Beispiel, wenn es Dateien auf einem POSIX-System installiert, muss es die DESTDIR-Umgebungsvariable verwenden. Wenn es kein Installationssystem oder keine Standardkonvention gibt, wählen Sie "nicht anwendbar" (N/A). [installation_standard_variables]

    User is asked to choose storage location while deploying RESC. Example - https://github.com/abnamro/repository-scanner/blob/main/deployment/resc-helm-wizard/src/resc_helm_wizard/questions.py#L39


    Genug für ein Badge!

    Das Projekt MUSS einen Weg für potenzielle Entwickler bereithalten, um schnell alle erforderlich Projektergebnisse und Support-Umgebungen zu installieren, um Änderungen vornehmen zu können, einschließlich der Tests und Test-Umgebung. Dies MUSS mit einer gängigen Methode durchgeführt werden können. [installation_development_quick]

    Instructions to run unit testing, sorting and linting for Python code is done by tox command. Example - https://github.com/abnamro/repository-scanner/tree/main/components/resc-backend#run-unit-tests-linting-and-import-checks-locally

    VueJS - npm run ut and npm run lint commands used. https://github.com/abnamro/repository-scanner/blob/main/components/resc-frontend/README.md#testing


  • Externe gepflegte Komponenten


    Genug für ein Badge!

    Das Projekt MUSS externe Abhängigkeiten in computerlesbarer Form auflisten. (URL erforderlich) [external_dependencies]

    resc-backend: https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/requirements.txt resc-vcs-scraper: https://github.com/abnamro/repository-scanner/blob/main/components/resc-vcs-scraper/requirements.txt resc-vcs-scanner: https://github.com/abnamro/repository-scanner/blob/main/components/resc-vcs-scanner/requirements.txt resc-frontend: https://github.com/abnamro/repository-scanner/blob/main/components/resc-frontend/package.json resc-helm-wizard: https://github.com/abnamro/repository-scanner/blob/main/deployment/resc-helm-wizard/setup.cfg#L15


    Genug für ein Badge!

    Projekte MÜSSEN ihre externen Abhängigkeiten (einschließlich Bequemlichkeitskopien) überwachen oder regelmäßig überprüfen, um bekannte Schwachstellen zu erkennen und ausnutzbare Schwachstellen zu beheben oder sie als unausweichlich zu verifizieren. [dependency_monitoring]

    We monitor or periodically check the vulnerabilities in external dependencies using Dependabot. https://github.com/abnamro/repository-scanner/security/dependabot

    Also AuditJS is integrated in Frontend pipeline to monitor javascript dependencies. Pipeline code - https://github.com/abnamro/repository-scanner/blob/main/.github/workflows/frontend-ci.yaml#L66 Pipeline job - https://github.com/abnamro/repository-scanner/actions/runs/6107034933/job/16573242269


    Genug für ein Badge!

    Das Projekt MUSS entweder:
    1. Es einfach machen, wiederverwendbare extern gepflegte Komponenten zu identifizieren und zu aktualisieren;oder
    2. Die Standardkomponenten des Systems oder der Programmiersprache verwenden.
    Dann, wenn eine Schwachstelle in einer wiederverwendeten Komponente gefunden wird, wird es einfach sein diese Komponente zu aktualisieren. [updateable_reused_components]

    External dependencies are maintained in requirements.txt for python components and package.json for vuejs. So its easy to identify and update these external dependencies.

    resc-backend: https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/requirements.txt resc-vcs-scraper: https://github.com/abnamro/repository-scanner/blob/main/components/resc-vcs-scraper/requirements.txt resc-vcs-scanner: https://github.com/abnamro/repository-scanner/blob/main/components/resc-vcs-scanner/requirements.txt resc-frontend: https://github.com/abnamro/repository-scanner/blob/main/components/resc-frontend/package.json resc-helm-wizard: https://github.com/abnamro/repository-scanner/blob/main/deployment/resc-helm-wizard/setup.cfg#L15


    Genug für ein Badge!

    Das Projekt SOLLTE vermeiden veraltete oder obsolete Funktionen und APIs zu verwenden, für die FLOSS-Alternativen in der eingesetzten Technologie verfügbar sind (ihr "Technologie-Stack") und eine Supermajorität der Benutzer, die das Projekt unterstützt (so dass die Benutzer den Zugriff auf die Alternative haben ). [interfaces_current]

    We are not using any deprecated or obsolete functions and APIs. Recently we upgraded all dependencies to latest versions.

    https://github.com/abnamro/repository-scanner/pull/171 https://github.com/abnamro/repository-scanner/pull/158


  • Automatisierte Test-Suite


    Genug für ein Badge!

    Eine automatisierte Test-Suite MUSS bei jedem Check-In auf ein gemeinsames Repository für mindestens einen Zweig angewendet werden. Diese Test-Suite muss einen Bericht über Erfolg oder Misserfolg des Testes produzieren. [automated_integration_testing]

    Pytest is used in pipeline for unit testing of Python components: https://github.com/abnamro/repository-scanner/blob/main/.github/workflows/backend-ci.yaml#L52 Newman is used in pipeline for API testing of rest APIs: https://github.com/abnamro/repository-scanner/blob/main/.github/workflows/backend-ci.yaml#L154 Npm is used in pipeline for unit testing of Vuejs code: https://github.com/abnamro/repository-scanner/blob/main/.github/workflows/frontend-ci.yaml#L58


    Genug für ein Badge!

    Das Projekt MUSS Regressionstests zu einer automatisierten Test-Suite hinzufügen für mindestens 50% der, in den letzten sechs Monaten, gefixten Bugs. [regression_tests_added50]

    We have unit test for each of the bug fix.


    Genug für ein Badge!

    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) haben, die mindestens 80% Aussage Berichterstattung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache erfüllen kann. [test_statement_coverage80]

    We have few components which has 80% coverage, for the rest we are working on it. examples: resc-vcs-scraper: 82% https://github.com/abnamro/repository-scanner/actions/runs/6142241241/job/16663703821 resc-helm-wizard : 83% https://github.com/abnamro/repository-scanner/actions/runs/5666634632/job/15353775346 frontend - 86.56% https://github.com/abnamro/repository-scanner/actions/runs/6107034933/job/16573242269


  • Neue Funktionalitätsüberprüfung


    Genug für ein Badge!

    Das Projekt MUSS eine formale schriftliche Richtlinie dazu haben, wie wichtige neue Funktionalität hinzugefügt werden. Tests für die neue Funktionalität MÜSSEN zu einer automatisierten Test-Suite hinzugefügt werden. [test_policy_mandated]

    For each new/updated API endpoint we create Newman test and unit tests


    Genug für ein Badge!

    Das Projekt MUSS in seinen dokumentierten Anweisungen für Änderungsvorschläge die Richtlinien enthalten, die Tests für große neue Funktionalität hinzugefügt werden sollen. [tests_documented_added]

    https://github.com/abnamro/repository-scanner/releases


  • Warnhinweise


    Genug für ein Badge!

    Projekte MÜSSEN praktischerweise sehr streng mit Warnungen in der Projektsoftware sein. [warnings_strict]

    All linter are ran in CI for early detection for any warnings/errors


  • Wissen über sichere Entwicklungspraktiken


    Genug für ein Badge!

    Das Projekt MUSS sichere Designprinzipien (von "know_secure_design"), soweit anwendbar, umsetzen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). [implement_secure_design]

    In kubernetes deployments files we are using secure by default configuartion by adding the securityContext. Example: https://github.com/abnamro/repository-scanner/blob/main/deployment/kubernetes/charts/resc-database/templates/database_deployment.yaml#L52C11-L64C35

    Authenticated communication made while connecting with celery queues. Example: https://github.com/abnamro/repository-scanner/blob/main/components/resc-vcs-scanner/src/vcs_scanner/secret_scanners/celery_worker.py#L33

    We have secuerity headers in place for API response: In API: https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/src/resc_backend/resc_web_service/dependencies.py#L122 https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/src/resc_backend/constants.py#L96

    Deployment is made secure by using passwords for different components and passwords needs be provided by user during set up process using resc-helm-wizard cli. Example: https://github.com/abnamro/repository-scanner/tree/main/deployment/resc-helm-wizard


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

    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der Projektsoftware DÜRFEN NICHT von kryptographischen Algorithmen oder Modi mit bekannten schweren Mängeln abhängen (z.B. der SHA-1-Kryptographie-Hash-Algorithmus oder der CBC-Modus in SSH). [crypto_weaknesses]

    Yes, We are not using any cryptographic mechanism, because we dont have functionality to encrypt any data


    Genug für ein Badge!

    Das Projekt SOLLTE mehrere kryptographische Algorithmen unterstützen, so dass Benutzer schnell wechseln können, wenn eines defekt ist. Verbreitete symmetrische Schlüsselalgorithmen umfassen AES, Twofish und Serpent. Verbreitete kryptographische Hash-Algorithmus-Alternativen umfassen SHA-2 (einschließlich SHA-224, SHA-256, SHA-384 UND SHA-512) und SHA-3. [crypto_algorithm_agility]

    Yes, We are not using any cryptographic mechanism, because we dont have functionality to encrypt any data


    Genug für ein Badge!

    Das Projekt MUSS die Speicherung von Anmeldeinformationen (z.B. Passwörter und dynamische Token) und private kryptografische Schlüssel in Dateien, die von anderen Informationen getrennt sind (z.B. Konfigurationsdateien, Datenbanken und Protokolle), unterstützen und den Benutzern erlauben, sie ohne Code-Neukompilierung zu aktualisieren und zu ersetzen . Wenn das Projekt keine Anmeldeinformationen und private kryptographische Schlüssel verarbeitet, wählen Sie "nicht anwendbar" (N/A). [crypto_credential_agility]

    N/A. We are not using any cryptographic mechanism, because we dont have functionality to encrypt/store any sensitive data


    Genug für ein Badge!

    Die vom Projekt produzierte Software SOLLTE sichere Protokolle für alle Netzwerkkommunikationen unterstützen , wie SSHv2 oder höher, TLS1.2 oder höher (HTTPS), IPsec, SFTP und SNMPv3. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder früher, und SSHv1 SOLLTEN standardmäßig deaktiviert werden und nur aktiviert werden, wenn der/die Benutzer/in es speziell konfiguriert. Wenn die vom Projekt produzierte Software keine Netzwerkkommunikation verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_used_network]

    N/A


    Genug für ein Badge!

    Wenn die Software, die durch das Projekt produziert wird, TLS unterstützt oder verwendet, SOLLTE sie mindestens TLS Version 1.2 verwenden. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_tls12]

    N/A


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, muss, wenn es TLS unterstützt, die TLS-Zertifikatsüberprüfung standardmäßig bei der Verwendung von TLS, einschließlich auf Subresources, durchführen. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_certificate_verification]

    N/A


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, MUSS, wenn sie TLS unterstützt, eine Zertifikatsüberprüfung durchführen, bevor HTTP-Header mit privaten Informationen (wie z.B. sichere Cookies) versendet werden. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_verification_private]

    N/A


  • Sicheres Release


    Genug für ein Badge!

    Das Projekt MUSS kryptographisch unterschriebene Releases der Projektergebnisse aufzeichnen, die für weit verbreitete Verwendung gedacht sind, und es MUSS ein dokumentierter Prozess sein, der den Benutzern/innen erklärt, wie sie die öffentlichen Signaturschlüssel erhalten und die Signatur(en) überprüfen können. Der private Schlüssel für diese Signatur(en) MUSS NICHT auf der Seite(n) verwendet werden, die öffentlich zugänglich sind. Wenn Releases nicht für eine weit verbreitete Verwendung bestimmt sind, wählen Sie "nicht anwendbar" (N/A). [signed_releases]

    N/A. We are not using any cryptographic mechanism, because we dont have functionality to encrypt/store any sensitive data


    Genug für ein Badge!

    Es wird empfohlen, dass in dem Versionskontrollsystem jeder wichtige Versions-Tag (ein Tag, der Teil eines Hauptrelease, eines kleineren Release, oder eines Fixes, öffentlich gemeldeten Schwachstellen, ist) kryptographisch signiert und verifizierbar ist, wie in Signed_releases. [version_tags_signed]

    Every release/commit is signed and verified. https://github.com/abnamro/repository-scanner/releases


  • Andere Sicherheitsissues


    Genug für ein Badge!

    Die Projektergebnisse MÜSSEN alle Eingaben aus potenziell nicht vertrauenswürdigen Quellen überprüfen, um sicherzustellen, dass sie gültig sind (eine *Allowliste*) und ungültige Eingaben ablehnen, wenn überhaupt Einschränkungen für die Daten vorliegen. [input_validation]

    We are using Pydantic as data validation library for Python components in all our schemas. Example: https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/src/resc_backend/resc_web_service/schema/detailed_finding.py

    For all of our rest apis, we are using validation for query parameters provided by Fast API. Example: https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/src/resc_backend/resc_web_service/endpoints/rule_packs.py#L132

    Also we have custom validation in place. Example: https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/src/resc_backend/resc_web_service/helpers/rule.py#L330

    Also we have proper exception handling in place to return error codes instead of any detailed error or stacktrace. Example: https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/src/resc_backend/resc_web_service/helpers/exception_handler.py


    Genug für ein Badge!

    Härtungsmechanismen SOLLTEN in der Software, die das Project entwickelt, verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. [hardening]

    We have secuerity headers in place for API response: In API: https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/src/resc_backend/resc_web_service/dependencies.py#L122 https://github.com/abnamro/repository-scanner/blob/main/components/resc-backend/src/resc_backend/constants.py#L96

    In nginx ingress: https://github.com/abnamro/repository-scanner/blob/main/deployment/kubernetes/charts/resc-frontend/templates/frontend_ingress.yaml#L21

    We have also added few security headers to the project, to avoid security vulnerabilities https://github.com/abnamro/repository-scanner/blob/4e74a188a8cdb99027fbba67b288fe9c655c3e33/components/resc-backend/src/resc_backend/resc_web_service/dependencies.py#L109


    Genug für ein Badge!

    Das Projekt MUSS einen "Assurance Case" bereithalten, der rechtfertigt, wie die Sicherheitsanforderungen erfüllt werden. Der Assurance Case muss Folgendes beinhalten: eine Beschreibung des Bedrohungsmodells, eine eindeutige Identifizierung von Vertrauensgrenzen, eine Beschreibung wie sichere Designprinzipien angewendet wurden, und eine Beschreibung wie die üblichen Implementierungssicherheitsschwächen beseitige wurden. (URL erforderlich) [assurance_case]

    We, as part of a secure coding team of 6 developers working for Bank security, will prioritise security requirements from the start of the project, we work on shift left security, we have a threat model in place in our internal space. https://github.com/abnamro/repository-scanner/blob/main/docs/threatmodel.md Also, please see the photos below for the whole architecture model with security. https://github.com/abnamro/repository-scanner/tree/main/images



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 Repository-Scanner und die OpenSSF Best Practices Badge Mitwirkenden an.

Projekt-Badge-Eintrag im Besitz von: Repository-Scanner.
Eintrag erstellt: 2023-09-04 14:01:53 UTC, zuletzt aktualisiert: 2023-09-29 13:59:59 UTC. Letztes erreichtes Badge: 2023-09-05 10:32:15 UTC.

Zurück