インターネット黎明期、サイト数が数百万に過ぎなかった時代（今日の16億サイトと比較すると）、トランスポート層セキュリティ（TLS）の導入は容易ではありませんでした。Web開発者はブラウザ用の証明書を購入することはできましたが、高価で使いにくく、自動化も不十分でした。httpsが設定されていないサイトにアクセスし、ブラウザからセキュリティ警告メッセージが表示された経験は、誰もが覚えているでしょう。
参照:モバイルデバイスのセキュリティポリシー(TechRepublic Premium)
その後、Let's Encryptが登場し、TLSを無料、シンプル、そして自動化しました。そして数年のうちに、Webの大部分が暗号化されました。開発者は正しいことをしたいと思っています…ただ、簡単で自動化されていれば良いのです。
今日、開発者にとって新たな大きなセキュリティ課題が待ち受けています。それは、ソフトウェアサプライチェーンのセキュリティです。容易な対応も自動化も不可能です。オープンソースプロジェクトとベンダーは、このギャップを埋めるために競い合っています。
生産は確保したが、ビルドの確保を忘れた
Log4Jとソフトウェアサプライチェーンの成果物をどのようにロックダウンするかという問題は、当初、メンテナーとコントリビューターのモデルが破綻しているという批判的な意見に単純化されすぎていました。これは私が書いた記事でもありました。しかし、実際はそれよりもはるかに複雑です。
「アプリケーションセキュリティとインフラセキュリティの基準は向上しました」と、ChainguardのCEO兼共同創設者であるダン・ロレンク氏は述べています。「パスワードをどこでも使い回すことはなくなりました。HTTPSは使いやすく、あらゆるウェブサイトで利用されています。パスワードを平文で送信することはもうありません。攻撃者は従来の方法では成功せず、より耐性の低い手段、つまりサプライチェーン攻撃へと移行します。もし攻撃者が自衛をしっかり行えば、彼らが利用しているベンダー、オープンソースの依存関係、あるいはライブラリを特定し、そこから彼らの顧客すべてに攻撃を仕掛けることができます。」
Chainguard入社以前、LorencはGoogle Cloud Platformの基盤インフラに9年間携わっていました。そのため、この問題への取り組みにはある程度（というか、かなり）精通しています。
Googleの社内セキュリティ対策は素晴らしかったです。構築には何年にもわたるプロセスが必要でしたが、ユーザーデータを真に保護するために、複数の承認なしにコードを実行できないシステムを構築していました。当時、つまり2012年か2013年当時は、開発者は本番環境でルート権限を持っておらず、すべてをチェックするために複数の人員が必要でした。
しかし、クラウドが登場し、誰もがコンテナとKubernetesに取り組み始めると、Lorenc氏は、開発者の多くが、安全なビルド環境を明らかにするものではなく、ラップトップや机の下のJenkinsマシンでビルドしていることに気づきました。
「突如として、Mac Miniを購入し、経費として計上し、机の下に置き、Jenkinsをインストールして、そこからリリースを行うのが最先端技術になったんです」と、当時Minikubeプロジェクトに携わっていたロレンク氏は語る。Minikubeは後にラップトップでKubernetesを実行するための標準的な方法となった。「80MBのGoバイナリをGitHubにアップロードすると、みんながそれをダウンロードして、自分のラップトップでルート権限で実行していました。正直言って、本当に恐ろしい状況でした。そして、どうすればこの状況を改善できるのか、という迷路に陥ってしまったんです」
欠けているのはソフトウェア成果物の信頼のルートである
ロレンツ氏はGoogleでChainguardの共同設立者であるキム・レワンドウスキー氏と出会い、2人は共同で作成し共同で維持している一連のオープンソースプロジェクトを通じてソフトウェアサプライチェーンのセキュリティ問題に取り組んできた。
「ソフトウェア開発と展開のサプライチェーンは非常に複雑で、ソースコード→ビルド→公開のワークフローには数多くの脅威が潜んでいます」と、レワンドウスキー氏はブログ記事で述べ、開発者がソフトウェア成果物をロックダウンするためのツールチェーンが一般的に不足していることを指摘しました。「特定の脆弱性に対するポイントソリューションは確かに存在しますが、ソフトウェアサプライチェーン全体にわたる脅威を軽減する方法を定義し、合理的なセキュリティ保証を提供する包括的なエンドツーエンドのフレームワークは存在しません。」
そこで、レワンドウスキー氏とロレンツ氏はオープンソースを通じてこの問題を解決しようと試みました。ソフトウェア・アーティファクトのサプライチェーン・レベル（SLSA、発音は「サルサ」）、Sigstore、Tektonといったオープンソース・プロジェクトは、ソフトウェア・サプライチェーン・セキュリティにおけるゼロトラスト・セキュリティの究極のビジョンの様々なレイヤーに焦点を当てています。ゼロトラスト・セキュリティとは、あらゆるアーティファクトが、その基盤となったソースコードとハードウェア、そして誰が作成したかまで、検証可能な形で追跡できるセキュリティです。
ChainguardがEnforceをリリース
Chainguardは、Amplify Partnersが主導する500万ドルのシード資金を確保してから5か月も経たないうちに、本日開始したEnforceと呼ばれる初の商用サービスに、これらの新しい信頼の基盤を組み込んだ。
Enforce は、SLSA や米国国立標準技術研究所の Secure Software Development Framework (SSDF) 標準などのオープンソース プロジェクトに基づいて、厳選されたポリシー定義のセットを提供します。
Enforceのポリシーエージェントは、コンテナ内で実行されているものを、実際のバイナリコード（コンテナイメージ）自体から検出します。開発者は、コンテナイメージの内容、ビルド方法、入手元に基づいてポリシーを適用できます。また、継続的な検証により、デプロイされたコンテナイメージが定義されたポリシーに準拠していることを確認できます。
「私たちは、展開時に何かをブロックするのではなく、実際に何が実行されているかを確認するという逆のアプローチを採用しています」とロレンク氏は述べた。「ソフトウェアのサプライチェーンに関連するメタデータの多くは、時間の経過とともに変化します。展開前の状態だけを見ていると、問題の90%を見逃してしまいます。なぜなら、最初に構築して展開した時点では重大な脆弱性がなかったとしても、3年後も重大な脆弱性がないとは限らないからです。つまり、これは単なる展開アプローチではなく、継続的なポリシーシステムアプローチなのです。」
サプライチェーンのセキュリティは今後多忙な時期を迎える
ソフトウェアのサプライチェーンにおけるセキュリティの状況はまだ初期段階にあり、今後急速に変化していくでしょう。昨年、ホワイトハウスはサイバーセキュリティの向上に関する大統領令を発令し、「ソフトウェア構築に使用される様々なコンポーネントの詳細とサプライチェーンの関係性を含む正式な記録」の必要性を明確に示しました。
私たちは何十年もソフトウェアで何かを構築し、生産のセキュリティにこだわり続けてきましたが、その後、誰も見ていない誰かの机の下に置かれた、パッチが適用されていない Jenkins ボックスで (頻繁に) 構築してきました。
新しいタイプのオープンソースプロジェクトとセキュリティベンダーは、ビルドシステムは少なくとも本番環境と同等のセキュリティを備えるべきだと考えています。そして、オープンソースプロジェクトと、Enforceのようなガードレールを備えた商用製品との間には共生関係が生まれ、ベンダーはこうした微妙なユースケースに合わせて開発者エクスペリエンスをパッケージ化していくでしょう。
「ソフトウェアサプライチェーンのセキュリティは非常に特殊です」とロレンス氏は述べた。「ソフトウェアライフサイクルの様々なポイントを狙う、多種多様な攻撃が存在します。セキュリティソフトウェアを1つ選んで有効にするだけで、あらゆる脅威から保護されるわけではありません。SLSAやSSDFといった様々なオープンソースフレームワークを組み合わせて活用することで、ソフトウェアサプライチェーンのセキュリティ対策を進化させていくというパターンが今後見られるようになると思います。」
開示: 私は MongoDB で働いていますが、ここで表明されている意見は私個人のものです。
