オープンソースプロジェクトのセキュアビルドを作成し、メンテナーと収益を共有するサービス SecureBuild が、技術コミュニティから注目を集めている。しかし、必ずしも彼らが期待していた理由ではない。重要な脆弱性を修正するための6日間のサービスレベル合意（SLA）の約束が、今日の脅威環境における適切なセキュリティ対応時間とは何かについて激しい議論を巻き起こしている。
6日間 SLA 論争
重要な CVE 修正に対する同社の6日間のコミットメントは、批判の的となっている。コミュニティのセキュリティ専門家たちは、この期間が現代のセキュリティ基準を満たしているかどうかを疑問視している。一部の組織は重要な脆弱性パッチに48時間の制限を求めていると報告されており、 SecureBuild の約束は比較すると鈍重に見える。
しかし、現実はより複雑であるようだ。 SecureBuild は約束された6日間よりもはるかに早く修正を提供することを目指しているが、深い依存関係ツリーがパッチ適用プロセスを複雑にする場合があることを認めている。同社は最終的に対応時間をわずか6時間まで短縮するという野心的な計画を持っているが、この目標を達成するためのタイムラインは提供していない。
SecureBuild SLA タイムライン比較
- クリティカル CVE：6日間 SLA（目標：6時間）
- 高/中/低 CVE：13日間 SLA
- 業界期待値：クリティカル脆弱性については48時間
- 監査基準：クリティカル脆弱性について30日間を義務付けることが多い
CVE 対応戦略の再考
コミュニティディスカッションから特に鋭い批判が浮上し、すべての CVE を修正するために競争するというアプローチ全体に疑問を投げかけている。セキュリティ専門家たちは、組織は脆弱性を日数で追跡すべきではなく、代わりに実際の攻撃が野生で始まる前にパッチを適用することに焦点を当てるべきだと主張している。
「野生での積極的な悪用が始まる前にパッチを出す必要がある。それが重要な唯一の指標だ。」
この視点は、 SecureBuild や類似のサービスが間違った問題を解決している可能性があることを示唆している。すべての CVE に対して包括的な対応時間を約束するのではなく、実際に悪用されている脆弱性を特定し、それらに応じて優先順位を付けることに焦点を当てるべきである。
ビジネスモデルの現実チェック
技術的な議論を超えて、コミュニティメンバーは基本的なビジネス前提に疑問を投げかけている。ある観察者は、迅速な CVE 対応に基づいてセキュリティを構築する組織と、オープンソースプロジェクトを財政的に支援することに真に関心のある組織との間には、最小限の重複しかない可能性があると指摘した。
SecureBuild のリーダーシップはこの懐疑論に反発し、銀行や政府機関などの企業環境に商用ソフトウェアを配布する独立系ソフトウェアベンダー（ISV）の顧客基盤を指摘した。彼らは顧客のほぼ半数がオープンコア企業自体であると主張しており、オープンソースの持続可能性を支援したいセキュリティ意識の高い組織の市場が実際に存在することを示唆している。
収益分配モデル
- オープンソースメンテナー：サブスクリプション収益の70%
- SecureBuild ：サブスクリプション収益の30%
- サポート契約は不要
- プロジェクトからのコード変更は不要
今後の展望
この議論は、包括的な脆弱性管理と標的型脅威対応の間のセキュリティ業界におけるより広範な緊張を明らかにしている。 SecureBuild の70-30収益共有モデルがオープンソースメンテナーとの間で真の持続可能性の課題に対処している一方で、彼らのセキュリティアプローチは進化する業界の期待に応えるために改良が必要かもしれない。
組織がますます迅速な対応時間とより洗練された脅威の優先順位付けを要求する中、 SecureBuild のようなサービスは、複雑なソフトウェア依存関係の実際的な現実とセキュリティ脅威の真の性質とともに、野心的なタイムラインのバランスを取る必要がある。