パッケージの乗っ取り、依存関係の混同、タイポスクワッティング、継続的インテグレーション／継続的デリバリー（CI/CD）の侵害、あるいは古い依存関係を悪用した単純なウェブ攻撃など、攻撃者が実行できるソフトウェアサプライチェーン攻撃は数多く存在し、被害者の業務を停止させ、身代金を要求し、重要データを窃取する。身代金を要求し、重要データを窃取する。
より大きな標的に到達するには、サプライチェーンの弱点を攻撃する方が効率的な場合が多い。ここ数年で起きたKaseyaやSolarWindsの事例がその一例だ。攻撃者はRCE（リモートコード実行）を仕掛けたり、開発者の認証情報を窃取したりして、権限を昇格させ、悪意ある操作を密かに実行できる。
さらに、現在のサプライチェーンは非常に複雑で相互接続されているため、単一のパッケージを侵害するだけで、広範なユーザーや組織にマルウェアを配布できる可能性がある。
もちろん、開発者にすべての脆弱性の責任を負わせることはできない。しかし通常、開発者は特権アカウントを持ち、機密文書やパイプラインにも直接アクセスできるため、攻撃者にとってますます魅力的な標的となっている。
開発者がサプライチェーン攻撃から身を守れるよう、米国家安全保障局（NSA）、サイバーセキュリティ・インフラセキュリティ庁（CISA）、国家情報長官室（ODNI）はこのほど、コードとプロセスのセキュリティ確保を支援する包括的なガイドを公開した。
次の記事：コードデバッグおよびコードセキュリティの主要ツール
悪意あるコードインジェクションを阻止する
このガイドによると、脅威アクターは今も公開された脆弱性情報を悪用しているが、脆弱性の公開を待つのではなく、「製品に悪意あるコードを事前に注入し、その製品をグローバルなサプライチェーンを通じて下流に正規に配布させる」という。
開発チームは更新作業や、時間のかかるDevOps（開発と運用）に苦労することが多い。そのため、デプロイやテストを自動化するCI/CDパイプラインを導入するが、プロセスの設定を誤ることもあり、セキュリティチェックが欠けている場合も多い。
もう1つの一般的な手法は、開発者だけが使用するパッケージ（NodeのdevDependenciesなど）を侵害し、AWSキーなどの認証情報を窃取するというものだ。
米国の新たなガイダンスは、ソフトウェアのライフサイクルにおける一般的な脅威シナリオを特定している。
- 攻撃者が意図的に悪意あるコードを注入する、または開発者が意図せず脆弱なコードを製品に含めてしまう。
- 脆弱性のあるサードパーティーのソースコードやバイナリが、意図的または意図せず製品に組み込まれる。
- ビルドプロセス内の弱点が悪用され、製品コンポーネントに悪意あるソフトウェアが注入される。
- 提供メカニズム内の製品が改変され、顧客がデプロイする元のパッケージ、更新、アップグレードバンドルに悪意あるソフトウェアが注入される。
文書では、リスクを低減するための具体的な対策を挙げている。
- アーキテクチャと設計の文書を作成する。
- 訓練を受けた、適格で信頼できる開発チームを集める。
- ソフトウェア製品の脅威モデルを作成する。
- セキュリティテスト計画を定義し、実施する。
- リリース基準を定め、その基準に照らして製品を評価する。
- 製品サポートと脆弱性対応に関するポリシーおよび手順を策定する。
- 開発者の能力とセキュア開発プロセスに対する理解を評価し、トレーニングを割り当てる。
- ソフトウェアリリースごとのセキュリティ手順とプロセスを文書化し、公開する。
コードを安全にする方法
安全なコードの記述には、使用するプログラミング言語にかかわらず、コードレビューやセキュリティテストなどの手順が必要となる。Rustのように、デフォルトで安全性を優先する言語であっても同様だ。
このガイドは、攻撃において悪意あるコードが意図的および意図せず注入される事例が、いずれも広く見られることを強調している。
エンジニアや開発者は、不満や外部からの影響といった一見無害な状況をきっかけに侵害される可能性がある。トレーニング不足も、発見がかなり難しく、ゼロデイ攻撃につながる可能性がある未修正のまま何カ月も残る設計上の重大な欠陥の原因となり得る。
また、プログラマーはトラブルシューティングやセットアップを容易にするため、特殊なパラメーターやその他のデバッグ機能を実装することがある。残念ながら、こうした「ハック」が利便性を理由に本番環境へ持ち込まれたり、使用後に削除するのを単に忘れられたりすることは珍しくない。
このガイドは、技術チームに次の緩和策を適用するよう促している。
- GITリポジトリの適切な運用や多要素認証（MFA）など、バランスの取れた認証付きソースコードチェックインプロセスを実装する。
- 自動の静的・動的セキュリティ／脆弱性スキャンを実行する。
- セキュリティテストとリグレッションテストを含む夜間ビルドを実施する。
- 開発用パッケージの制限や未使用の依存関係の削除など、要件に機能を対応付ける。
- コードレビューを優先し、重要なコードをレビューする。
- セキュアなソフトウェア開発／プログラミングのトレーニングを実施する。
- 次のような手法で開発環境を強化する：VPN、MFA、「ジャンプホスト」、各環境の脅威モデリングなど。
ビルドプロセスを改善する方法
個々の開発者向けであれ本番ビルド環境向けであれ、エンドユーザーに提供・配布する前にソフトウェアのセキュリティを検証することが推奨される。チームはさまざまなツールや手法を活用できる。例えば次のようなものだ。
- 脆弱性スキャン、ペネトレーションテスト、透かし、データ損失防止（DLP）、完全性チェックなどの間接的な制御を導入する
- SBOM（ソフトウェア部品表）とデジタル署名で提供物を検証する
- 迅速な反復サイクル（アジャイル開発）
- すべてのパイプラインのアクセスログ
- シークレットを暗号化する
- 最小権限の原則
- ネットワークの分離
- オンプレミスでのデプロイ
- バージョン管理
- CI/CDパイプラインでのA/Bテスト
バージョン管理のベストプラクティス
この文書は、ソースコードを保護するためのガイドラインを示している。
まず、アクセスと検証は、ソースコードリポジトリへの変更を追跡するための適切なソースコード管理（SCM）原則から始まる。
開発チームは、新たな脅威やバージョン、更新が見つかった際に通知を受けられるよう、通知機能も有効にすべきだ。GitLabやGitHubなどの主要なバージョン管理プラットフォームにはこうした機能があるが、ガイドはさらに踏み込み、「すべての開発者と、開発者がダウンロードしたコンポーネントのログ」を保持するよう推奨している。
リポジトリへの「すべてのアクセス」でMFAを有効にし、チームは基本的なGitブランチ機能を活用して整理を維持できる。
- 開発者は開発ブランチで作業する。
- リード開発者は、コードレビューと承認の後、ソフトウェアをQA（品質保証）ブランチに昇格させる。
- QAチームはQAブランチのソフトウェアをテストする。
- 承認されれば、ブランチを本番環境にマージできる。
ガイドは、本番ブランチへのアクセスを「少数のビルド担当者とチームメンバー」に制限し、ビルドを保護するため、リリースごとにロックダウン手順を実施するよう推奨している。
開発者はコミットにも署名すべきだ。ガイドでは明示されていないが、攻撃の中には盗んだ鍵を使ってコミットをプッシュするものがある。この場合、不正な変更が正規ユーザーによるものとして扱われてしまう。
開発者が環境のセットアップに一時的な鍵を使うことは珍しくない。使用後に鍵を削除しなければ、攻撃者はサーバーへのアクセスを得た後に鍵を発見できる可能性がある。
別の攻撃としては、偽のパッケージを作成し、メンテナーの情報を使ってGitを設定することで、正規のメンテナーの身元を偽装する手法がある（タイポスクワッティングなど）。
開発者はGPG（Gnu Privacy Guard）鍵や、Gitsignなどのライブラリを使ってコミットに署名できる。万全ではないが、この追加のセキュリティ層は比較的簡単に設定できる。
次の記事：主要な脆弱性管理ツール