はじめに
こんにちは、かをるです。
一週間前の先月10月29・30日、情報セキュリティ国際会議CODE BLUE 2019（https://codeblue.jp/2019/）に参加していました。
今年の会場はハロウィンでなにかと話題の渋谷です🎃。
とてもホットだったCODE BLUE 2019のわたし的参加レポート、2本立てでお送りします。
当日受付をすませると、映画のパンフレットのような立派な冊子をいただきました！
まずは前編としてMain Track より「ソフトウェアサプライチェーンの透明性: SBOMの実現」の講演レポートです。
ソフトウェアサプライチェーンの透明性: SBOMの実現（Transparency in the Software Supply Chain: Making SBOM a Reality）
講演について
成分を知らずにキャンディを買うことはできないように、ナットやボルトの仕組みを知らずに機械を組み立てたり、売ることはできない。しかし、サプライチェーンの不確実性が情報セキュリティリスクのトップとなったものの、ネットワーク上のソフトウェアにおいてサードパーティ・コンポーネントに対する視野は限定されており、ソフトウェアサプライヤーがサードパーティへの依存性を追跡するインセンティブは少ないと言わざるを得ない。すべてのサプライチェーンリスクをすべて解決する方法は存在しないが、解決策はやはり透明性から始まる。 本講演ではソフトウェアサプライチェーン業界全体でサードパーティ・コンポーネントの使用を共有する慣行に関するコンセンサスを見いだす、オープンで国際的な取り組みについて紹介する。ステークホルダは、ソフトウェアやソフトウェアベースの設備を作成、購入、使用する人たちへのセキュリティと品質の両方をいかに改善するかを文書化し、MVP（実用最小限の製品： minimum viable product）の基本を組み上げ、データ形式をレビューし、医療機器部門で概念実証を行った。今後、アウェアネスと実用の促進のため、さらなる積極的な参加やコミュニティの賛同と、共に立ち向かうための課題の特定が必要である。*1
アラン博士は
「あなたは上司から、そのシステムに脆弱性があるかどうか質問されたとします。答えられない。これってとてもクレイジーなことではありませんか？」 「お店に行ってキャンディを買う。食品に含まれている成分をアレルギーを持っているなら知りたいと思うでしょう。」
のように話されていました（意訳）。
SBOMはSoftware BOMのことで、BOMはbill of materials、部品表。ソフトウェアの部品表です。 ソフトウェアも製品のように、どういったコンポート（OSやTCO/IPスタックなど、OSSも含まれる。）で作成されたかを明らかにするものです。
SBOMは2つのフォーマットから構成されています。 世の中にSBOMが普及する方法として「市場が要求する」「規制する（政府の仕事）」の観点でも述べられていました。
また、アメリカの銀行においてはもうSBOMをソフトウェア企業に要請している例も取り上げられ 「SBOMをつくれないということは、ソフトウェアも作れないということだ。10-20%の減額を要求されるだろう。」*2とのことでした。
新鮮な材料をつかっているのか、有機なのか、地産地消なのか。 そんな風に、OSは最新版か、EOLはどうなのか、メンテナンスがいるのかどうかが、SBOMがあることによってわかりますし、 わかっているということは、パッチが来るのを待つ時間があったり、脆弱性が発見されたときに場当たり的な対応ではなく、なんらかの軽減策が取れる、ということでした。 そして、医療機器部門の実証実験の具体的なところと今後の展望について述べられて、講演は終了となりました。
私がこのセッションを詳しく取り上げたいと思った理由
私がこのセッションに興味を持ち、詳しく取り上げたい🌟と思った理由は、目から鱗といいますか、非常に納得したと同時に、他の分野で当たり前に利用されている仕組みを取り入れて、よりよいサービスを提供できないだろうか？と考えたからです。
現在、私はWebアプリケーションの脆弱性診断に携わっており、ブラックボックステストと呼ばれる手法で診断を行なっています。
当然、個々のアプリケーションごとに仕様が異なるため、発見した不具合がただのバグなのか脆弱性なのか判断に揺れることもしばしばです。 以前脆弱性診断における「ロール」を考慮したアカウントや「データ」の準備について - SSTエンジニアブログという記事を書いたのですが、経験則ベースでこの記事を書いたように、お客様から頂いたロールやデータ（に限らず、そのほか情報）が必要十分を満たすかどうかを定量的に判断する手法は私の知る限りではありません。
SBOMというフォーマットがあることでソフトウェアの透明性が確保され、脆弱性の発見や対処がしやすくなるのであれば、ブラックボックステストにおいても、SBOMに準じるデータ様式のようなものがあれば、言葉通りのブラックボックスの暗中模索より、よりよい診断サービスの手がかりになるのではないのだろうかと考えたからです。もっというのであれば、その先にあるよりよいサービスや手法の提案ができればいいなと考えました。
サイバーセキュリティの分野もですが、広く社会にで活用されている様々な手法や概念についても知識を深め、何らかの方法で引き続きよりよいサービス提供に貢献できればと思いました。
そして、アラン博士も講演で述べられていた「人の手だとミスがでるからルーチン化しよう」。 もっと、ルーチンにできる部分はルーチンにしてしまいたいですね。
前編のおわりに
後編ではイベントそのものについての詳細なレポートをお伝えしたいと思っています。
注釈
*1:https://codeblue.jp/2019/talks/?content=talks_19
*2:CODE BLUE終了後、もう少し調べていたところ、アラン博士がお話されているPodcastを見つけました。Podcastの冒頭においてもこのお話をされていましたので、参考までリンクします。https://www.devsecopsdays.com/devsecops-podcast-gallery/podcasts/what-is-an-sbom-and-why-should-you-care