savvy-devsecops

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください!バッジステータスは次のようになります。 プロジェクト 7960 のバッジ レベルは in_progress です バッジステータスの埋め込み方法は次のとおりです。

これらはゴールドレベルの基準です。合格またはシルバーレベル基準を表示することもできます。

        

 基本的情報 0/5

  • 識別情報

    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.

  • 前提要件


    プロジェクトは、シルバー レベル バッジを達成しなければなりません。 [achieve_silver]

  • プロジェクトの管理・運営


    プロジェクトは2以上の "バス ファクタ"を持つ必要があります。 (URLが必要です) [bus_factor]


    プロジェクトには少なくとも2人の関係を持たない重要な貢献者がいなければなりません。 (URLが必要です) [contributors_unassociated]

  • その他


    プロジェクトは、各ソースファイルにライセンスステートメントを含まなければなりません。これは、各ファイルの先頭近くに次のコメントを含めることによって行うことができます: SPDXライセンス識別子:[プロジェクトに対するSPDXライセンス表現] [license_per_file]

  • 公開されたバージョン管理ソースリポジトリ


    プロジェクトのソースリポジトリは、共通の分散バージョン管理ソフトウェア(gitやmercurialなど)を使用しなければなりません。 [repo_distributed]

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



    プロジェクトは、新規または偶に参加する貢献者によって実行できる小さなタスクを明確に識別しなければなりません。 (URLが必要です) [small_tasks]


    プロジェクトは、中央リポジトリを変更したり、機密データ(プライベート脆弱性レポートなど)にアクセスするために、開発者に対して二要素認証(2FA)を要求する必要があります。推奨されませんが、2FAメカニズムは、SMSのような暗号化メカニズムを持たないメカニズムを使用することができます。 [require_2FA]


    プロジェクトの2要素認証(2FA)は、偽装を防ぐために暗号化メカニズムを使用すべきです。ショート メッセージ サービス(SMS)ベースの2FA自体は、暗号化されていないため、この基準を満たしていません。 [secure_2FA]

  • コーディング標準


    プロジェクトは、コードレビューの実施方法、チェックする必要があるもの、受け入れられる必要があるものなど、コードレビュー要件を文書化しなければなりません。 (URLが必要です) [code_review_standards]


    プロジェクトは、公開する前に、提案されたすべての変更の少なくとも50%を著作者以外の人がレビューして、それが価値のある変更であり、取り込みに反対する既知の問題がないかどうかを判断しなければなりません。 [two_person_review]

  • 作業ビルドシステム


    プロジェクトが再現可能なビルドを持たなければなりません。ビルドが発生しない場合(たとえば、コンパイルされないでソースコードが直接使用されるスクリプト言語)、「該当なし」(N/A)を選択します。 (URLが必要です) [build_reproducible]

  • 自動テスト スイート


    テストスイートは、その言語の標準的な方法で呼び出すことができなければなりません。 (URLが必要です) [test_invocation]

    警告:URLが必要ですが、URLは見つかりません。



    プロジェクトは、新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動化されたテストが実行される、継続的な統合を実装しなければなりません。 (URLが必要です) [test_continuous_integration]

    警告:URLが必要ですが、URLは見つかりません。



    プロジェクトは、選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがある場合、少なくとも80%のステートメント カバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。 [test_statement_coverage90]


    選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがあれば、少なくとも80%のブランチカバレッジを提供するFLOSS自動テストスイートがプロジェクトに存在しなければなりません。 [test_branch_coverage80]

  • 優良な暗号手法を使用する

    一部のソフトウェアは暗号化メカニズムを使用する必要がないことに注意してください。あなたのプロジェクトが作成するソフトウェアが、(1) 暗号化機能を含む、アクティブ化する、または有効化し、(2) 米国(US)から米国外または米国市民以外にリリースされる可能性がある場合は、法的に義務付けられた追加手順の実行を要求される可能性があります。通常、これにはメールの送信が含まれます。詳細については、 Understanding Open Source Technology & US Export Controls「オープンソース技術と米国の輸出管理について」)の暗号化のセクションを参照してください。

    プロジェクトで作成されたソフトウェアは、ネットワーク通信すべてに対して、SSHv2以降、TLS1.2以降 (HTTPS)、IPsec、SFTP、SNMPv3などのセキュア プロトコルをサポートしなければなりません。FTP、HTTP、telnet、SSLv3以前、SSHv1などのセキュアでないプロトコルは、デフォルトで無効にしておき、ユーザーが特別に設定した亜場合のみ有効にしなければなりません。プロジェクトによって作成されたソフトウェアがネットワーク通信をサポートしない場合は、「該当なし」(N/A)を選択します。 [crypto_used_network]


    プロジェクトによって作成されたソフトウェアは、TLSをサポートあるいは使用する場合、少なくともTLSバージョン1.2をサポートしなければなりません。TLSの前身は、SSLと呼ばれていたことに注意して下さい。ソフトウェアがTLSを使用ない場合、「該当なし」(N/A)を選択します。 [crypto_tls12]

  • MITM(man-in-the-middle:中間者)攻撃に対応できる安全な配信


    プロジェクトウェブサイト、リポジトリ(ウェブからアクセス可能な場合)、およびダウンロードサイト(別々の場合)には、許容できない値を持つキー強化ヘッダーが含まれていなければなりません。 (URLが必要です) [hardened_site]

    Found all required security hardening headers.

    警告:URLが必要ですが、URLは見つかりません。


  • その他のセキュリティ上の課題


    プロジェクトは過去5年間にセキュリティレビューを実施していなければなりません。このレビューは、セキュリティ要件とセキュリティ境界を考慮しなければならりません。 [security_review]


    プロジェクトによって作成されたソフトウェアで強化メカニズムを使用しなければならないので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。 (URLが必要です) [hardening]

  • 動的コード分析


    プロジェクトは、リリース前にプロジェクトによって作成されたソフトウェアの主要な製品リリースに対して、少なくとも1つの動的解析ツールを適用しなければなりません。 [dynamic_analysis]


    プロジェクトは、生成するソフトウェアに多くの実行時アサーションを含めるべきであり、動的分析中にそれらのアサーションをチェックするべきです。 [dynamic_analysis_enable_assertions]


このデータは、Creative Commons Attribution version 3.0以降のライセンス(CC-BY-3.0 +)のもとで利用できます。すべての人がデータを自由に共有および適応できますが、適切にクレジットを入れる必要があります。 Nishkarsh RajとOpenSSFベストプラクティス バッジ貢献者のクレジットを入れてください。

プロジェクト バッジ登録の所有者: Nishkarsh Raj.
エントリの作成日時 2023-10-16 11:06:43 UTC、 最終更新日 2023-10-17 06:20:21 UTC

もどる