JPCERT/CC脆弱性情報ハンドリング説明会開催

Anonymous Coward曰く、"JPCERT/CCが、「『オープンソースソフトウェアな人』限定! 脆弱性情報ハンドリング説明会」なるものを開催するそうだ(案内状: テキスト) (案内状: PDF)。
JPCERT/CCといえば、2004年から、ソフトウェアの脆弱性情報コーディネーションを業務として行うようになった。脆弱性情報のポータルサイトJVNの運営も、独立行政法人情報処理推進機構 セキュリティセンター(IPA/ISEC)と共同で行っており、インシデント対応よりも脆弱性情報コーディネーションに軸足を移しつつある感もある。
なお、「『オープンソースな人』限定」といいつつも、実際には「オープンソースソフトウェアの開発プロジェクトに携わる方、オープンソースソフトウェアのユーザコミュニティに関わる方、オープンソースソフトウェアをこよなく愛する方、ソースを公開してはないが個人でソフトウェア作って公開している方、ただ単に興味ある方、等々」とあるので、関心のある方は参加してみてはいかがだろうか。"

10月16日(日) 14:00～16:00、東京の住友不動産新宿オークタワーにて開催される。参加申し込みが必要。

要するに

[Technical Type (3408)]

オープンソースのコミュニティーも積極的に製品開発者に登録してくれって事じゃないかな。 でもJPCERT/CC 脆弱性関連情報取り扱いガイドライン [jpcert.or.jp]だけ見て、この通りにやればいいっていうならまだしも、こんなに沢山の関連するガイドラインを読んで理解して守れっていうので挫折するよね。おまけに、これらのガイドライン間で「矛盾が無く整合性が取れている」訳じゃないし。

• 経済産業省 「脆弱性関連情報取扱体制」 [meti.go.jp]
• 経済産業省 「情報セキュリティ早期警戒パートナーシップ」の運用開始について [meti.go.jp]
• IPA 情報セキュリティ早期警戒パートナーシップガイドラインの公表について [ipa.go.jp]
• IPA ソフトウエア等脆弱性関連情報に関する届出の受付開始について [ipa.go.jp]
• JEITA/JISA 「製品開発ベンダーにおける脆弱性情報取扱に関する体制と手順整備のためのガイドライン」 [jeita.or.jp]

とくにこの最後の奴を文字通り遵守しようなんて思ったら、100年経っても出来ないよ。

もし「そんなに杓子定規ではありません」と言うなら、JPCERT の方で IPA や JEITA 、JISA と話をつけて、もっと簡素化して一つにまとめて欲しい。もっとも、「ガイドラインだから守らなくてもいい」と言えばそれまでだけど、それを言ったら、製品開発者に登録する必要も無いし。

Re:要するに

[Anonymous Coward]

オープンソースのソフトウェアの脆弱性に関する通報を受けることがあり、
それを伝えて改善させるべく開発者に連絡を取ろうとしても、連絡先が
不明だったり、連絡しても無反応で無視されるというケースも多いらしい。

全てのオープンソースソフトがそうとは限らないが、開発がいい加減で
無責任に途中で捨てられるケースも多く、ユーザは脆弱性を抱えたまま
見捨てられる。

「オープンソースなのだから、必要であれば自分で直せ」という考えも
あるのかもしれないが、その能力がないユーザはコストをかけて直す
必要が出てきてしまい、それくらいなら有料で売っている製品を買った
ほうが良かったと後悔することもあるかもしれない。

そうならないよう、きちんとオープンソース開発者は責任を持てよ
ということだろう。
だから「オープンソースな人限定」なわけだ。

Re:要するに

[G7 (3009)]

>オープンソース開発者は責任を持てよ

無保証(T_T)
作者を「縛る」のは、どうもオープンソースには馴染まないような。

まあ、作者じゃなくても開発者が居ればイイんだろうとは思う。
つまり、オリジナル作者とは別に、責任とるのをショーバイにするような企業がもし現れれば
それも「開発者」だから。

>それくらいなら有料で売っている製品を買った
>ほうが良かったと後悔することもあるかもしれない。

乗り換え先がプロプラ有料なものばかりとは限らない、のかなとも思います。
別のオプソに乗り換えるという手も、(選択肢さえ有るならば)有りじゃないかな？

だから
「ぜんぶのオプソは責任とれ」じゃなく
「それぞれの分野(？)に少なくとも１つくらいは、責任とってくれる人のいるソフトが有ってくれ」
ってとこじゃないかなあ？
ターンAじゃなくターンEね。
実験志向な奴と品質志向な奴が併存してくれるといいなぁという。

＃実験志向なのでG7

>無反応

office氏と某Wikiの人とのやりとりを思いだしちまった…。

Re:要するに

[G7 (3009)]

>「ぜんぶのオプソは責任とれ」じゃなく
>「それぞれの分野(？)に少なくとも１つくらいは、責任とってくれる人のいるソフトが有ってくれ」
>ってとこじゃないかなあ？

>>無反応
>office氏と某Wikiの人とのやりとりを思いだしちまった…。

補足しておくと。
そのやりとりを見てると、どうも
office氏の目には、某Wikiの人が「反応」の足りない人として映ってしまった
ようだったなぁということです。

で、俺からoffice氏を見た印象は、
氏は「ぜんぶのオプソは責任とれ」系の要求をしてるよなあ、
というものだったわけです。

「ぜんぶのソフト(Openであるかどうかはこの場合あまり本質でないかも)」に
それを求めるのは、ちと辛いですね。
実験とか遊びとか(をも含めた「表現」全般)がやりにくいったら。

いっぽうoffice氏的には、どうも、
少なくともWebアプリは
全部「責任とれ」系でないとダメという解釈だったようで…。

あとたしか、IEの変な仕様だかバグだか(による脆弱性)を回避するために、
Wikiエンジン側が工夫せんとならん、
という論法も展開してたような気が。
MSがIEを直してくれるのが筋だろうとは(俺も)思うんだが、
office氏的には、普及しちまったもんのマズさには、周囲は対応しなきゃアカンってことらしい。

…辛いよ。

Re:要するに

[Technical Type (3408)]

> 連絡先が不明だったり

じゃ、開発者のWebに連絡先のメールアドレスが書いてあれば事足りますね。

> 連絡しても無反応で無視される

連絡して無視されたら、内容を公開すればいいのでは。

> きちんとオープンソース開発者は責任を持てよ

オープンソースは元々、自己責任で使う物かと思いますが。オープンソースを採用する際に、開発チームの過去の脆弱性の対応状況も知らないで使うのはどんなものかと。まさか、目先のコストや納期だけを考え、完成後に発見された脆弱性の対応方法も考えず、過去に脆弱性出しまくりとか、問題を連絡しても放置で悪評のあるオープンソースのプロジェクトの成果物をわざわざ採用して納品し、脆弱性が見つかってから「連絡が取れない」だの「責任を持て」とか、そういう事を言ってもねぇ。

Re:要するに

[Anonymous Coward]

＞じゃ、開発者のWebに連絡先のメールアドレスが書いてあれば事足りますね。

それがきちんと読んで反応してくれるメールアドレスであればね。
そうじゃないケースも多くて困るらしい。

＞オープンソースは元々、自己責任で使う物かと思いますが。

オープンソースに限らず、商用ソフトも含めて全てのソフトは
導入して使用するのは自己責任でなくてはいけないことは
同じでしょう。

＞オープンソースを採用する際に、開発チームの過去の脆弱性の対応状況も知らないで使うのはどんなものかと。

はて？
そこまで調査して特定のオープンソースを採用しているところって
あるんでしょうか？

＞

Re:要するに

[Anonymous Coward]

連絡先が 不明だったり、連絡しても無反応で無視されるというケースも多いらしい。

そういうのはさっさと事実関係を公表して、「もう使わない方がいい」という判断をできるようにしてくれないかな。

Re:要するに

[Anonymous Coward]

そりゃまた、一方的な意見だな。

試験日です

[herewe (21291)]

情報処理技術者試験の日程とかぶってますね…
誰かのレポートが公開されることを期待してます。

前から疑問だったんだけど

[Anonymous Coward]

JPCERTの存在意義ってどの程度あるんでしょうか？
CERTに比べてかなりいけてないような気がするんですが...


# どのくらいいけてないかというと、/. と /.J の違いぐらい