開発者向けのテストの生産性向上に取り組む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にアップデートしていかないと使えなかったというのがその一因だそうだ。このアップデートが終わってから大量に溜まったライブラリをアップデートしていくことになるが、「そうすると色々壊れる」(川口氏)ことになる。