SniffnetをGitHub Secure Open Source Fundで保護して学んだこと

私は常にセキュリティを最優先にSniffnetを構築してきました。そして今日、その哲学に忠実に沿った大きなマイルストーンを発表できることを嬉しく思います。Sniffnetは最近、GitHub Secure Open Source Fundに参加しました！Microsoft、Stripe、1Password、Shopifyといった業界の巨人が支援するこのプログラムは、重要なオープンソースソフトウェアのセキュリティと持続可能性の向上に特化した取り組みです。このブログ記事では、プログラムがSniffnetをどのようにしてより安全にしたのかを共有し、同様のことを行うためにあなたがたどることができる手順を説明します。結局のところ、この経験から得られる最も重要な教訓の1つは、セキュリティはコミュニティ全体の共同作業であるということです。各プロジェクトは、より大きなパズルの小さな断片であり、エコシステムの残りが安全でない限り、誰も完全に安全ではいられません。 GitHub Secure Open Source Fundプログラム プログラムの使命は、広く使用されており、現代のスタックにとって重要なオープンソースソフトウェアを保護することです。これは、各プロジェクトに1万ドルの資金、実践的なトレーニング、およびメンターシップを提供する3週間の集中的なスプリントで構成されており、メンテナーがセキュリティは「あれば良いもの」ではなく、基本的な要件であることを理解するのを助けます。このスプリントはGitHub Security Labによってキュレーションされ、セキュリティ専門家のチームによって提供されます。 Sniffnetと他の49のプロジェクトが、このプログラムの第4回セッションに昨年の4月に参加しました。選ばれた参加者は、潜在的な露出を避け、コードベースの保護に集中するために、今日の公式発表までこのニュースを共有しないように求められました。一番良かった点は？プログラムは学習と理論だけではありません。それは、成果主導型の目標と検証されたセキュリティ要件を満たすために取られるべき一連の実践的なステップとして設計されており、プロジェクトとそのユーザーに具体的な影響を与えます。 セキュリティを最優先事項として 導入で述べたように、私は常にSniffnetのセキュリティを気にかけてきました。このウェブサイトのホームページには、「最優先事項の1つは、データプライバシーとシステム整合性を保護することです」と記載されており、最近プロジェクトは独立したセキュリティ監査を受けました。そして…私のコンピュータサイエンス修士号の専門は何だと思いますか？もちろんサイバーセキュリティです！この分野にしばらく携わってきましたが、Secure Open Source Fundのような構造化されたセキュリティプログラムに触れたことは一度もありませんでした。そして、コードをより堅牢にするためにGitHubがネイティブに提供するツールの数に驚かされました。残念ながら、現実は、セキュリティが開発サイクルの終盤に延期されるか、さらに悪いことに、脆弱性が発見された後のパニックの瞬間にのみ考慮されることがあまりにも多いということです。したがって、セキュリティを単なる受動的な対抗策に格下げするのではなく、積極的に設計・計画するための考え方の転換が必要です。私が学んだ知識とベストプラクティスを共有することで、セキュリティ意識を増幅させる責任を感じています。これにより、他の開発者はインスピレーションを得て、自身のプロジェクトで同様の対策を適用できます。 インシデント対応計画と脅威モデリング 具体的な対策を心配する前に、最初のステップは明確なセキュリティ計画を定義することです。計画は主に2つの理由で重要です。 何か悪いことが起こったとき（遅かれ早かれ起こるでしょう）、堅牢な戦略が準備されていれば、プレッシャーの下でも冷静かつ効果的に行動できます。 侵害される前に、プロジェクトの最も重要な資産を概説することで、本当に重要なことに労力を集中させることができます。 ポイント1はインシデント対応計画（IRP）によって対処されます。これは、セキュリティインシデントが発生した場合に従うべき役割、責任、および順序付けられた一連のアクションを定義することです。目標は、インシデントの影響を封じ込め、通常の運用をできるだけ早く復旧するための手順を念頭に置くことです。詳細なIRPドキュメントについては、SniffnetのINCIDENT_RESPONSE.mdを参照してください。 ポイント2は、脅威モデリングの問題です。これは、システム内の特定の資産がさらされる可能性のある脅威をカタログ化するプロセスです。一般的な種類の脅威を特定するために、STRIDEフレームワークを使用しました。これは、脅威を6つのカテゴリに分類します：なりすまし、改ざん、否認、情報漏洩、サービス拒否、権限昇格。 真に網羅的な脅威モデルは、脅威×資産の巨大な二次元マトリックスを作成することになりますが、これは特に大規模なプロジェクトにとっては複雑で維持が困難なものです。このため、プロセスを無期限に延期するのではなく、発生可能性と悪用の影響度でランク付けされたシステム内の最も重要な資産を分析することから始め、徐々にカバレッジを拡大していくことが推奨されます。Sniffnetでこれがどのように機能したか興味がある場合は、最初のTHREAT_MODEL.mdをご覧ください。 上記で言及した2つのドキュメントは、脆弱性の報告方法とメンテナーがそれらをどのように処理するかを説明するセキュリティポリシーと組み合わせると、さらに効果的です。これにより、貢献者とユーザーは、実施されているセキュリティ対策を認識できます。Sniffnetのセキュリティポリシーは、当社のSECURITY.mdで確認できます。 実践的なセキュリティ対策とツール 明確なセキュリティ設計が整ったら、いよいよ実践に移ります。これはプログラムが真に輝く部分だと私は思います。なぜなら、それは実際の影響を与える一連の実行可能な対策を提供し、しかも比較的短時間で展開できるからです。それらのメリット対労力の比率を考えると、誰もがオープンソースの仕事のベースラインとしてそれらを採用すべきだと思います。Sniffnetはすでに最も関連性の高いものをカバーしていましたが、プログラムはいくつかのギャップを埋めるのに役立ちました。リストは長いですが、ここではGitHubが提供するセキュリティ強化ツールの表に限定し、その目的と対応する公式ドキュメントへのリンクを簡単に説明します。 対策 それは何であり、なぜ役立つのか シークレットスキャン リポジトリ内のAPIキーやトークンなどの漏洩した認証情報をスキャンし、見つかった場合に通知します。そのコンパニオンであるプッシュ保護は、リモートに到達する前にシークレットを含むコミットをブロックします。 コードスキャン CodeQLを使用して、ソースコードとGitHub Actionsワークフローのルールベースの静的分析を実行し、脆弱性とコードの臭いを見つけます。 リポジトリのルールセット 誰が、何を、どこにプッシュできるかを定義します。これらは、偶発的（または悪意のある）直接プッシュを防ぎ、タグを保護して、公開されたリリースが静かに書き換えられないようにします。 不変のリリース リリースをロックします。そのGitタグは同じコミットに固定され、そのアセットはもはや変更できません。これがないと、メンテナーアカウントを制御できる人は誰でも公開されたバイナリを改ざんできます。 プライベート脆弱性報告 セキュリティ研究者に、脆弱性を攻撃者に公開するのではなく、責任を持って脆弱性を開示するための機密チャネルを提供します。 Dependabotアラート 依存関係が既知の脆弱性の影響を受けている場合に通知し、それをパッチされたバージョンに引き上げるプルリクエストを自動的に開きます。 多要素認証 アカウントの乗っ取りを防ぐために、メンテナーに2番目の要素で本人確認を要求します。 きめ細かなアクセス トークン 各トークンには、厳密に必要な権限のみを付与します。最小権限アプローチを使用すると、侵害されたワークフローや漏洩したトークンの影響範囲を縮小できます。 予想どおり、これらの対策を実装することは、一般的なプロジェクトの健全性にとって良い出発点ですが、今日に至るまで、ターゲットを絞ったテストとファジングは、コードベース固有の欠陥を見つけるための最も効果的な方法であり続けています。今日、Sniffnetはかなりのユニットテストセットを備えていますが、コアのパケット解析ロジックとGUIレイヤーの両方に関する、より広範な統合テストをすでに計画しています。 まとめ では…セキュリティは永遠に解決されたのでしょうか？ この質問の答えはすでにわかっています。それは…*ドラムロール*…いいえ！セキュリティは人生のようなものです。あなたはそれに100パーセントを捧げ、すべてを正しく行うことができますが、それでも何かがうまくいかなくなる可能性があります。マーフィーの法則（「起こりうることはすべて起こる」）が支配する世界では、何が...