GitHub は、オープンソース ユーティリティ、開発者ツール、アプリ ストアでは見つからないニッチなアプリの拠点です。これらのプロジェクトの多くは本当に役に立ちます。しかし、中にはメンテナンスが不十分であったり、安全でなかったり、完全に悪意のあるものもあります。良いものと悪いものを区別する方法は次のとおりです。
GitHub はコラボレーションのためのプラットフォームであり、セーフティ ネットではありません。誰でも無料でコードを投稿できるのは素晴らしいことです。しかしそれは、悪意のあるプロジェクトやずさんなプロジェクトがすり抜けてしまうということも意味します。ユーザーは常に注意を払う必要があります。オープンソースだからといって自動的に安全であるとは限りません。コードを精査し、メンテナをチェックし、ダウンロードしたものを盲目的に信頼しないでください。あなたの安全はあなたにかかっています。
そうは言っても、一部のプロジェクトがどのようにしてセキュリティ問題になるのかを以下に示します。
多くのプロジェクトは、ソフトウェアの構築とリリースのために GitHub Actions に依存しています。しかし、なぜ GitHub Actions を使用するのでしょうか?
GitHub Actions は、GitHub の組み込み CI/CD システムです。これにより、リポジトリは、コミット、プル リクエスト、リリース タグなどのイベントに応じてジョブを自動的に実行できます。これを使用すると、テストの実行、バイナリの構築、Docker イメージのパッケージ化、さらにはサーバーへのデプロイが可能になります。とても便利ですよね？
しかし、この便利さにはリスクも伴います。アクションの設定が不十分だと、バイナリがソース コードと一致しなかったり、セキュリティの問題が気付かれずにビルドされたりするなど、信頼性の低いビルドが発生する可能性があります。自動化は慎重なレビューに代わるものではありません。
Windows ハッキングのほとんどは、高度な攻撃ではなく、日常の習慣によって可能になります。
すべての問題が CI/CD パイプラインに起因するわけではありません。放棄されたプロジェクトの場合もあります。メンテナが異動すると、プロジェクトは静かに腐ってしまう可能性があります。依存関係にパッチが適用されず、ビルド システムが劣化し、脆弱性が蓄積します。アクティブに維持されているプロジェクトは、セキュリティの点で放棄されたプロジェクトよりも優れています。
すべての脅威がメインのコードベースから発生するわけではありません。 JavaScript エコシステムでは、信頼できるパッケージが一夜にして敵対的になる Shai-Hulud キャンペーンなど、悪意のあるインストール後のスクリプトや依存関係のハイジャックが発生しています。依存関係が注意深く監査されていない場合、GitHub リポジトリがこれらの攻撃の配布ポイントになる可能性があります。
何かをダウンロードする前に、数分かけてリポジトリを評価してください。
健全なプロジェクトには生命の兆候が見られます。最近のコミット。未解決の問題と解決された問題。活発なプルリクエストのディスカッション。これは、GitHub 上で生命の兆候がどのように見えるかです。
スター、フォーク、トレンドのバッジは便利です。しかし、それらは信号であり、保証ではありません。
Stargazers Ghost Network のようなキャンペーンが文書化されており、数千の偽の GitHub スターが悪意のあるリポジトリを人為的に強化して信頼できるように見せかけます。これだけではありません。ある調査研究により、GitHub 上で偽スターと疑われる 600 万人が特定されました。
星の数だけに感動するのではなく、次の点に注目します。
実体のない人気は危険信号だ。
研究者らは、GitHub リポジトリで推定 450 万個の偽のスターを発見しました。
私は、ほとんどの作業を 1 人の人間に依存しているオープンソース ソフトウェアを驚くほど多く見てきました。私にとって、これは深刻な持続可能性リスクです。
プロジェクトに 5,000 人以上の貢献者がいるからといって騙されないでください。代わりに、寄稿者間で均等な分配が行われるようにしてください。透明性のあるガバナンスと包括的なリーダーシップを備えたプロジェクトは、より長く存続し、問題が発生した場合でもより良く回復する傾向があります。数人ですべての重労働を行っている場合、および彼らが去った場合に備えて。そのプロジェクトは運命にある。
README を見ると、作成者がツールに何を望んでいるのかがわかります。問題はそれが実際に何であるかを教えてくれます。
私がスキャンするもの:
活発な議論、明確な貢献ガイドライン、敬意を持ったコミュニケーションはすべて、品質と信頼性を示す強力な指標です。
一貫したリリース頻度とタグ付きバージョンは成熟度を示しています。長い空白、突然の大きな変更、または 1 回のリリースのみの場合は、注意が必要です。
クリックしてメンテナーのプロフィールにアクセスします。
共同作業が目に見える長期にわたるアクティブなアカウントは、偽造が難しく、一般に信頼性が高くなります。
コンパイル済みのリリース資産は便利ですが、信頼が必要です。可能な限り、バイナリがソース コードと正確に一致することを確認できる、再現可能なビルドをサポートするプロジェクトを好みます。
ソースからビルドすることを強くお勧めします。これにより、実行中の内容を直接確認できるようになります。
プリコンパイルされたアプリケーションをダウンロードするとき、私は常に SHA256 または SHA512 チェックサムを比較して、ファイルが変更されていないことを確認します。暗号化フィンガープリントは、ファイルが発行者が意図したものとビットごとに同一であるかどうかを示し、ダウンロード中またはホスティング中の破損、改ざん、または置換から保護します。
さらに強力な方法は、PGP/GPG 署名を検証することです。署名は、ファイルが署名されてから変更されていないことを確認するだけでなく、誰が署名したかを証明します。より高いレベルの信頼性と信頼性を提供します。
それだけ注意することしかできません。どんなに予防策を講じたとしても、物事は思わぬ方向に進むことを想定してください。そのため、私は最も信頼できる防御線としてサンドボックスまたは分離に大きく依存しています。プロジェクトが大ざっぱだと思われる場合は、メイン システムでは決して実行しません。代わりに、仮想マシンまたは Docker コンテナを起動し、その環境内でアプリを安全に実行します。
それに加えて、私は常に最小限の特権の原則を適用します。絶対に必要な場合を除き、管理者または root としてツールを実行することはありません。ファイルとネットワークへのアクセスを制限し、潜在的なリスクを最小限に抑えるために可能な限り自動起動サービスとバックグラウンド サービスを無効にします。
GitHub からアプリをダウンロードすることは本質的に危険ではありませんが、盲目的にダウンロードすることは危険です。そうでないことが証明されるまで、すべてのリポジトリを信頼できないものとして扱います。その背後にある人々、彼らが従うプロセス、および彼らが生成するアーティファクトを確認してください。ダウンロードしたものを確認し、実行したものを分離し、時間の経過による変化に常に注意してください。
これらの慣行に従うことで、不必要なリスクにさらされることなく、オープンソース ソフトウェアの利点を安全に享受できます。