オープンソースプロジェクトの脆弱性修正にかかる時間が 3 年間で倍以上に増加したとの調査結果 15
ストーリー by nagazou
大幅増 部門より
大幅増 部門より
headless 曰く、
Snyk が Linux Foundation の協力によりまとめた報告書「State of Open Source Security 2022」によると、オープンソースパッケージの依存関係によりソフトウェアサプライチェーンの複雑さが増し、脆弱性の修正にかかる時間が長くなる傾向がみられるそうだ(プレスリリース、 BetaNews の記事)。
オープンソースパッケージは現代的なアプリケーションで重要な要素となっており、開発者は数多くのオープンソースパッケージをプロジェクトで使用する。プロジェクトごとの直接的な依存関係は平均 80、最も多い JavaScript プロジェクトでは平均 174 まで増加する。依存関係は直接的なものだけでなく、推移的 (間接的) な依存関係もある。推移的依存関係は見えないリスクを生むだけでなく、修正も困難だ。脆弱性全体の 40 % が推移的依存関係で見つかっており、プロジェクトごとの平均的な脆弱性の数 49 に対し、18 ～ 20 が推移的依存関係から発生することになる。
その一方でオープンソースソフトウェア (OSS) の開発・利用に関するセキュリティポリシーを確立している組織は 49 %。組織内の OSS のセキュリティを信頼していないという回答は 41 % にのぼる。ただし、72% は 2022 年末までにある程度以上のセキュリティを確保できると回答しているという。オープンソースプロジェクトで脆弱性が修正されるまでの (平均) 時間は 2018 年の 49 日間から 2021 年には 110 日間まで増加しており、プロプライエタリプロジェクトよりも 18.75 ％ 長い時間を要するとのことだ。
放置されたスパゲッティの山 (スコア:0)
直す気すらないプロジェクトが増える一方
Re: (スコア:0)
IT企業が採用条件にOSS活動とか書くからな。
採用されたらやる意義がなくなる。時間もなくなるし。
利用者が直せ (スコア:0)
企業が使っている場合とか
フリーライドしないでパッチ送ればいい
Re: (スコア:0)
脆弱性を見つけた企業・人間にそれを直す義務は無いし直す能力があるとは限らない
Re: (スコア:0)
利用者は公開する義務もないしね。
Re: (スコア:0)
おまえにAGPLをお見舞いしてやる
Re: (スコア:0)
その分ただでティシュ配ったり色々やってるだろ。
Re: (スコア:0)
何回か送ったがいずれもいれてくれたな(いずれもセキュリティ関係ではなくバグフィックス
一つだけ半年以上かかったか
Re: (スコア:0)
やだよ。
最新版で起こるかどうか確認するのが面倒。
起こったとしても、最新版向けにパッチ作り直すのも面倒。
パッチ投げるのも面倒。
ここバグってんぞって言うだけですむぐらい手軽じゃないと、やる気起こらん。
Re: (スコア:0)
粘着質なメンテナーが幅を利かせていて、PRを投げようという気にもなれない
forkするとそっちにも口出ししてくる…
# よくあるマイナーOSS末期...
以前みた記事 (スコア:0)
https://mag.osdn.jp/22/02/15/171500 [mag.osdn.jp]
この記事と印象がまったく異なりますね。
Re:以前みた記事 (スコア:1)
Linuxという人が集まっている成功してるプロジェクトと、そうでないでないプロジェクトの差ですね。
目が無ければ放置されるし、手が無ければこれまた放置される。
Linuxだって手を入れるコスパが悪ければセキュリティバグを修正せず無効化で対処される [hardware.srad.jp]訳で。
Re: (スコア:0)
No1広告のように意図的な結果を誘導する調査方法が流行っているから
こういった話は真に受けないほうがいいでしょうね。
GitHubがね… (スコア:0)
どこかよく分からない企業に買収されて
実用性が皆無になったからね
脆弱性を修正しようにも、あれこれと面倒くさい事ばかり
Re: (スコア:0)
何処がダメになったのか具体的に言ってみろよ