より安全なソフトウェア開発のための簡潔なガイド
（このページは Concise Guide for Developing More Secure Software の参考訳です。）
by the Open Source Security Foundation (OpenSSF) Best Practices Working Group, 2023-06-14
ここでは、すべてのソフトウェア開発者のために、安全なソフトウェア開発、構築、配布のための簡潔なガイドを示します。記載されているすべてのツールやサービスは、単なる例に過ぎません。
- すべての特権開発者が多要素認証 (MFA) トークンを使用することを確認する。これにはコミットやそれらを受け付ける権限を持つものが該当します。MFAにより、攻撃者がこれらのアカウントを「乗っ取る」ことを防ぐことができます。
- 安全なソフトウェア開発について学ぶ。例えば、無料のOpenSSFコースや実践的な Security Knowledge Frameworkコースを受講してください。SAFECodeのセキュアなソフトウェア開発のための基本的な実践が参考になります。
- 脆弱性を検出するために、CIパイプラインで複数のツールを組み合わせて使用します。セキュリティツールについてはOpenSSFセキュリティ ツール ガイドを参照してください。ツールは唯一の方法ではなく、拡張可能なものとなります。
- 直接の依存関係としてソフトウェアの選択を行う前に、評価を行います。ソフトウェアの追加は必要な場合のみ追加し、評価し（オープンソースソフトウェアを評価するための簡潔なガイドを参照）、名前をダブルチェックし（攻撃者が予め想定するタイポを前提とした攻撃に対抗するため）、正しいリポジトリから取得されていることを確認します。
- パッケージマネージャを使う。パッケージマネージャ（システム、言語レベル、コンテナレベル）を使って、依存関係を自動的に管理し、迅速なアップデートを可能にします。
- 自動テストを実装する。ネガティブテスト（起きてはならないことが起きないというテスト）を含め、テスト全体が「テストに合格したら出荷する」のに十分徹底していることを確認します。
- ソフトウェアの直接および間接的な依存関係における既知の脆弱性を監視します。例えば、GitHubのDependabotやGitLabのDependency Scanningを使って基本的なスキャンを有効にしてください。その他多くのサードパーティ製ソフトウェア構成分析（SCA）ツールも利用可能です。脆弱性のある依存関係を迅速に更新します。
- 依存関係を適度に最新に保つこと。そうしないと、脆弱性のためのアップデートが難しくなります。
- シークレットをリポジトリにプッシュしないでください。リポジトリへのシークレットのプッシュを検出するツールを使用してください。
- 変更を受け入れる前にレビューする。例えば、GitHubやGitLabの保護されたブランチなどを利用し、レビューを強制してください。
- 脆弱性の報告およびそれに対する準備についての方法を明文化する。
- 連携した脆弱性開示のためのガイドのようなリソースを利用する。
- ベンダー依存関係に影響するセキュリティ問題を明示的に開示する。
- セキュリティポリシーを作成する。連絡先を提供する。
- 連携した脆弱性開示のためのガイドのようなリソースを利用する。
- ユーザーが簡単に更新できるようにする。安定したAPIを実装する。例えば、新しい名前が追加されたときに古い名前をサポートし、セマンティック バージョニングを行い、廃止手順を定義します。
- プロジェクトの重要なリリースに署名を付与します。あなたが提供するディストリビューションに対し、標準的なツールや署名フォーマットを使用してください。コンテナやその他の生成物に対して署名するためにSigstore projectのcosign toolを参照してください。
- あなたのオープンソースプロジェクトでOpenSSFベストプラクティス バッジを獲得します。少なくとも「合格」を獲得してください。最終的にシルバーやゴールドを獲得するための計画やロードマップを作成してください。
- （OSSでGitHub上にある場合）あなたのOpenSSFスコアカードのスコアを向上させます。スコアカードのチェックを読むことができます。Allstarのモニターを利用してください。
- プロジェクトの脆弱性をコミュニティに通知する。セキュリティ アドバイザリを公表してください。正確で詳細な情報、例えば、どのような使用法やバージョンに脆弱性があるか、緩和策、修正されたバージョンなどを含みます。またCVE IDを取得してください。GitHubでは、セキュリティ勧告の作成、CVEのリクエストが参照できます。
- ソフトウェア成果物のサプライチェーン レベル（SLSA）のレベルを向上させます。これにより、攻撃に対するソフトウェアのビルドと配布プロセスの保全性が強化されます。
- ソフトウェア部品表(SBOM)を発行し、利用する。これにより、ユーザーはインベントリを確認し、既知の脆弱性や潜在的な法的問題を特定できます。SPDXまたは CycloneDXを参考にしてください。
- Linux Foundationのプロジェクトを管理している場合は、LFXSecurityをプロジェクトに組み込んでください。
- CNCFのセキュリティTAGソフトウェア サプライチェーン ベストプラクティス ガイドを適用する。
- ASVSを実施し、関連するチートシートに従う。
- SAFECodeのセキュアなソフトウェア開発のための基本的プラクティスを適用する。
- 第三者のセキュリティ コード レビュー監査を完了する。5万米ドル以上を想定しておく。
- 継続的に改善する。スコアを向上させ、ヒントを探し、適切に適用する。
- 継続できるよう管理する。明確なガバナンスを持ち、活動的で信頼できるメンテナーを増やす努力をする。
- メモリ セーフな言語を選ぶ。多くの脆弱性はメモリの安全性に関係しています。実践的な用途では、メモリ セーフのプログラミング言語を使い（ほとんどの言語が該当します）、メモリ セーフを有効にしておくこと。そうでない場合は、リスクを減らすために追加のツールやピアレビューのような仕組みを利用してください。
提案やアップデートを歓迎します！issueを開くか、プルリクエストを投稿してください。
翻訳協力：松本央
このサイトはオープンソースです。このページを改善する
