OpenSSFが各セキュリティ分野の教育のための包括的なリソースをまとめた一連のガイド集「OpenSSFガイド」日本語版を公開

こんにちは、吉田です。今回は「Open Source Summit Japan 2023」開催に合わせてOpen Source Security Foundation (OpenSSF)が公開した、各セキュリティ分野の教育のための包括的なリソースをまとめた一連のガイド集「OpenSSFガイド」日本語版の中から、興味深いガイドラインを紹介します。

【参照】OpenSSFガイド日本語版を公開
https://www.linuxfoundation.jp/blog/2023/11/japanese-version-of-openssf-guide/

公開されたガイドラインは、下記のとおりです。

1. ソースコード管理プラットフォーム設定のベストプラクティス
2. より安全なソフトウェア開発のための簡潔なガイド
3. オープンソース ソフトウェアを評価するための簡潔なガイド
4. セキュリティ研究者のためのオープンソース ソフトウェア プロジェクトと脆弱性の公表を調整するためのガイダンス
5. npmベストプラクティス ガイド
6. オープンソース プロジェクト向けに協調的脆弱性開示プロセスを実装するためのガイド

この中から、まず「オープンソース ソフトウェアを評価するための簡潔なガイド」を紹介します。ソフトウェア開発者として、オープンソースソフトウェア(OSS)の依存関係やツールを使用する前に候補を特定し、ニーズに照らして主要なものを評価することになりますが、その際に評価するために必要な項目について説明しています。

1. その追加を避けることができるか?
追加する代わりに既存の(間接的かもしれない)依存関係を使えないか? を検討します。新しい依存関係が増えるたびに、攻撃対象が増える(新しい依存関係やその推移的依存関係の破壊がシステムを破壊するかもしれない)ことになります。

2. 意図したバージョンを評価しているか?
派生したバージョンではなく、オリジナルの意図したバージョンを評価していることを確認します。よく入力ミス等によるTyposquatting攻撃を受けることもあるので注意しなければいけません。そのためには、名前とプロジェクトのウェブサイトをチェックし、URLを確認する必要があります。

3. メンテナンスされているか?
メンテナンスされていないソフトウェアは、重大なリスクとなる可能性があります。まず、最近1年以内にコミットなどの重要な活動が行われていることや直近のリリースが1年以内であること、組織の異なる複数のメンテナーが存在することなど、健全なコミュニティ活動がなされていることを確認する必要があります。

4. 開発者が安全性を高める努力をしているという証拠はあるか?
プロジェクトがOpenSSFの「ベストプラクティスバッジ」を獲得しているか(または、獲得に向けて順調に進んでいるか)を確認することから始めてみるのも良いでしょう。ベストプラクティスバッジとは、OSSプロジェクトがOpenSSFの規定するベストプラクティスに従っていることを自ら示す方法で、Webアプリケーションを使用して自己証明ができます。詳細なバッジの合格基準はWebサイトで公開されています。
また、Googleが提供するOpen Source Insightsを調査し、パッケージの構造、構築、セキュリティをより深く理解することも必要です。また、OpenSSFが開発したOSSのGitHubリポジトリをセキュリティ的にチェックするOpenSSF Scorecardのスコアや、既知の脆弱性などの情報を調べることも重要です。テスト結果や検証結果をエビデンスとしてそれらを根拠にシステムの安全性、信頼性を議論し、システム認証者や利用者などに保証する、あるいは確信させるためのドキュメントであるアシュアランスケース(assurance case)を活用することも判断材料になります。
そのプロジェクトがセキュリティバグをタイムリーに修正していることやLTS (Long Time Support)バージョンがあるかを確認する必要もあります。

5. 安全に利用できるか?
デフォルトのコンフィギュレーションや「簡単な例」の中にネットワークプロトコルの暗号化がデフォルトでオンになっているなどを確認し、そうでなければ利用を避けるべきです。また、インターフェイス/APIは安全に使いやすいように設計されているかを確認することも重要です。

6. 脆弱性を報告する方法についての指示はあるか?
これについては、オープンソース プロジェクト向けに協調的脆弱性開示プロセスを実装するためのガイドに詳しく記述されているので、そちら参照してください。

7. 重要度の高いシステムでの利用があるか?
広く使われているソフトウェアほど、安全に使うための有用な情報を提供している可能性が高く、そソフトウェアのセキュリティに関心を持つ人が多いと考えるのが一般的です。

8. ソフトウェアのライセンスは何か?
ライセンスそのものはセキュリティとは無関係ですが、明確なライセンス情報を提供していないソフトウェアを利用することは問題があるので、注意が必要です。

9. コード評価とその結果とは?
まず、信頼できない入力に対する厳密な入力チェックや、パラメータが適切に処理された実行の記述など、開発者が安全なソフトウェアを開発しようとした証拠をコードの中に探してみましょう。また、サンドボックス内でソフトウェアを実行し、悪意のあるコードのトリガーと検出を試すのも良いかも知れません。

また、オープンソース プロジェクト向けに協調的脆弱性開示プロセスを実装するためのガイドは、前述したようにOSSを評価する際にも重要な内容になります。このガイドは、プロジェクトのメンテナーが協調的脆弱性対応プロセスを作成および管理できるようにすることを目的としています。

「協調的脆弱性開示(Coordinated Vulnerability Disclosure。以降、CVD)」とは、発見された脆弱性に関する情報をベンダ(開発者)などの関係者と調整し、修正プログラムなどの解決策が用意できてから一般公開することで、日本では2004年から運用されている「情報セキュリティ早期警戒パートナーシップ」がこのCVDの実装例になります。

OSSプロジェクトの中にセキュリティ問題の解決中にNeed To Knowの原則(必要な情報を必要な人だけが知るという原則)を保つために問題に対応でき、対処中は機密保持を信頼できる小規模なチームが必要になります。この脆弱性レポートを管理するこの小さなチームが脆弱性管理チーム (VMT)です。このガイドでは、VMTチームの役割と実行するべきプロセスについて紹介しています。

このようなレポート集を活用すると、OSSそのもののセキュリティだけでなく、システムのセキュリティレベルを上げるためにも役立つので、興味のある方は、ぜひお読みになることをお勧めします。