Varun BadhwarはEndor LabsのCEO兼共同創業者。以前はRedLockの買収後、Palo Alto NetworksでPrisma Cloudを構築した。
過去10年間で、企業はソフトウェア構築の方法を変革してきた。かつては主に独自コードだったものが、現在ではオープンソースコンポーネントが主流となっている。多くの場合、アプリケーションの80%以上がコミュニティによって維持されているライブラリやフレームワークから構成されている。この変化はイノベーションを加速させたが、多くの組織が管理できない新たなリスクももたらした。
古い戦略はもはや通用しない
長年、オープンソースのセキュリティ戦略は比較的シンプルだった：脆弱性をスキャンし、できるだけ早くパッチを当てる。最近の事件—継続中のShai-Hulud npmサプライチェーン侵害など—は、リソースが豊富なセキュリティチームや開発チームでさえ、現代の攻撃の規模と自動化に追いつくのに苦戦していることを示している。攻撃者がソフトウェアサプライチェーンを標的にし、AIコーディングアシスタントが自動的に新しい依存関係を導入する中、企業はマインドセットを進化させる必要がある。
適切なモデルはすでに存在している—それはまだオープンソースに適用されていないだけだ。ソフトウェアサプライチェーンにゼロトラスト原則を拡張する時が来ている。
従来のオープンソースセキュリティが不十分な理由
従来のオープンソースセキュリティワークフローには3つの主要な欠陥がある：
1. 後ろ向きのスキャニング。 ほとんどのセキュリティツールは、すでに報告された問題のみを追跡する公開脆弱性データベースに依存している。これにより、組織は文書化される前の新しい脆弱性や悪意のあるアップデートにさらされる。
2. 制御されていない依存関係の増加。 開発者は単一のコマンドでライブラリを追加できる—そしてAIアシスタントは開発者がリスクを認識せずに含めてしまう可能性のある新しい依存関係を提案または生成することがある。
3. 遅い修復サイクル。 脆弱性の修正は、機能を破壊する可能性のある新しいバージョンへのアップグレードを意味することが多い。修復やパッチ適用の運用コストが高額または破壊的であるため、多くのチームは未解決のリスクを抱えている。
要するに、企業のセキュリティチームは、ルールがすでに変更されているゲームで後手に回っている。
ゼロトラストの真の意味
ゼロトラストとは、システムから盲目的な信頼を排除することだ。ネットワーク内—またはこの場合、コードベース内—のものが安全であると想定する代わりに、ゼロトラストは継続的な検証、最小権限、侵害は避けられないという前提を要求する。
オープンソースに適用すると、教訓は明確だ：企業は、パッケージが人気があるから、ダウンロード数が多いから、または既知の脆弱性がないからといって安全であると想定することはできない。すべての依存関係は明示的に検証され、継続的に監視され、真に必要なアクセスのみを与えられるべきである。
オープンソースに適用される主要原則
• デフォルトで拒否：オープンソースコンポーネントは、明示的な承認なしに本番システムに導入されるべきではない。デフォルトの姿勢は「検証されるまでブロック」であるべきだ。
• 継続的に検証：パッケージが承認された後も、新しい脆弱性、悪意のあるアップデート、または放棄の兆候がないか監視されるべきだ。信頼は永続的なものではなく、継続的に再獲得される必要がある。
• 最小権限を適用：必要なライブラリのみを含め、大規模なフレームワークよりも軽量な依存関係を優先する。ソフトウェアサプライチェーンが小さいほど、防御すべきものは少なくなる。
• 侵害に備える：各依存関係に対して、明確な可視性、迅速にロールバックまたはパッチを適用する能力、リスク分離プロセスを維持する。
• 出所と可視性を確保：すべてのコンポーネントとバージョンの正確で生きた監査可能なインベントリ—またはソフトウェア部品表（SBOM）—を維持する。
オープンソースへのゼロトラストへの移行には運用上の変更が必要だ。適切に行われれば、ゼロトラストは最後の瞬間の緊急対応を防ぎ、アラートノイズを減らし、開発者に依存関係に対する信頼を与えることで摩擦を減らす。
理念から実践へ
ゼロトラスト原則を採用する企業は、このアプローチを効果的に実装するための対策を講じることができる。未検証のアップデートを取り込む可能性のある緩やかな範囲に依存するのではなく、依存関係を正確なバージョンに固定する。精度によって制御が可能になる。
チームは新しいパッケージに対するクールダウン期間の導入も検討するかもしれない。新しいバージョンを採用する前にわずかな時間待つことで、より広いコミュニティが危険信号を特定できるようになる。パッケージの健全性—一般的な脆弱性と露出—を評価することも有益だ。指標にはメンテナの活動、更新頻度、エコシステムの採用、コード品質が含まれる。
さらに、チームは開発者のワークフローにチェックを統合すべきだ。リスクのある依存関係をマージ前—プルリクエストのレビュー時など—にブロックすることは、事後対応の修復を急いで実装するよりもはるかに効果的だ。問題が発生した場合、チームはアップグレード、利用可能なパッチ、またはフォールバックオプションに関するガイダンスを含む明確な修復パスが必要だ。
マインドセットを反応的から先見的に転換することで、企業はより強力なセキュリティとより迅速なイノベーションの両方を実現する。セキュリティチームはブロッカーではなく、イネーブラーとなり、オープンソースとAI駆動の開発の安全で持続可能な採用をサポートする。
今後の道筋
現代のソフトウェアサプライチェーンは、古い習慣が存続するには複雑すぎ、動きが速すぎ、攻撃者にとって魅力的すぎる。企業は盲目的な信頼を許容できない。ゼロトラスト原則の適用は明確な前進の道を提供する：デフォルトでブロックし、継続的に検証し、露出を最小化し、侵害に備える。これは偏執ではなく、今日のソフトウェアエコシステムの現実を反映している。
この変化を受け入れる組織は、サプライチェーンリスクへの露出を減らし、エンジニアリングチームがより大きな自信を持ってより速く動けるようにする。そうでない組織は、信頼は戦略ではないことを思い出させる侵害の結果に直面するかもしれない。
