【Web】【フリーランス】も知っておきたい脆弱性対応について
Webアプリケーションのライブラリバージョンを長らく放置していることはないでしょうか？
今回は、フリーランスとしても社会人としても考えるべき脆弱性とリスクについてお話しします。
脆弱性とは
脆弱性（ぜいじゃくせい）は、英語の vulnerability の日本語訳である。この分野での意味は「 弱点 」であり、セキュリティホール（安全性欠陥）と類似している。ただし、セキュリティホールがより具体的な欠陥を指す傾向があるのに対して、脆弱性は欠陥だけではなく、たとえ意図した（要求仕様どおりの）動作であっても、攻撃に対して弱ければ、つまり「弱点」があれば用いるという点が異なる。
システムに弱点があり、外部からの攻撃を受けやすい状態です。いわゆる欠陥です。
例えばWebアプリであればライブラリを使うことが非常に多いです。 PHPならcomposer、node.jsならpackage.jsonに大量にライブラリが書かれていないでしょうか。 これらのライブラリにも脆弱性のリスクを負うものが入っていたりします。
脆弱性は発見された時に影響があるわけではありませんが、今後影響してくる、あるいは影響を受けているというリスクをはらんでします。
リスクには大きく４つの選択肢があることを理解しておきましょう。
どれも聞いてみると確かにこれは意識しておく必要があるなというものです。
知っているのと知っていないのでは考え方や動き方も違うので常に意識するようにしましょう。
事例
event-streamのような様々なライブラリが依存しているパッケージでさえ、不正なソースが混入することがあります。
他にも調べたら無限に出てきますが、会社が倒産するほどの損失が起きることもあり得ます。 十分に理解しておきましょう。
対応について
脆弱性を調べられる環境を整える
脆弱性は日々すごい勢いで発見されています。日常的に知るために常にアンテナを貼ることが大事です。
脆弱性の情報を載せてくれるサイトはたくさんあります。
自分のシステムにあった情報を収集するようにしましょう。調べるとセキュリティを扱っている記事は出てきます。
例：
他にも脆弱性の警告を受けたnpmパッケージを出してくれる
npm audit
のようなものも存在します。
発見されたものが致命的な場合もあるため、できるだけ検知できるように心がけることが大事です。
脆弱性があることを知る
情報収集の中から該当のものがシステムで利用されているかを確認します。 内容を確認し、影響が判断できるレベル、あるいはエンジニア以外のステークホルダーまで説明できるようにしましょう。
対応の方針検討、実施
収集した情報からどの程度影響があるのか調査し、内容に合わせた対応方針を決定し、それらを実施(対応)していきます。
脆弱性があっても許容せざるを得ないものもあったりします。
例えば、社内のみで公開しているアプリケーションがあった場合に、アプリケーション経路から攻撃される脆弱性が見つかった場合
緊急性はそこまで高くないとして判断することもできます。(許容)
また、ライブラリ側で致命的で改善する見込みのないものであれば代替する方法を考えたりする必要もあります。
場合によっては法的に問題が出るケースもあるかもしれないのでエンジニア以外のステークホルダーを巻き込むケースもあります。
このように確認する量、対応難易度、判断力を要するので対策を考えるチームを作り、いつでも対応できるようにしておくことが大事です。
それ以外のリスク
バージョンを定期的にあげないとそれ以外に起こる障害もあります。
例えば、ライブラリや公式がEOLを発表した際にバージョンを最新に上げなくては...!
なんてことがあったとします。
保証が切られているので当然脆弱性の話題も上がってきづらいです。
そうなった時に、いざ2.x → 5.xにあげようとしても完全に互換性が保たれておらず移行に非常に苦戦を強いられることも少なくありません。
放置しすぎると自分が苦しむことにもなります。
