ソフトウェアデザイン 2019年11月号の特集2が脆弱性スキャナ Vuls/Trivy/Dockleとのことでしたので早速購入してみました。
使い方の説明もありますが、私としてはそれぞれのOSS作者の開発秘話のような話が聞けてとても面白かったです。
自分もOSSへコミットしてみたり、開発してみようかなと、読んでいてとてもモチベーションが上がる内容になっています。
概要
ソフトウェアデザイン 2019年11月号の特集2「脆弱性スキャナ Vuls/Trivy/Dockle」というタイトルですが、サブタイトルが「OSSを公開したら人生が変わった3人の開発者」となっており、サブタイトル通りに3人(神戸さん、福田さん、天地さん)の人生がOSSを通してどう変わっていったのかが感じられるものになっています。
全部で4章(21ページ分)あり、Vuls/Trivy/Dockleの使い方、何ができるのかといった説明と作成者がOSSを作成するにあたっての秘話なども書かれています。
第1章 脆弱性スキャナの効果と威力
この章では脆弱性を管理することの大変さと重要性について語られています。
WebLogicの脆弱性(CVE-2018-2628)を例に世の中に公開されてからPoCが公開され、実際に攻撃に使われ始めるまでに時間が短いケースがある、という注意喚起がされ、Vulsのような脆弱性スキャンツールで手間をかけずに脆弱性管理を行う重要性が語られています。
WebLogicの脆弱性は特に中国で監視されており、脆弱性が発表されるとすぐに中国からの攻撃が観測される、との話を聞いたことがあります。
WebLogicの脆弱性を突かれると影響も大きいと思いますので早い対応が必要になり、素早い対応をするためにもVulsのような脆弱性スキャンツールを使い、常に監視をするというのが確かに重要だと思います。
(参考) NTT DATA Oracle WebLogic Serverに含まれるリモートコード実行に関する脆弱性（CVE-2018-2628）についての検証レポート
CVE-2018-2628に関する詳しい解説が乗っています。
NTT DATAによる観測でもPoC公開直後に攻撃が観測され、攻撃の送信元も中国が半数以上に占めています。
第2章 脆弱性検知はVulsに任せろ
VulsをAWS のEC2上で構築する際の方法がコマンドと共に書かれています。
コマンドの通り実行することで構築、スキャンができるので初心者にも優しい内容になっています。
もちろん、VulsのTutorialも公開されているのでこちらをみてもVulsの構築は可能だと思います。
しかし、使い方だけではなくスキャン結果のどの部分を特に気にしてみた方が良いのか、ざっくりどんな機能がありどう扱えばよいのかを理解するためにはこの第2章の部分はとても参考になる。
また、神戸さんがネパールにバックパックで旅行に行ったことをきっかけにOSSによる世界平和を悟り、Vulsの開発を自宅に引きこもり行ったという話は強烈です。
分量がかなりありますが、詳しいインタビュー記事を参考に載せておきます。
私としては第2章の章末にある福田さんによる「COLUMN Vulsとの出会い」がとてもよかった。
セキュリティエンジニアとして何か尖ったものを持ちたいと思っていたが全力で取り組める「何か」が見つからなかったが、Vulsに出会い、神戸さんに出会ったことで心のモヤモヤが晴れた。
この部分はぜひ読んで欲しい部分です。
第3章 コンテナの安全性を測る Trivy/Dockle
この章でははじめに福田さんがTrivyを開発した経緯が書かれています。
コンテナの脆弱性スキャナはTrivyを開発する以前からありましたが、どのツールもセットアップが面倒だったり開発者にとって使いやすいものでなく、改善点を多く感じていたことがきっかけだそうです。
次にTrivyとDockleのセットアップ方法、簡単な実行方法について書かれています。
私はTrivyをDockerの脆弱性スキャナとだけの認識でしたが、以下のコンテナ内のパッケージ管理ファイルを見つけ、脆弱性の特定を行うようです。
- Gemfile.lock (Ruby)
- Pipfile.lock (pip, python)
- poetry.lock (python)
- composer.lock (php)
- package-lock.json (node.js)
- yarn.lock (node.js)
- Cargo.lock (Rust)
これらのファイルを使って利用しているライブラリの名前、バージョンを特定し、外部の脆弱性DBを使って脆弱性の特定を行っているようです。
本誌の中で印象的だったのは
開発をしているとどうしても機能をいろいろと追加したくなりますが、OSSではその機能を開発する期間よりもメンテナンスをしていく期間の方が長くなることが多いです。
多機能にしてしまうと、将来のメンテナンスコストを増大してしまいます。
なるべく機能を少なく保つことでツールとしてのコアな機能に集中できると考えているため、今後も本体の機能はシンプルに保ちたいと思います。
どうしても多くの機能を追加したくなるところですが、その後の運用まで考えるとシンプルであることも必要です。
(言われれば当たり前のように感じますが、なかなか難しい)
第4章 開発者が語るOSSのインパクト
この章が一番面白くおすすめの部分です。
Vulsの作者の神戸さん、Trivyの作者の福田さん、Dockleの作者の天地さんによるOSSの開発し始めの話やOSSの開発を通してどう変わったのかについて書かれています。
3人ともタイプの違う人たちのため、読んだそれぞれの人の立場によって感じ方や共感できる部分が変わりそうだと感じています。
読んでいて多くの方のモチベーションが上がると思います。
OSSに貢献する、開発するというのはかなりハードルが高いと私自身も思いますが、天地さんはエンジニア歴が短く、元々は看護師やゲームプロデューサをされていた方のようです。
そのような方もチャレンジをしてVulsへのコミットやDockleの開発まで行えるようになっていたという話を聞くと自分もやってみようかな、と思えるのではないでしょうか。
また、Trivyの開発者の福田さんは、イスラエルのAqua Security Softwareというスタートアップに買収され、Aquaで働くことになる、という話はとても印象的です。
詳しい話は福田さんのブログに載っています。
ブログに載っていない現在イスラエルで何をしているのかも書かれていますのでその部分も面白いです。
こちら(opensource.tokyo)の福田さんへのインタビュー記事もとても面白いです。
Trivyの開発経緯から買収までの話に加えて、OSS開発に関する考え方 (READMEを作り込む、あえて自分で直さずに誰かに修正してもらう、スターを押すだけでもいい「貢献」から始める、など) も書かれています。
全体通しての感想
どの人も自分が現場で感じた改善点をツールを自作してより良くしていった、という共通点があります。
福田さんのColumnにも書いてありますが、自動化のためのちょっとしたツールを開発したとしても自分以外の人が利用できるほどの完成度の高いものではなかったりします。
その時に肩肘を張らずに完成度が高くなくてもOSSとして公開してみたり、他の人に使ってもらえるように共有してみることが重要で、それがあったからこそ今に繋がっているのだと思います。
また、福田さんも天地さんもVulsの作者の神戸さんと出会ったことがきっかけとなっています。
誰かとの出会いなどの小さなきっかけで人生が大きく変わることもあると思います。
そのためにも自分にとって小さなチャレンジでも良いのでどこかのイベントに参加したり、Twitterやブログでコメントをするでも良いと思いますので、何かを新しく行動をする、というのが大きな変化に繋がると私は思います。
ソフトウェアデザイン 2019年12月号 「サーバーレスでめざせ! インフラ管理ゼロなシステム」「PHPプログラミング・アラカルト」
Twitter アカウント
