筆者はDevSecOps及びソフトウェアサプライチェーンに関する最新のセキュリティ動向や製品情報の収集を目的に、RSAカンファレンス2023に参加した。
＜関連記事＞
RSAカンファレンス2023 現地レポート｜テーマは「Stronger Together」
RSAカンファレンス2023現地レポート②｜急速な進化を遂げるAIとクラウド、サイバーセキュリティ上の課題とは？
RSAカンファレンス2023現地レポート③｜新しいサイバーセキュリティ経営のあり方
DevSecOpsとは、開発（Development）と運用（Operation）が協調してソフトウェア開発を行うDevOpsという開発手法にセキュリティ（Security）を組み込んだ開発手法である（図1）。
図１. DevSecOpsにおける開発のライフサイクル
DevOpsでは、開発チームと運用チームが一体となることで、迅速な開発を行うことが主な目的の一つであったが、その結果従来型のプロセスでセキュリティを担保する事が難しいという問題があった。DevSecOpsは、DevOpsに統合されるセキュリティの実現を目指すことで、柔軟で迅速かつ安全な開発を行うための開発プロセスである。
RSA Conferenceにおいては、DevSecOpsは過去何年にもわたって取り沙汰されてきたテーマの一つである。今年度のカンファレンスでも、およそ一日に渡って開かれる基調講演や多くのセッションがあり、DevSecOpsは盤石な一大トピックとなっていると感じた。ここまでの期間にDevSecOpsの導入に挑戦した企業も徐々に現れてきたためか、セッションの内容は、新しいトピック――クラウド導入や後述するソフトウェアサプライチェーンなど――に関するものの他では、体制・ツールの構築や文化醸成にまつわるベストプラクティスの紹介など実践のためにどうすればよいかの話題に関するものが多かった印象だ。
また、安全な開発という観点において、近年特に注目を集めているのがソフトウェアサプライチェーンである。
ソフトウェアサプライチェーンとは、ソフトウェア開発ライフサイクル（SDLC）において、ソフトウェアが提供されるまでの、各種要素や依存関係を含めた一連の流れの事を指す言葉である。
2020年に発生したSolarWinds社のビルドプロセスへの不正コード侵害や2021年に報告されたオープンソースソフトウェアlog4jの深刻な脆弱性等により、ソフトウェアサプライチェーンに潜む様々なリスクやそのマネジメントの重要性について、ソフトウェア開発に携わるものであればより一層意識するべき問題として表出した（図2）。
図2. ソフトウェアサプライチェーンにおける様々なリスク
こうした背景から、ソフトウェアサプライチェーンは昨年度のカンファレンスで最も注目されたトピックであったが、今年度も昨年度に引き続き最重要トピックの一つであることに変わりはないと言えるだろう。トラックセッションの数が多かったのはもちろんの事、ソフトウェアサプライチェーンに関連する製品説明を行っている出展企業も30社を超えていた。
本ブログでは、DevSecOps及びソフトウェアサプライチェーンに関して筆者が聴講した、トラックセッションについていくつか紹介しようと思う。
▶「企業における情報セキュリティ実態調査」をダウンロードする
DevSecOps
DevOps is Now DevSecOps
講演者：
Mike Rothman (Chief Strategy Officer, Techstrong Group)概要：
リサーチ会社 Techstrong Research社による、DevSecOps関連の2023年のトレンドと、DevSecOps導入状況に関する調査データについての解説が行われた。
調査対象の企業の60%もの企業がDevSecOpsに対して何らかの形で取り組んでいると回答しており、まだDevSecOpsが検討段階になっていない企業は30%程度にとどまっていることが判明した。
DevSecOpsのプラットフォームは、現状Best of Breed（色々なベンダの組み合わせ）の状態であり、Suites（同一ベンダによるシステム）の状態を目指すベンダは、M＆Aや機能追加を積極的に行っている。
DevSecOpsではセキュリティ責任をチーム共同で所有することを求めるが、開発業務をメインで行う開発者からの反発を招いている現状がある。セキュリティ担当は、開発チームにセキュリティチャンピオンを置き継続的教育を行う、またセキュアな設計のパターン/テンプレートを提供したりツールを導入することで開発者の負荷を減らす、といった施策を行う必要がある。
当社コンサルタントの見解：
多くの企業がDevSecOpsに取り組み始めているという部分については、日本でコンサルティングを行っている我々としても実感している所であり、アジャイル開発に取り組み始めた企業からセキュリティ導入に関する相談を受ける事も増えてきている。そんな中、企業がDevSecOpsを正しく推進していくには、セキュリティチャンピオンの育成といったDevSecOps文化の醸成に加え、適切なプラットフォーム・パイプラインの構築やツールの導入などを通じて、セキュリティ人材が開発者を支援することが大切であると考えている。DevSecOps Worst Practices
講演者：
Tanya Janca (CEO and Founder, We Hack Purple)概要：
講演者が、過去AppSecの立場で300以上の企業と協力する中で経験した、DevSecOps失敗の原因となった15のバッドプラクティスについて事例と共に紹介した。
紹介されたバッドプラクティス：「誤検知によりビルドを壊してしまう」、「ツールをテストせず用いる」、「開発者を妨げるだけのセキュリティゲートを設ける」、「テスト結果を開発者が参照できない」、「開発者がテストを回避してしまう」、「セキュリティにおける達成不可能なSLAを立てる」、「職員を訓練しない」、「バグがバックログで見過ごされる」、「ポジティブフィードバックを行わない」、「自分の職務範囲だけに注意を払う」、「複数のバグトラッカーを導入する」、「CI/CD以外のSDLCが安全でない」、「CI/CDの権限不備」、「CI/CDのみを自動化する」、「エラーを秘匿する」
バッドプラクティスに当てはまるものが無いかを確認することを初めのステップとし、次いでバックログの確認や不要なツールの削除、教育を徐々に行っていくことで、DevSecOps失敗の要因を削減していくことができる。
当社コンサルタントの見解：
紹介されたバッドプラクティスは大別して、不適切な教育・文化に由来するもの、安全かつ実現可能でない開発プロセスの構成によるもの、ツールの不適切な使用によるものの3つであると言える。「文化・プロセス・技術」はDevSecOps実現のための重要な3要素であると当社では考えており、それぞれの要素から派生した上記のようなバッドプラクティスを参照し、自組織の状況と照らし合わせてレッスンとすることで、DevSecOps実現のための試金石とされたい。ソフトウェアサプライチェーン
Exploiting Vulnerabilities and Flaws to Attack Supply Chain
講演者：
Ilay Goldman (Security Researcher, Aqua Security)Yakir Kadkoda (Lead Security Researcher, Aqua Security)
概要：
本セッションでは、ソフトウェアサプライチェーンにおける開発工程をIDE、SCM（ソースコード管理）、Registry、CI/CD、Artifactsに分け、それぞれの工程での攻撃例/緩和策について紹介した。
例えば、IDEフェーズでは、VSCodeの拡張機能をMarketplace上で、正規のものに似せて偽装するImpersonate Extensionについて触れ、実際に講演者の作成した偽の拡張機能が48時間以内に1000人もの開発者にインストールされたことについて報告した。
その他ではArtifactsフェーズにおいて、Timing Attack（サーバからの応答時間の差異を利用して情報を取得する攻撃）によりnpmのプライベートパッケージ名を探索したのち、スコープ（通常ユーザ名や組織名である）を省略した同名の偽のパッケージを作成して、スコープに言及し忘れた開発者に偽のパッケージを利用させる攻撃（Dependency Confusion）を紹介していた。
当社コンサルタントの見解：
本セッションでは、ソフトウェアサプライチェーンの各工程における具体的な攻撃例/緩和策について紹介していた。開発者が信頼できないソフトウェアをインストールしないように統制している組織は多いと思うが、IDEの拡張機能といった部分まで管理している組織はあまり多くないだろう。ソフトウェアサプライチェーンではその各工程において多様な攻撃ベクトルが存在している。SLSAなどのフレームワークを利用して、自社のソフトウェアサプライチェーンにどのようなリスクが存在しているか洗い出すことが重要だと考えられる。
また、ソフトウェアサプライチェーンの対策をする上で、念頭に置くべき事は、開発者はミスをするということだろう。組織は、開発者が外部のパッケージを利用する場合、上述のようなリスクがある事を啓蒙する必要があるほか、パッケージを自社内で提供する場合は開発者が偽のパッケージをTyposquattingによりダウンロードしないよう、似た名前のパッケージをプレースホルダとして用意しておくといった対策が考えられる。拡張機能の提供者はドメイン認証サインを取得して自身の真正性を証明するといった対策が求められている。
The World on SBOMs
講演者：
Chris Blask (Chief Evangelist, Cybeats)Kate Stewart (VP, Dependable Embedded Systems, Linux Foundation)
概要：
ソフトウェア開発ライフサイクル（SDLC）の進行に沿ってSBOMを作成/更新する米国電気通信情報局（NTIA）の考え方と、それに基づいた概念的な応用例が紹介された。
SBOMをソフトウェア開発の各段階で作成・更新し（設計SBOM, ソースSBOM, ビルドSBOM, etc.）、これを上手く活用することでソフトウェアの開発や活用の場面でソフトウェアサプライチェーンの追跡可能性を高めることができる。
段階的に生成・更新されるSBOMの活用方法として規制産業（エネルギー事業）における概念的な応用例が紹介されていた。その例では業界におけるステークホルダと機能を定義したうえで、脆弱性の発見などのシナリオを想定しており、ステークホルダ（機能）の連携とSBOMの活用でシナリオの課題を解決できることが強調されていた。
当社コンサルタントの見解：
SDLCの各段階でSBOMを生成・更新することに対する技術的障壁はまだ高い。しかし今後SDLCの各工程で使用されるツールでSBOMの参照や作成、更新に対応する機能が増え、それに伴いSBOM活用がより具体化されることが予想される。Introducing the Secure Supply Chain Consumption Framework (S2C2F)
講演者：
Adrian Diglio (Principal PM Manager of Secure Software Supply Chain (S3C), Microsoft)概要：
マイクロソフトが開発・公開したソフトウェアサプライチェーンセキュリティに関するフレームワーク「S2C2F」について紹介が行われた。
ソフトウェア開発の過程で当該ソフトウェアの完全性を確保するフレームワークである「SLSA」に対して、「S2C2F」はOSS（オープンソースソフトウェア）を活用する立場にある者（Consumer）がワークフローにOSSの依存関係を安全に組み入れることを目的としたフレームワークである。
「S2C2F」には様々な脅威シナリオに対応するための8つのプラクティスがあり、各プラクティスには4つの成熟度で分けられた要件が定義されている。また、各成熟度の要件を満たす、実際のツールのマッピングも行っている。
当社コンサルタントの見解：
「S2C2F」はOSS等のソフトウェアを安全に活用するための枠組みとして米国やその他地域、各業界で標準仕様として浸透する可能性がある。実際に、「S2C2F」はOpenSSFに取り入れられるなど大規模なコミュニティへの普及が進んでいるため、本フレームワークの活用については検討の価値があるのではないだろうか。
※OpenSSFは、OSSセキュリティの改善を目的とした業界横断的組織であり、OSSに関するメトリクスやベストプラクティス、ツール、教育等の提供を行っている。別のトラックセッションにおいては、OSSの安全性をスコア化するOpenSSF Scorecardsの紹介も行われた。
Software Supply Chain:Panel on Threat Intel, Trends, Migration Strategies
講演者：
Jossef Harush Kadouri (Head of Supply Chain Security, Checkmarx)Karine Ben-Simhon (VP Customer Advocacy ARC, Trellix)
Nir Peleg (VP BizDev, Scribe Security)
Idan Wiener (CEO & Co-founder, illustria)
Omer Yaron (Head of Research, Enso Security)
概要：
ソフトウェアサプライチェーンにおけるトレンドや緩和戦略等に関して、セキュリティ企業のCEOらを交えてパネルディスカッションが行われた。
米国では、2021年の大統領令や、2022年NISTによるSecure Software Development Framework（SSDF）1の策定など、ソフトウェアサプライチェーンを強化のための施策が本格的に取り組まれている。今年度の3月には、国家サイバーセキュリティ戦略を公表し、消費者側やオープンソフトコミュニティからソフトウェア提供者側へと安全でないソフトウェアの責任をシフトすることを戦略目標としSBOMやSSDFの活用を推奨しており、ベンダはこうした基準・フレームワークに準拠することが必要になりつつある。
AIによるソフトウェアアプライチェーンリスクを低減するための利活用についても議題に上がった。AIを用いて悪意あるコードを検知するといった活用方が考えられるが、ChatGPTを用いた検証の結果、AIを欺くソーシャルエンジニアリングに対して脆弱であることが分かり、信頼性の問題でまだ疑問が残るとの見解が示された。
当社コンサルタントの見解：
米国は現在ソフトウェアサプライチェーンについて最も先進的に取り組んでいる国であると言える。米国では安全なソフトウェア開発をソフトウェア提供者がより率先して行うように、ソフトウェア提供者への責任のシフトを推進している。我々もこうした国際的な動向を鑑みながら、安全なソフトウェア開発のためのベストプラクティスを吸収していく必要があるだろう。
本パネルディスカッションでは最近の潮流も鑑みてAIに関する言及が行われたことも印象的だった。AIを用いたソフトウェアサプライチェーンマネジメントには展望を見出せるものの、現時点ではその信頼性に疑問が残るという見解は、セキュリティの他分野と共通的な見解であった。現時点では策定が進んでいる既存のフレームワークやツールを用いて対策を行いつつも、今後の動向に注意を向けていくのがよいだろう。
おわりに
本ブログでは、DevSecOpsやソフトウェアサプライチェーンに関する動向について、トラックセッションの内容を紹介してきた。
DevSecOpsに取り組む企業も増えてきており、カンファレンスでは実際の運用の結果得られた知見を共有するセッションも多かった。DevSecOpsではチーム全体でセキュリティ責任を所有することを求めるが、開発者にセキュリティ責任を押し付けるのではなく、セキュリティ担当が開発者を支援することが必要であることは一貫して強調されていた。
また、DevSecOpsを実現するためには、セキュリティチャンピオンの育成といった教育・文化にまつわる取り組み、安全性と実効性を兼ね備えた体制構築、適切なツール導入といった点についても必要となると考えられている。ただ実際には未だこうしたDevSecOpsの実現にハードルを感じている企業も少なくないと思われる。当社では、組織ごとの体制に応じてDevSecOps導入のための支援も行っているため、何か困りごとがあれば気軽にご相談いただければと思う。
また、ソフトウェアサプライチェーンでは、リスクの評価や実践規範について基準を設けるべく、様々なフレームワークやツールが登場してきている。行政の観点でも、米国では大統領令や国家サイバーセキュリティ戦略などが発表され、ソフトウェア開発企業がこういった布告に順守するよう歩みを進めることが求められてきており、今後はこれらのフレームワークや取り組みがグローバルスタンダード化していく可能性も高いと考えられる。
こうした情勢に乗り遅れず進歩するサイバー攻撃に対応するために、我々も適切なツールの導入や開発体制の構築といった部分について検討を行っていく必要があるだろう。実際に、当社が過去開催したソフトウェアサプライチェーンに関するセミナーでは、SBOMの活用法などについて様々な企業から相談をいただいた。国内においてもソフトウェアサプライチェーンマネジメントについての関心は高まりつつあるのではないか、と考えている。
＜関連サービス＞
