11/20に公開のWordPress4.01の脆弱性が発覚しましたが、WordPress使用した案件の脆弱性対応はみなさんどのように対応をしていますか？
皆さんの取り組み方をお聞かせ願いますでしょうか？よろしくお願いします。
WordPressという選択時点で、制作前には必ずこのようなオープンソースの脆弱性とサポートを確認しますので、何もしていませんし、するつもりもないです。
でも、クライアントはそんな事知ったこっちゃないと思うよ。絶対クレームの元になる。
ちゃんと伝えて書面も交わしてれば、クレームにもならないし、仮に来てもただのいちゃもんモンスターだから無視でOK。
モンスタークライアントは無視でOK
知ったこっちゃないって言うクライアントの事は知ったこっちゃない。永続的なサポートに関して明記していない限りは金払わないなら無視で良いかと、
そういうクライアントって損得よりも感情で動くから、サポート予算捻出すりゃ良いだけなのに、サポートをわざわざ余所の会社に投げて余計な予算をかけた上にノウハウも引き継がれなくて更なるトラブルを産む。以下ループ。
オープンソースを使う以上どんなクライアントに対してもリスクを明文化して、金かかる範囲、クレームのもとになりそうなことは事前に決めておくことが重要ですね。
結果的に、制作者側のお荷物にしかならないクライアントは、切るってのもありかもしれませんね。
でも、個人の方なんかは、そんなに強くも言えなくて、結局無償で対応している人多くないのかなと思ったりしますが、どうなんでしょう？
↑もちろんいるだろうさ。弱小フリーランスやなんの強みもない制作会社とかね。だからどうなんだ？そんなヤツらの苦労話や愚痴を聞きたいのか？
そういう弱小のところってそもそもバージョンアップを想定していないと思う。(想定してるんなら契約書に書くだろうし)バージョンアップしようにもプラグインが非対応になって収拾付かなくなって逃亡するしかないパターンと思われる。WordPressはそういう事がけっこうあるのが怖いな。
弱小にはそもそも契約書がねーんだぞっと。
SIerなら常識だろうけど、システムを納品する時には、納品までのプロセスで、要件定義書とか仕様書とか運用マニュアルとか、ドキュメントをわんさか作るのが当たり前なのよ。それは法務的なリスクヘッジの意味もあるし、納品物がソフトウェアってことは「モノ」じゃなくて「コト」を納品するわけで、その代替物としてドキュメントがあるの。例えばDTPの世界からなんとなくグラフィックデザインの延長でやってきてる人はそういう感覚って全くないから（自分もそうだった）いざインシデント発生ってなると責任の範疇が全くわからなくなって損をするのさ。あとWP使ってフリーランスやってる人は結構WPのソースコードも良く読まずにやっちゃってる人多いと思うから気をつけた方が良いよ。クライアントが法人で訴訟になったら高確率で借金背負うよ。
あと、前のコメントに誰かが知ったこっちゃないって書いてるけど、それはそもそもビジネスとしてアウトな考え方ですよ。後先が逆になろうが、そこはどうしますって定義して合意取らないと契約じゃないですよ。
一方でフリーランスに安易に頼むようなクライアントも、そういうのを「無駄な作業」って思ってるんだろうなと思う。
確かにその通りですね。私もDTP上がりの人間なので、そのあたりは正直疎いし、意識は薄いですね。
みんなの回答 2 件
WordPressという選択時点で、制作前には必ずこのようなオープンソースの脆弱性とサポートを確認しますので、何もしていませんし、するつもりもないです。
SIerなら常識だろうけど、システムを納品する時には、納品までのプロセスで、要件定義書とか仕様書とか運用マニュアルとか、ドキュメントをわんさか作るのが当たり前なのよ。
それは法務的なリスクヘッジの意味もあるし、納品物がソフトウェアってことは「モノ」じゃなくて「コト」を納品するわけで、その代替物としてドキュメントがあるの。
例えばDTPの世界からなんとなくグラフィックデザインの延長でやってきてる人はそういう感覚って全くないから（自分もそうだった）いざインシデント発生ってなると責任の範疇が全くわからなくなって損をするのさ。
あとWP使ってフリーランスやってる人は結構WPのソースコードも良く読まずにやっちゃってる人多いと思うから気をつけた方が良いよ。クライアントが法人で訴訟になったら高確率で借金背負うよ。
関連するトピックス