savvy-devsecops

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

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

        

 Grundlagen 0/5

  • Identifizierung

    Best Practices for GitHub Native DevSecOps Pipeline Implementing DevSecOps best practices for CI/CD (Continuous Integration/Continuous Delivery) in GitHub involves integrating security practices throughout the software development lifecycle. This ensures that security is not treated as an afterthought but is an integral part of the development process. Here's a description of GitHub native DevSecOps CI/CD best practices:

    1. Infrastructure as Code (IaC) Security: Utilize GitHub's infrastructure as code capabilities to enforce security measures in the deployment pipeline. Use tools like Terraform or GitHub Actions to ensure that infrastructure deployments are secure and adhere to best practices.

    2. Automated Security Testing: Integrate automated security testing into the CI/CD pipeline. Use tools like SonarQube, Snyk, or GitHub-native security tools to scan for vulnerabilities, malware, or code flaws as part of the build process.

    3. Code Analysis and Review: Encourage secure coding practices through code analysis and review. Leverage GitHub's code scanning and pull request review features to identify and fix security vulnerabilities early in the development process.

    4. Policy Enforcement with GitHub Actions: Enforce security policies using GitHub Actions to automate checks for compliance, code quality, and vulnerability scanning. Use pre-configured workflows to ensure that all code changes meet the organization's security standards.

    5. Container Security: Implement container scanning tools like Docker Security Scanning or GitHub container scanning to detect vulnerabilities within the container images before deployment. Make sure that only secure and approved container images are used in the CI/CD pipeline.

    6. Secret Management: Manage secrets securely by utilizing GitHub's native secret management solutions. Encourage the use of environment variables and GitHub Secrets to store sensitive information securely, reducing the risk of exposure during the CI/CD process.

    7. Access Control and Permissions: Enforce access control and permissions for repositories and CI/CD pipelines to ensure that only authorized personnel have access to sensitive information and critical deployment processes. Implement GitHub's access management features to define roles and permissions for different stakeholders.

    8. Incident Response and Monitoring: Implement monitoring and logging solutions within the CI/CD pipeline to track and analyze security incidents in real-time. Use tools like GitHub Security Advisories and Security Insights to stay informed about security vulnerabilities and take prompt action when necessary.

    9. Continuous Learning and Improvement: Foster a culture of continuous learning and improvement by regularly updating security measures, conducting security awareness training, and staying informed about the latest security threats and best practices. Encourage developers to stay updated with the latest security guidelines and tools.

    By following these GitHub native DevSecOps CI/CD best practices, organizations can build a robust and secure development pipeline, ensuring that security is integrated seamlessly throughout the software development lifecycle.

  • Voraussetzungen


    Das Projekt MUSS ein Silber-Siegel erreichen. [achieve_silver]

  • Projektüberwachung


    Das Projekt MUSS einen "Busfaktor" von 2 oder mehr haben. (URL erforderlich) [bus_factor]


    Das Projekt MUSS mindestens zwei unabhängige bedeutende Entwickler haben. (URL erforderlich) [contributors_unassociated]

  • Andere


    Das Projekt MUSS eine Lizenzerklärung in jeder Quelldatei enthalten. Dies DARF als Kommentar relativ am Anfangs jeder Datei einfügt sein: SPDX-License-Identifier: [SPDX license expression for project]. [license_per_file]

  • Öffentliches Versionskontroll-Source-Repository


    Das Source-Repository des Projekts MUSS eine geläufige, verteilte Versionskontrollsoftware (z. B. git oder mercurial) verwenden. [repo_distributed]

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



    Das Projekt MUSS eindeutig kleine Aufgaben identifizieren, die von neuen oder gelegentlichen Mitwirkenden durchgeführt werden können. (URL erforderlich) [small_tasks]


    Das Projekt MUSS eine Zwei-Faktor-Authentifizierung (2FA) für Entwickler haben, um ein zentrales Repository zu wechseln oder auf sensible Daten zugreifen zu können (z. B. private Schwachstellen-Berichte). Dieser 2FA-Mechanismus DARF Mechanismen ohne kryptographische Mechanismen wie SMS verwenden, obwohl dies nicht empfohlen wird. [require_2FA]


    Die Zwei-Faktor-Authentifizierung des Projekts (2FA) SOLLTE Kryptographie-Mechanismen verwenden, um Identitätswechsel zu verhindern. Short-Message-Service-/SMS-basierte 2FAs allein erfüllen dieses Kriterium nicht, da sie nicht verschlüsselt sind. [secure_2FA]

  • Programmierstil


    Das Projekt MUSS seine Code-Review-Anforderungen dokumentieren, einschließlich, wie Code-Überprüfung durchgeführt wird, was überprüft werden muss und was erforderlich ist, um akzeptabel zu sein. (URL erforderlich) [code_review_standards]


    Das Projekt MUSS mindestens 50% aller vorgeschlagenen Änderungen vor dem Release durch eine andere Person als den Autor überprüfen, um festzustellen, ob es sich um eine sinnvolle Änderung handelt und frei von bekannten Problemen ist, die gegen die Freigabe der Änderung sprechen würden [two_person_review]

  • Produktivsystem


    Das Projekt MUSS ein reproducible Build haben. Wenn kein Building erforderlich ist (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [build_reproducible]

  • Automatisierte Test-Suite


    Eine Test-Suite MUSS in einer standardisierten Weise für diese Programmiersprache anrufbar sein. (URL erforderlich) [test_invocation]

    Warnung: URL erforderlich, aber keine URL gefunden.



    Das Projekt MUSS eine kontinuierliche Integration implementieren, bei der neue oder geänderte Codes häufig in ein zentrales Code-Repository integriert werden und automatisierte Tests auf dem Ergebnis durchgeführt werden. (URL erforderlich) [test_continuous_integration]

    Warnung: URL erforderlich, aber keine URL gefunden.



    Das Projekt MUSS automatisierte FLOSS-Test-Suite(n) einsetzen, die mindestens 90% der Befehle abdecken, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Programmiersprache messen kann. [test_statement_coverage90]


    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) mit mindestens 80% Zweig-Abdeckung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache messen kann. [test_branch_coverage80]

  • 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 produzierte Software MUSS 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 MÜSSEN 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]


    Die Projektsoftware MUSS, wenn sie TLS unterstützt oder verwendet, mindestens TLS Version 1.2 unterstützen. 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]

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


    Die Projekt-Website, das Repository (wenn über das Internet zugänglich) und die heruntergelandenen Seiten (falls separat) MÜSSEN Key-Hardening-Headers mit nichtpermeablen Werten enthalten. (URL erforderlich) [hardened_site]

    Found all required security hardening headers.

    Warnung: URL erforderlich, aber keine URL gefunden.


  • Andere Sicherheitsissues


    Das Projekt MUSS innerhalb der letzten 5 Jahre eine Sicherheitsüberprüfung durchgeführt haben. Diese Überprüfung muss die Sicherheitsanforderungen und die Sicherheitsgrenze berücksichtigen. [security_review]


    Härtungsmechanismen müssen in der Projektsoftware verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. (URL erforderlich) [hardening]

  • Dynamische Codeanalyse


    Das Projekt MUSS mindestens ein dynamisches Analyse-Tool auf jeden kommenden Hauptproduktionsrelease der Software, die durch das Projekt vor seiner Freigabe produziert wird, anwenden. [dynamic_analysis]


    Das Projekt SOLLTE viele Laufzeit-Assertionen in der Projektsoftware enthalten und diese Assertionen während der dynamischen Analyse überprüfen. [dynamic_analysis_enable_assertions]


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

Projekt-Badge-Eintrag im Besitz von: Nishkarsh Raj.
Eintrag erstellt: 2023-10-16 11:06:43 UTC, zuletzt aktualisiert: 2023-10-17 06:20:21 UTC.

Zurück