OSSの選び方：人気より更新・保守を引き受ける体制を確認する
必要な機能があり、利用例も多い。ライセンス費用を抑えられそうだ。こうして選んだオープンソースソフトウェアが、後になって「更新すると動かない」「修正を誰に頼むか決まっていない」という問題になることがある。
採用時には動くかどうかを試す。しかし、使い続ける条件まで試す機会は少ない。OSSを選ぶ判断では、人気や機能の比較に加え、修正が出たときに誰が適用し、出ないときにどうするかを決めておきたい。無料で入手できることと、継続利用の費用が要らないことを分けるためである。
この記事の目次
星の数からは、引受先が分からない
公開リポジトリの注目度やダウンロード数は、候補を探す手掛かりにはなる。ただし、今回の利用環境を支える約束ではない。よく使われる部品でも、自社の古い版が保守されるか、必要な機能が今後残るかは別に確かめる必要がある。
OpenSSF Scorecardは、コードレビューや保守など、ソフトウェア開発上の実践を自動チェックする仕組みである。導入判断を補助する情報として使えるが、点数だけで個別の利用に安全を保証するものではない。OpenSSF「Scorecard」
確認したいのは、総合点を順位表にすることより、点数の背後にある項目である。問題の報告先があるか、変更がレビューされるか、保守の形跡があるか。そして、その情報が自社の採用する版や配布物に対応しているかを見たい。
公開情報が少ない候補を直ちに危険と断定する必要はないが、確認できないことを確認済みとして扱う理由もない。とくに事業の重要な処理へ使う場合は、足りない情報を誰が補うかを採用の議論に含める。
「高得点ほど脆弱性が少ない」とは限らなかった
Zahanらの研究は、npmとPyPIのパッケージについて、Scorecardの項目と外部報告された脆弱性件数の関係をモデル化した。2023年改訂版では予測の説明力が低く、総合点が高いほど報告件数が少ないという単純な関係にもならなかった。Zahanほか「Do Software Security Practices Yield Fewer Vulnerabilities?」
これは、安全対策が無意味だと証明した研究ではない。数えているのは把握された脆弱性であり、潜在するすべての欠陥ではない。研究も報告データの不足や測定時点などの問題を論じている。対策が良いから欠陥が増える、という因果関係にはできない。
実務上は、総合点を合否の唯一の線にしないという読み方が妥当だろう。項目の確認は行い、別に、利用場所、扱う情報、更新できる構成、障害時の代替を確認する。開発プロセスの情報と、自社で使う際の条件は補い合うものとして扱う。
点数を項目へ戻すと、低い点にも別の理由が見えます。公式の説明では、自動検出がすべての実装を認識するわけではなく、例えば別の静的解析ツールを使っているため低得点になる可能性が示されています。対策がないのか、検出方法では見えないのかを、代わりの証拠で確かめます。 Scorecard公式チェック説明
この区別は、点数を都合よく無視するためではない。代わりの証拠を確認できたなら、その内容を採用記録へ残す。確認できなければ、不明のまま次の判断へ渡す。低い点数をすべて危険と決めることも、人気を理由にすべて問題なしとすることも避けられる。
同じように、研究で予測が弱かったことは、何も確認しなくてよい理由にはならない。自社の利用に直接関係する条件へ判断を近づける理由になる。更新が必要になったとき、担当者が何を実行できるかという問いは、候補全体のランキングより具体的に答えられる。
更新が少ない理由を、日付だけで決めない
変更頻度が低いと、保守が止まっているように見える。一方、役割が小さく安定した部品なら、新機能が少ないこと自体は不自然ではない。更新日の新しさだけで成熟と放置を区別することは難しい。
OpenSSFのチェック項目には保守状態を確認するための説明がある。こうした自動チェックを入口にし、必要なら、問題への応答、利用環境への対応、保守終了の告知など具体的な記録へ進む。Scorecard公式チェック項目
ここでの提案は、最近の機能追加を求めることではない。困った際に何が期待できるかを確認することだ。修正を待てる用途か、自分たちで修正する能力があるか、有償の支援が必要かによって、受け入れられる状態は変わる。
「ソースがあるので何とかなる」という説明にも具体性が要る。誰がコードを読み、変更を検証し、以後の更新を取り込むのか。その能力と時間を確保しないまま、将来の自社保守を無料の保険として数えない方がよい。
更新作業まで、最初の試行に入れる
導入試行では、一度動かして終えるのでなく、版を上げる際に何が必要かも確かめたい。依存する他の部品、設定の変更、業務の確認を含め、利用部門と運用担当の作業を見積もる。最新版へ変えること自体が目的ではなく、必要な変更を継続して適用できる状態を作るためである。
担当を置くときには、通知を読む人と更新を承認する人が違うこともある。問題を知っても決裁が止まるなら、監視だけでは対応できない。利用を続ける条件が崩れた際に、一時的な制限、代替、更新のどれを決めるかも明らかにする。
また、外部の支援を使えば責任が消えるわけではない。支援対象の版、対応範囲、応答の条件を確認し、自社側で残る検証や切替作業を把握する。OSSと商用の二択より、必要な保守をどの組合せで確保するかを考える方が具体的になる。
これらは研究が示した唯一の採用手順ではない。採用後に必要となる仕事を、機能比較から落とさないための編集上の判断枠組みである。
試作品で使えるものを、本番にも置けるか
以下は架空の例である。担当者が社外へ公開しない試作品で、限定したデータを整形する。取り替えも容易で、試行後に継続利用する予定はまだない。この場合は、用途と期間を限定した評価を選べる。採用を確定せず、機能を調べるための利用である。
同じ部品を、顧客の注文処理へ組み込むなら判断は変わる。更新の検証に時間が掛かり、停止時の代替もなく、保守の引受先も決まっていないなら、人気があっても本番採用を保留する理由になる。試作品で動いた事実は、この欠落を埋めない。
さらに、社内で更新を検証する環境があり、必要な支援と代替経路を確保できるなら、採用を再検討できる。候補の名称は同じでも、引き受けられる運用が変わったことで選択が逆転する。
この比較は、試作品なら何を使ってもよいという意味ではない。利用条件や扱う情報の確認は必要である。違いは、事業を止めずに使い続ける責任をどこまで負うかにある。
Scorecardの点数は、引き受ける作業へ翻訳して読む
低いチェック項目を、採用後に自社が補う作業へ対応させる。最終コミット日だけでは、完成した小さな仕様と放置された不具合を区別できないため、公開履歴や未処理の問題も見る。比較は同じ日時・版で行い、更新時の試験と保守停止時の修正を誰が引き受けるかを採用条件にする。
採用理由に、停止する条件も書く
採用記録には、機能を選んだ理由とともに、利用する範囲、更新担当、保守が維持されない場合の対応を短く残したい。担当が替わっても「なぜこれを使っているか」と「どこまで依存してよいか」が分かる形にする。
費用の比較でも、初期の入手費用だけでなく、検証、更新、障害対応、置換えの作業を並べる。将来費用を正確に予言する必要はないが、未計上の仕事をゼロと見なさないことはできる。
人気のOSSを避けるという提案ではない。人気は探索を助け、チェック項目は確認を助ける。最後の採用判断は、自社が必要な期間、必要な場所で支えられるかへ戻す。重要な処理なのに保守と更新の引受先がないなら、その欠落を解消してから採用する。この順序なら、無料という魅力を継続利用できる価値へつなげやすい。