FFS原則 - ソフトウェア保守のトリレンマ

ソフトウェアを長く運用していると、誰もが次の三つを同時に望みたくなります。

• Freeze: バージョンアップしたくない(塩漬けにしたい)
• Free: お金を払いたくない
• Secure: 脆弱性は受け入れたくない

しかし、この三つは同時には成り立ちません。CAP定理になぞらえて、これを FFS原則 と呼ぶことにします。

なぜ両立しないのか

脆弱性修正は、基本的にアップストリームの現行バージョンにしか提供されません。古いバージョンへバックポートするには、誰かが手を動かす必要があり、その分のコストが必ず発生します。

コストを払う主体は、次の三つしかありません。

1. ベンダー — 対価としてサポート契約料を要求します(Red Hat ELS、Ubuntu Pro、Tanzu Spring Essentials など)
2. 自社のエンジニア — 工数というかたちで内部コストを払います
3. 誰でもない — 結果として脆弱性は放置されます

「タダで古いバージョンの脆弱性が勝手に直る」は原理的に起こりません。

三つの選択肢

いちばん危険なのは「無自覚な塩漬け」

明示的に選んでいないのに Freeze + Free に陥っているケースが現場では一番多く、これは暗黙のうちに Secure を捨てている状態です。

「自覚して Freeze + Free を選んでいる」のであれば、ネットワーク隔離や WAF などの代替コントロールを検討できます。自覚がなければ、何の対策も打たれません。

次に「このバージョン、まだ上げなくていいですよね?」と聞かれたら、こう問い直してみてください。

私たちは F・F・S のうち、どれを捨てる決断をしているのか?

答えが出てこないなら、それは決断ではなく、ただの先送りです。