2.18 依存関係とサプライチェーンの管理

概要と動機

プロジェクトのロックファイルを開いて、パッケージを数えてみてください。ほとんどのチームと同じなら、自分たちが書いたコードは、自分たちが書いたのではなく、完全には理解しておらず、簡単には監査できない、何百何千もの依存関係の上にある薄い層です。現代のウェブサービスは、フレームワーク、データベースドライバ、ログのライブラリ、シリアライズ形式を取り込み、それぞれがさらに多くを取り込みます。その結果、実行中のソフトウェアの大半、しばしば大多数が、インターネット上の見知らぬ人々から来たものです。それは失敗ではありません。小さなチームが、かつては何年もかかったことを数週間で出荷できるようにする取引です。要点は、その取引を目を開いて引き受けることです。

その借り物のコードをうまく管理することは、それ自体が一つのエンジニアリングの規律であり、本章はその技芸についてです。依存関係をどう選び、固定し、更新し、ビルドを再現し、グラフが育つなかで全体を読める状態に保つか。攻撃者が意図してそのグラフを汚染する、セキュリティの脅威の側面は、アプリケーションセキュリティの4.2章で十分に扱います。ここでの関心事は日々のエンジニアリングです。バージョンの制約、ロックファイル、推移的な衝突、更新の周期、そしてソフトウェアに何が入っているかを知ること。これを正しくやれば、セキュリティははるかに容易になります。見えないサプライチェーンは守れないからです。

大きなチーム、特に企業と政府にとって、賭け金は規模とともに上がります。五百のリポジトリがそれぞれ独自のライブラリを選ぶと、同じログのフレームワークの五百の少しずつ異なるバージョン、誰も承認していないライセンスが生まれ、深刻な脆弱性が現れたときに「影響を受けるか」に答える方法がありません。企業はこれに、承認されたライブラリと共有のレジストリで答えます。政府はますます、義務づけで答えます。米国の大統領令14028は、ソフトウェア部品表(SBOM)とビルドの来歴を、購入するソフトウェアの基準に押し上げました。次の依存関係の危機の間、冷静でいられる組織は、必要になる前にこの仕事をしていた組織です。

主要原則

ソフトウェアの大半は自分で書いていないコードです。書いていなくても、その責任を負います。
すべての依存関係は資産であると同時に、恒久的な負債です。反射的にではなく、意図して加えます。
ロックファイルでバージョンを固定し、ビルドを「その日の最新が何であれ」ではなく、再現可能で決定的にします。
まれで恐ろしい飛躍ではなく、小さな自動化された増分で、安定した周期で更新します。
ソフトウェアに何が入っているかを正確に知ります。列挙できないものは、守ることもライセンスを管理することもできません。
便利な多数の依存関係より、少数のよく保守された依存関係を好みます。
パッケージの出所を管理します。検証されないレジストリは、開いた扉です。

推奨事項

バージョニングを理解し、意図して制約する

エコシステムがバージョンをどう表現するかを学んでください。更新の振る舞いはそれに完全に乗っているからです。ほとんどのパッケージマネージャーは、何らかの形のセマンティックバージョニング(SemVer)を使い、バージョンはMAJOR.MINOR.PATCHと読みます。パッチの上昇はバグ修正だけを約束し、マイナーの上昇は後方互換な機能を加え、メジャーの上昇は破壊的な変更を示します。依存関係の宣言は、「4.xと互換」や「2.3.0以上」のような制約を設定し、リゾルバがバージョンを選ぶときにどこまで動いてよいかを伝えます。

その制約がどれだけゆるく、あるいはきつくあるべきか、意図してください。ゆるい範囲は、レビューしていないマイナーリリースが本番に滑り込むのを許すコストと引き換えに、修正を自動的に取り込み、きつい固定は、手作業の労力と引き換えに制御を与えます。ほとんどのチームにとって実用的な答えは、マニフェストにはそれなりに寛容な範囲を宣言し、それから解決された正確なバージョンをロックファイルに固定して、範囲が意図して更新したときにだけ再評価されるようにすることです。SemVerは、メンテナが守ろうとする約束であって、常に守る保証ではないものとして扱ってください。「パッチ」リリースでも壊れることはあり、まさにだから更新は信頼するのではなくテストするのです。

ロックファイルをコミットし、再現可能なビルドを求める

ロックファイルは、直接のものも推移的なものも含め、依存関係グラフのすべてのパッケージの正確なバージョンと暗号学的ハッシュを記録します。それをバージョン管理(2.6章)にコミットし、ソースの第一級の一部として扱います。その役目は、ビルドを関数にすることです。同じ入力が、すべてのマシンで、今年も来年も、毎回同じ出力を生みます。それがなければ、一週間離れて「install」を実行した二人のエンジニアが異なるコードを得ることがあり、本番に現れるバグは、それをビルドしたノートPCでは再現できないかもしれません。

与えられたコミットが常に振る舞いの同一な成果物を生む、本当の意味で再現可能なビルドを目指します。継続的インテグレーション(8.1章)では、ロックファイルから厳密にインストールし、新しいバージョンを黙って解決するのではなく、ロックファイルとマニフェストが一致しなければビルドを失敗させます。ロックファイルのハッシュは二重の役割を果たします。振る舞いを固定し、改ざんを検出します。内容が記録されたハッシュと一致しなくなったパッケージは、インストールされないからです。再現性は、本章の他のすべてが拠って立つ基礎です。

推移的な依存関係とダイヤモンド衝突を意図して管理する

直接の依存関係は、名指ししたものだけです。その下には、あなたのパッケージが依存するパッケージという、はるかに大きな推移的な依存関係のグラフがあり、そこにリスクの大半と驚きの大半があります。古典的な失敗はダイヤモンド依存です。ライブラリAが共有のユーティリティのバージョン1を必要とし、ライブラリBがバージョン2を必要とし、リゾルバは不可能な要求を調整しなければなりません。一部のエコシステムは、ディスクとメモリを平穏と引き換えに複数のバージョンを共存させ、他は単一のバージョンを強制して、衝突の仲介をあなたに任せます。

これらの衝突を膿ませる代わりに、見えるようにしてください。ツールを使って依存関係ツリー全体を表示し、あるパッケージがなぜ存在し、誰が取り込んだのかを説明させます。衝突が現れたら、意図して解決します。遅れているものをアップグレードする、上書きを固定する、要求を満たせない依存関係を落とす。時間とともにグラフの成長を見てください。推移的な依存関係の野放しの広がりは、技術的負債のゆっくりした蓄積で、最終的に、解決できないアップグレードや、書き直しなしにはパッチできない脆弱性として現れるからです。

自動化されたプルリクエストで、安定した周期で更新する

最もリスクの高い更新の戦略は、ほとんどのチームが偶然流れ着くものです。決して更新せず、重大な脆弱性に手を強いられたときに、緊急の圧力のもとですべてを一度に更新する。その頃には何年も遅れていて、変更履歴は壁のようで、アップグレードは日常の雑務ではなく数週間のプロジェクトです。直し方は周期です。新しいバージョンが出るたびに、変更履歴とテスト結果を添えたプルリクエストを開く、自動化された依存関係アップデーター(DependabotやRenovateのツールが一般的な例です)を採用します。

それから、流れを、あなたを溺れさせるのではなく助けるように調整します。毎朝個別のプルリクエストが大量に来ると、人々はそれを無視するようになり、自動化がまったくないよりも悪くなります。パッチリリースのような低リスクの更新をまとめ、テストが通れば自動的にマージさせ、人間の注意は、メジャーバージョンの上昇と、機微なライブラリに触れるものに取っておきます。チームが維持できるリズム、たとえば週次のレビューを設定し、更新が、まれな痛みを伴う請求書ではなく、小さく安定した税であり続けるようにします。ここで強いテスト戦略(2.4章)が見返りをもたらします。自動の更新は、テストがそれが壊すものを捉えられる場合にだけ安全だからです。

足跡を最小化し、採用する前に評価する

加えるすべての依存関係は、継続的なコミットメントです。そのバグ、その脆弱性、そのライセンス、そのメンテナの継続的な関心、そしてそれ自身の育つサブ依存関係のグラフへの。管理するのが最も安い依存関係は、加えなかったものです。パッケージに手を伸ばす前に、自分のコード数十行で足りないかを問ってください。特に些細な機能では。パッケージのエコシステムの歴史は、広く依存されている小さなパッケージが削除されたり乗っ取られたりして、インターネットの半分を壊した教訓的な話でいっぱいです。

採用するときは、候補を、長期の関係であるかのように評価します。保守の健全性を確認します。最近のコミット、応答するメンテナ、本物のリリース履歴、鍵を持つ人が一人より多いこと。ライセンスを確認し、それが承認リストにあることを確かめます(10.3章)。セキュリティの実績、サイズ、そのものの推移的な足跡を確認します。小さな機能は、百のパッケージを引き込む価値がないからです。「これを加えるべきか」が、気分ではなく、チーム全体が一貫して適用するチェックリストになるよう、これらの基準を書き留めます。

SBOMを作成し、ビルドの来歴を捕捉する

ソフトウェアに何が入っているかをすでに知っていなければ、「この脆弱性の影響を受けるか」に素早く答えられません。SBOMがその答えです。ビルドのあらゆる構成要素の、バージョンとライセンスを含む、SPDXやCycloneDXのような標準の形式の機械可読な一覧。ビルドのパイプラインの一部として自動的に生成し、成果物と並べて保存し、その成果物がどこかで動いている限り保持します。次の見出しになる脆弱性が出たとき、SBOMに対するクエリが、慌ただしいgrepの一週間を5分のレポートに変えます。

もう一歩進んで、来歴を捕捉します。成果物がどのようにビルドされたか、どのソースのコミットから、どのパイプラインでか、の署名された改ざんが明らかになる記録です。オープンソースソフトウェアのコミュニティは、まさにこのための段階的なモデルとして、SLSAフレームワーク(Supply-chain Levels for Software Artifacts)に収束しました。「ビルドを記述できる」から、「それを証明でき、その証明は侵害されたビルドシステムに耐える」まで進みます。証明書(アテステーション)は、利用者が成果物が本当にあなたのパイプラインから来たことを検証できるようにします。政府の仕事では、これはますます任意ではありません。来歴とSBOMは調達の義務づけの中にあるので、早くから能力を築いておくことで、入札の資格を保てます。

レジストリ、ミラー、ベンダリングで出所を管理する

パッケージがどこから来るかは、どのパッケージを選ぶかと同じくらい重要です。ビルドのたびに公共のインターネットから直接取得すれば、その障害、取り下げられたバージョン、その攻撃者を引き継ぎます。公共のエコシステムをプロキシする社内のパッケージレジストリやキャッシュミラーを立ち上げ、ビルドが速く、再現可能で、上流が消えることから隔離されるようにします。レジストリは、方針を徹底する自然な場所にもなります。既知の悪いバージョンをブロックし、新しいリリースを短い浸漬のために隔離し、ライセンスやセキュリティのゲートに失敗したパッケージを拒否します。

二つの特定の罠を避けるよう、そのレジストリを慎重に設定してください。依存関係の混乱は、ビルドツールが、同じ名前の私的な社内パッケージと公共のパッケージの両方を提示されたとき、攻撃者の公共のほうを取得すると起きます。社内の名前にスコープを付け、社内のパッケージを社内のソースに明示的に固定することで防ぎます。タイポスクワッティングは、悪意のあるパッケージが人気のものからキー一つ違いの名前を使い、打ち間違いを待つときに起きます。許可リストを持つ管理されたレジストリは、入口でそれを止めます。少数の重要な、あるいは変化の遅い依存関係には、ベンダリング、つまり実際の依存関係のソースを自分のリポジトリにチェックインして、ビルドの外部依存をゼロにすることを検討してください。更新の便利さを完全な制御と引き換えにするもので、ときにまさに正しい選択です。

トレードオフ: 長所と短所

アプローチ	長所	短所
ゆるいバージョン範囲	自動の修正。手作業の労力が少ない	レビューされていないコードが本番に届く。ロックファイルなしでは非決定的
厳格な固定とロックファイル	再現可能で監査可能なビルド	意図した更新作業が必要。修正が遅れうる
積極的な更新の周期	小さく安全な歩み。常に最新に近い	絶え間ない変動。安定したレビュアーの注意が必要
まれな、まとめた大きなアップグレード	日々の中断が少ない	恐ろしく、危険で、強いられると高価
便利な多数の依存関係	機能を作るのが速い	大きな攻撃面。重い保守の負荷
最小の足跡とベンダリング	制御、小さな表面、上流のリスクなし	所有するコードが増える。更新を自分で担う
公共レジストリへの直接アクセス	設定ゼロ	障害、取り下げ、混乱とタイポスクワッティングへの露出
社内レジストリとミラー	速度、方針の徹底、隔離	運用し保守するインフラ

中心的な緊張は、速度と制御の間にあります。上記のすべての選択は、異なる角度から見た同じダイヤルです。借りてきたコードのどれだけを積極的に統治し、どれだけを信頼で流れ込ませるか。制御に傾きすぎれば、手作業のレビューに溺れ、セキュリティ修正に遅れ、依存関係が速めるはずだったチームを遅くします。速度に傾きすぎれば、ある日、監査できず、アップグレードできないグラフと、弁護士に説明できないライセンス違反とともに目覚めます。解決は固定点ではなく姿勢です。すべてをロックして再現し、小さな歩みで継続的に更新し、引き受けるものを最小化し、自分が管理する関門で方針を徹底する。その組み合わせが、速度と安全の両方を買い、それが規模で行う価値のある取引です。

チームで議論すべき問い

実際の更新の周期はどれくらいで、強制された緊急のアップグレードは数時間かかりますか、数週間かかりますか。 ほとんどのチームは、重大な脆弱性が問題を強いるまで、これに正直に答えられません。本章は、安定した、自動化された、小さな歩みの更新を安全な道とし、まれな一括のアップグレードを危険なものとして扱います。開けたままにしたギャップは、後に圧力のもとで駆け抜けなければならないギャップだからです。証拠を持ち込んでください。依存関係のうちいくつがメジャーバージョンで一つ以上遅れているか、直近の大きなアップグレードが実際にどれだけかかったか。自動のアップデーターを採用できるか、人々が聞き流さないよう低リスクの変更をどうまとめるか、自動マージが安全になるためにどんなテストが必要かを議論してください。答えは、エンジニアリングの時間の予算の立て方を変え、まれな危機を日常の週次の税に変えるはずです。正直な答えが「数週間」なら、それはインシデントの最中に発見するのではなく、今名指しすべきリスクです。
一般的なライブラリで深刻な脆弱性が今発表されたら、動かしている影響を受けるすべての成果物をどれだけ速く一覧にできますか。 これはSBOMが答えるために存在する問いであり、答えの速さは、サプライチェーンの成熟度の直接の尺度です。一覧がなければ、リポジトリをgrepしたりチームに聞いて回ったりするしかなく、時計が進むなか、持っていないかもしれない日数がかかります。具体的なシグナルを持ち込んでください。ビルドごとにSBOMを生成しているか、どこに保存されているか、今日実際にそのすべてを横断して問い合わせられるか。直接の依存関係だけでなく、推移的なグラフも知っているかを議論してください。脆弱なパッケージは、通常、名指ししたことのないものだからです。答えは、次のインシデントがクエリになるか、避難訓練になるかを決め、必要になる前に能力を築く価値があります。政府はまさにその理由で、今これを義務づけています。
新しい依存関係を採用する価値があるかをどう決め、全員が同じ基準を適用していますか。 本章は、すべての依存関係が便利さであると同時に恒久的な負債であり、管理するのが最も安いのは加えなかったものだと論じています。それでも、ほとんどのチームでは、その決定は見えません。エンジニアが機能を必要とし、パッケージを見つけ、保守、ライセンス、セキュリティの履歴、足跡のレビューなしに、昼食までにロックファイルに入ります。自分たちのグラフから、誰も採用した覚えがなく、今日擁護できないパッケージの例を持ち込んでください。書面の評価チェックリストと承認されたライブラリのリスト(10.3章)が助けになるか、摩擦を加えるだけか、そして自分で書くべき些細なヘルパーと、依存する価値のある本物のインフラの境界線がどこにあるかを議論してください。答えは、チームが背負う長期の重みを、小さな決定一つずつ形づくります。
推移的な依存関係を実際に統治していますか。それとも名指ししたものだけですか。 リスクの大半は一つ下、あなたのパッケージが取り込んだパッケージにあり、二つのライブラリが共有ユーティリティの互換性のないバージョンを要求するダイヤモンド衝突は、最悪のタイミングでアップグレードをブロックしえます。規模ではこれが重要になります。パッチできない推移的なパッケージ一つが、何百ものリポジトリにわたってセキュリティ修正を凍結しえて、相反する引力は本物だからです。グラフ全体を表面化して固定することは継続的な労力を要し、無視することは、その労力を、解決できないアップグレードとして現れる負債のゆっくりした蓄積と交換します。証拠を持ち込んでください。ツールが完全なツリーを表示して、あるパッケージがなぜ存在し誰が取り込んだかを説明できるか、最も一般的なライブラリのいくつの異なるバージョンが今日共存しているか。企業や政府では、一覧と方針が推移的な構成要素に届いているかも加えてください。グラフの半分が見えないなら、ソフトウェアに何が入っているかを知れという義務づけは無意味だからです。答えは、次の強制されたアップグレードが日常のマージか、複数のチームによる発掘かを教えてくれます。
パッケージは実際にどこから来ていて、攻撃者がそれを滑り込ませるのを何が止めていますか。 公共のインターネットから直接取得するすべてのビルドは、その障害、取り下げられたバージョン、二つの特定の攻撃を引き継ぎます。ビルドツールが私的なパッケージを覆い隠す公共のパッケージを取得する依存関係の混乱と、悪意のあるパッケージが人気の名前からキー一つ違いに置かれるタイポスクワッティング。これは大きなチームにとって重要です。毒された取得一つが、誰かが気づく前に資産全体に伝播しうるからで、トレードオフは本物です。社内のレジストリやキャッシュミラーは、方針の関門と上流からの隔離を与えますが、誰かが運用し最新に保たなければならないインフラです。具体的なシグナルを持ち込んでください。社内のパッケージ名は明示的にスコープ付けされ、社内のソースに固定されているか、許可リストはあるか、新しいリリースは使われる前に短い隔離を受けるか。政府や規制された買い手にとっては、調達がますます求める承認済みソフトウェアのリストと直接のインターネット接続なしの姿勢にこれを結びつけ、現在の構成が今日その基準を通るかについて正直であってください。
成果物がどうビルドされたかを、実際に再現し証明できますか。 暗号学的ハッシュを含むコミットされたロックファイルは、ビルドを関数にするはずです。同じ入力が、すべてのマシンで今年も来年も同じ出力を生み、来歴は、成果物が本当にあなたのパイプラインとソースのコミットから来たことを、誰でも検証できるようにするはずです。これが重要なのは、再現不能なビルドが本番のバグを解けない謎に変え、改ざんがなかったことを証明できなくするからで、相反する考慮は労力と保証です。厳密なロックファイルのインストール、署名された証明書、SLSAに沿った来歴は、「最新をインストールするだけ」の流れが避ける設定と規律のコストがかかります。証拠を持ち込んでください。ロックファイルとマニフェストが一致しないとき継続的インテグレーションが失敗するか、ビルドごとにSBOMと署名された来歴の記録を生成して保存しているか、誰かが一度でもそれを検証したか。企業、特に政府の仕事では、来歴とSBOMがますます調達の義務づけの中にあるので、ここでの正直な答えが、入札の資格を保てるか、締め出されるかを決めます。

セクター別の視点

スタートアップ。 小さなチームでプラットフォームのグループもないので、プロセスではなく既定と自動化に頼ってください。初日からロックファイルをコミットし、パッチリリースをまとめてテストが通ればマージする自動のアップデーターを有効にし、パッケージを加えるための軽いルールを一つ保ちます。退屈でよく保守されたライブラリを好み、小さなものは二度考える。まだ社内レジストリは作らず、それで構いませんが、コミットされたハッシュだけですでにあなたは守られています。毒されたバージョンは、単にインストールされないのです。

小規模事業者。 依存関係の専門家はおらず予算も厳しいので、規律を作るのではなく買ってください。ホスティングとコードのプラットフォームがすでに提供する更新の自動化に頼り、アップグレードが安く済むよう少数の成熟したライブラリを好み、人員を配置せずに「影響を受けるか」に答えられるよう、パイプラインで無料のSBOMジェネレーターを使います。乏しい注意を、ライセンスのチェックと、十数行で自分で書ける些細なパッケージを採用しないことに使います。

大企業。 問題は多数のチームにわたる一貫性です。公共のエコシステムをミラーし、ライセンス、出所、バージョンの方針を一つの関門で徹底する共有の社内レジストリ、既定としての厳選された定番ライブラリの集合と、それ以外のための文書化された例外の経路。ビルドごとにSBOMを中央のストアに出力し、一つのクエリで資産全体の露出に答えられるようにし、調整されたアップグレードを自動のプルリクエストで展開し、依存関係の健全性を、リポジトリごとの偶然ではなく、測定され統治されるポートフォリオとして扱います。

政府。 調達規則と公的な説明責任があらゆることを形づくります。ベンダーに、すべてのリリースとともに機械可読なSBOMとSLSAに沿ったビルドの来歴を納品するよう求め、公共のインターネットへの直接の経路がないミラーから提供される承認済みソフトウェアのリストからのみ社内でインストールし、システムが十五年稼働しその間ずっとパッチ可能でなければならないかもしれないので、安定した保守と明確なライセンスを持つ依存関係を好みます。寿命の終わりの移行は、緊急ではなく意図して計画し、出荷されたあらゆる成果物を、監査人がソースまでたどれる記録を保ちます。

事例

スタートアップ。 6人のスタートアップは、フレームワーク、決済ライブラリ、そして一度も調べたことのない約900の推移的なパッケージの上に構築されたウェブアプリケーションを出荷します。プラットフォームチームは持てないので、自動化に頼ります。初日からコミットされたロックファイル、パッチリリースをまとめてテストが通ればマージする自動のアップデーター、そして積み上がったメジャーバージョンの上昇をレビューする月に一時間。依存関係を加えるための一段落のルールは、主に「退屈でよく保守されたライブラリを好み、小さなものは二度考える」です。人気のパッケージが侵害されたとき、コミットされたロックファイルのハッシュのおかげで、毒されたバージョンは単にインストールされず、彼らはそのインシデントを体験する代わりに記事で読みました。

大企業。 400のリポジトリを持つ銀行が、公共のエコシステムをミラーし、その関門で方針を徹底する社内パッケージレジストリを運用しています。厳選された定番ライブラリ、承認された一つのログのフレームワーク、一つのHTTPクライアント、一つのJSONパーサーが既定で、それ以外は文書化された例外を要します。インナーソースのモデルにより、どのチームもそれらの共有ライブラリに貢献でき、小さなプラットフォームグループがその健全性を所有します。調整されたアップグレードにより、セキュリティパッチが自動のプルリクエストで400のリポジトリ全体に数日で展開され、すべてのビルドがSBOMを中央のストアに出力します。重大な脆弱性が発表されたとき、彼らは一つのクエリを実行し、ニュースサイクルが終わる前に露出を知ります。

政府。 連邦機関が、大統領令14028にたどれる来歴とSBOMの要件のもとでソフトウェアを調達します。ベンダーは、すべてのリリースとともに機械可読なSBOMを納品し、SLSAフレームワークに沿ったビルドの来歴を示さなければならず、機関は各成果物が主張されたソースから来たことを検証できます。社内では、開発者は、公共のインターネットへの直接の経路がない社内ミラーから提供される承認済みソフトウェアのリストからのみインストールできます。長期の保守性が選択を駆動します。システムが十五年稼働し、その間ずっとパッチ可能でなければならないかもしれないので、安定した保守と明確なライセンスを持つ依存関係を好みます。構成要素が寿命の終わりに達したとき、緊急ではなく、計画された移行がそれを置き換えます。

ビジネスケース: 動機、ROI、TCO

依存関係の規律の見返りは、大半が、起こらなかった災害で測られます。コミットされたロックファイルと再現可能なビルドは、採用するコストがほぼゼロで、「自分のマシンでは動く」の欠陥と再現不能な本番のバグという種類全体を排除し、そのそれぞれがシニアエンジニアの時間を何日も燃やしえます。自動の更新の周期は、ロードマップを止めチームを疲弊させる、ときどきの数週間にわたる緊急のアップグレードを、小さくマージされた変更の安定した低いうなりに変えます。多くのリポジトリのポートフォリオ全体で、まれで巨大なものから頻繁で小さなものへのその転換は、エンジニアリング組織が使えるプロセスの変更の中で、最もてこの効くものの一つです。

総所有コストの議論は、今スプリントで使うものではなく、何年にもわたって背負うものについてです。管理されない依存関係は静かに積み上がります。書き直しなしにはもうアップグレードできない古いバージョン、誰も値付けしなかった法的リスクを生むライセンス、一つの必須のパッチが破壊的変更の連鎖を引き起こすほど絡まったグラフ。これをしないコストは、最悪のタイミング、セキュリティインシデントや監査や強制された移行のときに、何年もの先送りされた保守の請求書が利子つきで届く形で、一度にやってきます。リーダーシップに論拠を示すには、彼らの言葉で枠づけてください。再現可能なビルドはインシデントのコストを減らし、SBOMは脆弱性対応の時間を日から分に縮め、承認されたライブラリと来歴は、そうでなければ締め出される規制された契約や政府の契約への資格を保ちます。

アンチパターンと落とし穴

ロックファイルがない、あるいはコミットされていない: ビルドが毎回新しく解決されるため、何が出荷され何が壊れたかを誰も確実に再現できません。
本番で「latest」を浮動させる: レジストリがその分に提供したものが、レビューも追跡もされない自分のリリースになること。
強いられるまで更新しない: 何年ものずれが、脆弱性の圧力のもとで、一つの恐ろしい高リスクの緊急アップグレードに崩れ落ちること。
アップデートボット疲れ: まとめられていないプルリクエストの洪水が、緊急のものを含めてすべてを無視するようチームを訓練すること。
依存関係の乱立: 些細な機能のために反射的にパッケージを加え、保守できないグラフと広い攻撃面を育てること。
一覧がない: SBOMがなければ、「影響を受けるか」への答えは、リポジトリ全体にわたる何日もの手作業の考古学になります。
公共レジストリを盲目的に信頼する: 直接の取得は、障害、取り下げられたバージョン、依存関係の混乱、タイポスクワッティングにさらされること。
推移的な依存関係の無視: 名指ししたものだけを統治し、リスクの大半が一つ下に潜んでいること。
審査されないライセンス: 出荷の仕方と衝突するライセンスのコードを取り込み、監査や買収のときにようやく発見すること。

成熟度モデル

レベル1、開始: 依存関係は評価なしに自由に加えられます。コミットされたロックファイルはなく、ビルドは再現可能でなく、更新は強いられた緊急時にだけ行われ、ソフトウェアに何が入っているかを列挙できる人はいません。
レベル2、発展: 一部のチームはロックファイルをコミットして、ほぼ再現可能なビルドを得て、少しの自動化が更新のプルリクエストを開きますが、実践はリポジトリごとに一貫しません。ライセンスと推移的なリスクへの認識は非公式で、共有の方針も、一覧も、パッケージの出所の管理もありません。
レベル3、標準化: 実践は文書化され、組織全体で徹底されています。自動のアップデーターが適切なまとめ方で安定した周期で動き、ビルドはロックファイルから厳密にインストールし、ロックファイルとマニフェストが一致しないと失敗し、ビルドごとにSBOMが生成され、社内レジストリが出所とライセンスの方針を徹底し、新しい依存関係は、すべてのチームが適用する書面のチェックリストに照らして評価されます。
レベル4、管理: 依存関係の資産が、ベースラインに対してデータで測定され、制御されます。バージョンの遅れ(メジャーバージョンで一つ以上遅れている依存関係の数)、すべての成果物にわたって重大な脆弱性にパッチを当てるまでの平均時間、自動更新のマージ率、出荷されたビルドの割合としてのSBOMのカバレッジ、未解決のダイヤモンド衝突と方針の例外の数を追跡します。これらの指標がリリースをゲートし、労力をどこに使うかを導くので、アップグレードと是正は、最も声の大きい人ではなく証拠によって管理されます。
レベル5、オーケストレーション: 依存関係の管理は継続的に改善され、組織全体に統合されています。ビルドの来歴と証明書は捕捉され検証され、SBOMはポートフォリオ全体で問い合わせられて即座の脆弱性対応が可能で、調整されたアップグレードが多くのリポジトリに自動的に展開され、定番ライブラリは厳選されてインナーソース化され、システム全体はエコシステム、脅威、調達の義務づけの変化に応じて適応します。

議論のためのアイデア

小さなユーティリティを自分で書くことと、そのために依存関係を引き受けることの間の、チームにとって正しい境界線はどこですか。
バージョンの制約はどれだけゆるく、あるいはきつくあるべきで、その答えはアプリケーションと公開ライブラリで異なりますか。
低リスクのパッチの更新は、テストが通れば自動マージされるべきで、それを安全にするためにテストスイートには何が必要ですか。
社内のレジストリやミラーは、あなたの組織の規模とリスクの姿勢にとって、運用コストに見合いますか。
最大の制御のためにどの依存関係をベンダリングし、どれを公共のレジストリに任せるか、どう優先順位を付けますか。
出荷するすべての成果物についてSBOMを生成し実際に使うには、今四半期から始めて、何が必要ですか。

要点

ソフトウェアの大半は借り物のコードです。それをうまく管理することは、後付けではなく中核のエンジニアリングの規律です。
ロックファイルをコミットし、再現可能で決定的なビルドを求め、同じ入力が常に同じ出力を生むようにします。
まれで強いられる恐ろしい飛躍ではなく、小さな自動化された歩みで継続的に更新します。
書面の基準に照らして意図して依存関係を加えます。管理するのが最も安いのは、引き受けなかったものです。
SBOMを生成し来歴を捕捉して、ソフトウェアに何が入っていて、どこから来たかを常に知ります。
混乱、タイポスクワッティング、上流の障害から守るために、社内レジストリで出所を管理します。

参考文献とさらなる読み物

U.S. Executive Order 14028, Improving the Nation’s Cybersecurity (2021)
National Institute of Standards and Technology (NIST), Secure Software Development Framework (SP 800-218)
SLSA (Supply-chain Levels for Software Artifacts) framework specification, Open Source Security Foundation
OWASP CycloneDX specification and the SPDX specification, for SBOM formats
Tom Preston-Werner, Semantic Versioning Specification (SemVer)
The Reproducible Builds project documentation
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps