SBOMを始めるならSCAも知り、DevSecOpsへと歩みを進めよう
SBOMにまつわる懸念もある。例えば「ソフトウェアに関する情報を全部さらすことにリスクはないのか？ 情報漏えいとならないのか？」がある。これについて横田氏は「ソースコードを公開するものではない」と指摘する。攻撃者にとってSBOMは頼りになる情報にはならず、SBOMを公開するかどうかも現状では任意となっている。
先にSBOMに関連するツールを挙げたが、それに近いものにSCA（ソフトウェアコンポジション解析）ツールもある。これはSBOMを作るかどうかに関係なく、ソフトウェアをスキャンして脆弱性やライセンス違反をチェックする。世の中にはさまざまなSCAツールがあり、CI/CD実行時にSCAも自動で行うように組み込むのが「基本」と横田氏は言う。
そのためSBOMを始めるにあたり、もしSCAが未着手であれば横田氏は「まずはSCAから」と勧める。SCAを使えば脆弱性診断で問題を見つけたとしても、ライブラリのバージョンを上げれば解決することも多い。脆弱性対策としてもSCAは頼もしい。
また横田氏は「SBOMの作成やSCAはソースコードではなく、成果物（アーティファクト）に実施するのが望ましい」と話す。理由として、アーティファクトは依存解決が済んでおり、ソースコードにない情報を持っているためと、またソフトウェアはビルドのたびに内容が変わる可能性があるためと説明する。
今日の話を聞いて「まだ遠い未来かな」と感じているのであれば、横田氏は「いつか必要になった時のために、せめてSBOMの存在を覚えていただけるとうれしい」と話す。SBOMはDevSecOps、つまり安全なソフトウェアを効率良く提供するために重要な要素となるからだ。開発者がソフトウェアの仕様や開発など本来やるべきことに専念できるようにするためにも、SBOMやSCAツールを取り入れることを検討してもいいだろう。
実際、横田氏も開発者時代は「セキュリティは苦手で、セキュリティ担当者を悩ませる存在だった」と明かす。「少しでもDevSecOpsを身近に感じてください」と横田氏は言う。
JFrogに2人目のデベロッパーアドボケイト、佐藤氏がジョイン
ここからは2022年6月にJFrogに2人目のデベロッパーアドボケイトとしてジョインした佐藤由久氏が加わり、横田氏と開発者の現場について対談した。佐藤氏はアプリケーション開発エンジニアやITコンサルタントなどを経験し、2017年に地元の山形にUターン。現在はリモートワークをしている。
セキュリティではなく開発メインの経験がある点では横田氏と同じ。開発者時代を振り返ると、要件定義を進めていく時に顧客からはセキュリティについての明確な条件はなく、ざっくりと「ちゃんとやってね」的な指示で終わる場合があった。そのため「これを守っていきます」と非機能要件をまとめて、提案していた。そうしたなかで役に立ったのがSCAのようなツールだったと佐藤氏は言う。
佐藤氏は「開発時にはアーティファクトを継続的に見て行くことが力になります。アーティファクトを管理し、リリース後も継続的にSCAツールなどでチェックをすることが重要です。こうした脆弱性をチェックするツールを使うことで、エンジニアの負荷を下げ、エンジニアが少しでもハッピーになるように、そして本当に力を割きたいところに力を割けるように、情報発信していこうと思います」とデベロッパーアドボケイトとしての抱負を述べた。
