ソフトウェアのセキュリティ対策は何をすべきか
今回のテーマはDevSecOpsとSBOM。前者のDevSecOpsは今回のデブサミでも多く取りあげられるほど馴染みが出てきた。DevとOps、開発と運用が協力するDevOpsにセキュリティ（Sec）も組み込んでいこうという考えだ。
協力や協業と言うのは簡単だが、実際はそう簡単ではない。横田氏は「全員が全部できるようになる必要はありません。まずは丸投げしないこと。理解し合うこと。そうして少しずつ、お互いに手を広げていくのが理想」と話す。
そしてセキュリティと言っても幅広い。アセット、データ、アプリケーション、ネットワークなどから人間まで、7層に分けて考えられることもある。その中でDevSecOpsのセキュリティに該当するのはソフトウェアに関連するもの。
このソフトウェアのセキュリティを考えると、これまたランサムウェア、フィッシング、SQLインジェクション、ゼロデイ攻撃などキーワードが出てくる。またサイバー攻撃と言うと暗闇でパーカーを着た怪しい人物がノートパソコンを操作しながら特定の組織を攻撃しているイメージ図がよく使われる。
「実は、こんなに単純ではない」と横田氏は指摘する。最近よく言われるサプライチェーン攻撃だと、ソフトウェアに不正なプログラムやバックドアを仕込んだり、あるいは大企業とつながりのある企業から攻撃して大企業にダメージを与えるようにしたり。ソフトウェアが連鎖しているという性質を悪用して攻撃する。また、攻撃対象は企業のサーバーだけではなく、クルマや家電まで広がっている。
サプライチェーン攻撃と言うと、2020年12月に起きたSolarWindsが挙げられる。ソフトウェア更新が悪用されたため、アメリカ政府も含めて大規模に拡散された。最近2021年12月にLog4Jで発見された脆弱性も記憶に新しい。「対応に追われた方もいるのではないでしょうか。こうした事例からも分かるように、今やセキュリティ対策は手の届く範囲だけでは足りません」と横田氏は警笛を鳴らす。
「手の届く範囲」とは、主に自分が書いたコードを指す。今やソフトウェアは自社で書いたコードだけでは成り立たず、OSSなど外部から入手したライブラリなども含まれる。そのためこうした外部のコードにも対策を講じる必要がある。一般的にプロプライエタリなソフトウェアの6〜8割はOSSとも言われている。
では実際に脆弱性が発見されるなど、問題が生じた時に自社ソフトウェアが大丈夫かすぐ分かる状態にあるだろうか。どのソフトウェアがどのコンポーネントを使っているか把握できるだろうか。さすがに全てを記憶できないので、すぐ調べられるようになっているだろうか。
「ソフトウェアのコンポーネントなら、ライブラリのパッケージマネージャーで使うライブラリ名とバージョンを見ればいいのでは？」と思うかもしれないが、「それだけでは足りない」と横田氏は言う。ソフトウェアは連鎖的に依存しているので、依存先の依存先、推移的依存関係も安全性を確認する必要がある。
これからソフトウェアの脆弱性の確認に欠かせないSBOMとは
複雑に絡み合うソフトウェアの中で、発見された脆弱性が自社に影響を及ぼすのかどうか。その解決策となるのが、今日のテーマとなるSBOM（Software Bill Of Materials：ソフトウェア部品表）だ。「エスボム」という響きから武器や攻撃のようにも思えるが、そうではない。
ソフトウェアを構成するコンポーネントとメタデータの一覧になる。ここで言うコンポーネントとはソフトウェアが依存・使用するOSSやサードパーティのライブラリ、ソフトウェアが使うアドオン・プラグイン・拡張機能、プロプライエタリなコード、SaaSならAPIやサードパーティのサービスが含まれる。こうしたコンポーネントについてサプライヤー・バージョン・識別キー、依存関係、当該のSBOM作成者やタイムスタンプなども記される。
サンプルは下図のようになる。SPDX、SWID、CycloneDXなどフォーマットは数種類あるものの、基本的にはJSON、YAML、XMLなどのテキストファイルで標準化が進んでいる。人間にも機械にも読めて、自動化に使える。
ソフトウェアのコンポーネントが標準的な形式で一覧になっているということは、資産管理、ライセンス・コンプライアンス管理、知的財産管理、脆弱性管理など、ソフトウェアの安全性の確認や保証に役立つ。こうした一覧があることでLog4Jのような脆弱性が発見されても、SBOMを見れば影響があるかどうかすぐに確認できる。
このSBOMは2021年5月にアメリカが大統領令を出すほど、急速に重要性が高まっている。背景にはSolarWindsの件があるとされる。今後はアメリカ政府と取引がある組織はSBOMの作成が義務となる。日本でも自動車業界で活用が始まっている。
ソフトウェアの資産管理と考えれば、既に似たようなことを実践している現場もあるだろう。ただし自社独自のものだと、危うさもある。例えばExcelに手動で書き起こし、あるいは人力で確認していないだろうか。
SBOM管理のベストプラクティスとしては、一貫して同じフォーマットで管理し続けること、ツールで自動化すること、リリースのたびに更新すること、メタデータも合わせて保持すること。もちろんSaaSも対象になる。
SBOM作成で欠かせないのがSCA（ソフトウェアコンポジション解析）。ソフトウェアをスキャンして構成、脆弱性、ライセンス違反などを確認する。JFrog Xrayはじめツールが各種出ており、CI/CDに組み込んで使えばDevSecOpsの実現に貢献する。
「これでソフトウェアのセキュリティはバッチリ！」とはならないのが現実。セキュリティの世界（安全であること）には決して終わりはない。ソフトウェアのセキュリティ対策にはSCAだけではなく、脅威モデリング、静的アプリケーションセキュリティテスト（SAST）、動的アプリケーションセキュリティテスト（DAST）、ファジング、ペネトレーションテストなどがある。DevSecOpsを考えていくには、こうしたセキュリティ対策をソフトウェア開発ライフサイクルに組み込む必要がある。
上図を見ると、やることは山ほどある。「どこから始めれば？」と戸惑ってしまうだろう。横田氏は「まずは脆弱性診断から」と挙げる。とはいえ脆弱性診断なら既に導入しているところは多いだろう。次のステップとして横田氏が推すのがSCAツールの導入だ。無料のツールもあるので、敷居はそう高くない。横田氏は「脆弱性診断にDASTとSCAが備われば、ひとまず自分が書いたコードも取得したコードもカバーできるので、とてもおすすめです」と言う。
「何よりも関心がないのが一番危ない」と横田氏は自戒を込めて言う。横田氏自身、アプリケーション開発をしていたころは「開発そのものや機能要件を作り込むことが『いいものを作る』行為だと認識していました。セキュリティ対策は『分からないけど、やらなくちゃいけないもの』で、難しくて怖かった」と話す。こうした思いが積み重なり、壁を作っていくのだろう。
今では横田氏は「開発したものは安全に届けて、その後も安全に運用しなくてはなりません。機能がどんなに優れていてもセキュリティがザルなら、そのプロダクトの価値は落ちてしまいます。セキュリティ担当も一緒にものづくりをする仲間です」と考えている。難しいと思えたセキュリティも、分解していけば理解できるようになる。
少しずつステップアップして行こう。周囲の仲間が話題にしているトピックでもいいし、自分に関係した脆弱性について、より深く調べてみるのもいい。このセッションを通じて「ソフトウェアのセキュリティ対策にはこんなものがあるんだ」「今まで手動でやっていたけど、自動ツールがあるんだ」など発見があったのではないだろうか。
横田氏は「将来の備えとして、SBOM活用をご検討ください」と呼びかける。10年後にはSBOMが当たり前になっているかもしれない。
なお、JFrogは2021年にIoTデバイスの自動解析に強いVdooを買収した。横田氏は「JFrogには既にXrayがありますが、VdooにはソフトウェアのみならずIoTに強い製品がありますので、組み合わせることでよりセキュリティ対策にプラスになっていくと思います。ぜひご期待ください」と述べてセッションを締めた。
「6つの障害 DevOpsの成功に向けて」（EBOOK）
スピーディなリリースを阻む6つの障害はソフトウェア・デリバリー・パイプラインで直面する典型的なものです。ぜひ、本書「6つの障害 DevOpsの成功に向けて」をご覧ください。
