DXにおけるソフトウェアの重要性とセキュリティリスク

ソフトウェアがいかに重要であるかは、自動車がわかりやすい例と言えます。自動車は約3万個の部品で構成されると言われていますが、この数字は大きく変わっていません。一方、自動車に搭載されるソフトウェアは、10年前は100万行ほどのコードだったのが、現在は1億行以上になっています。

「現在はハードウェアよりもソフトウェアの進化が早く、ソフトウェアを先行して開発する『ソフトウェアファースト』の考え方が広がってきています。トヨタ自動車は1990年代、自動車のエレクトロニクス化が急速に進んだ際に『技術の手の内化』というキーワードを掲げました。これは、電子部品や半導体を内製化して、新しい技術を自分たちのものにして活用していくという考え方です」（前野）

この考え方は、DXを推進するためのソフトウェア開発においても同様です。ソフトウェアの技術をコントロールして、武器として使いこなしていくことが求められています。一方で、セキュリティも非常に大きな問題であり、重大なセキュリティインシデントが発生すると、サービスが停止したり、サービス自体が廃止になってしまったりすることもあります。

「DXを推進するためには、セキュリティも含めて手の内化していくことが必要です。しかし、開発者の数に対してセキュリティ人材が非常に不足しているなど、多くの課題があります。そこで解決策のひとつとなるのが効率化です。例えばソフトウェア開発において、セキュリティリスクを要件定義の段階で発見すると、リリース後に発見するよりも修正コストが1/30になると言われています」（前野）

セキュリティリスクの発見が早ければ早いほど、結果的にコスト削減につながります

このように、セキュア・バイ・デザインの考え方により、一連の開発サイクルの中にセキュリティを埋め込んで運用していくことを「DevSecOps」と言います。DXの観点では、ソフトウェアの手の内化によるDXの推進と、セキュリティの手の内化によるDX阻害要因の排除を同時に進めていくことが可能になるのです。

ソフトウェアとセキュリティの手の内化を同時に進めることでDevSecOpsが実現に近づきます

DevSecOpsの本来の姿と失敗例

米国CSAでは、DevSecOpsの「6つの柱」を定義しています。これは「組織・文化」と「技術」の観点に分けることができます。組織・文化では「共同責任」「コラボレーションと統合」「コンプライアンスと開発の架け橋」「測定・監視・レポート・アクション」、技術では「実用的な実装」「自動化」となります。

「これまでは、開発部門が開発のみに集中し、セキュリティ面での確認や判断が必要なときにセキュリティ部門に依頼していました。しかし、DevSecOpsでは両部門が共通の指標のもとでセキュリティの責任を負います。それを実現するために、開発部門には「Security Champion」と呼ばれるセキュリティのリーダーを擁立します。そして開発部門での自律的なセキュリティ判断やセキュリティ文化の浸透を行います」（前野）

「Security Champion」が旗振り役となって、開発部門のセキュリティ意識を強化する必要があります

しかし、実際にDevSecOpsに取り組んでも、うまくいかないケースも少なくありません。前野は、DevSecOpsにおけるリアルな失敗例を紹介しました。

1つ目のケースは、ソフトのパッケージ開発やシステムインテグレーション事業を行っている会社です。DevSecOpsの推進に前向きでビジョンを持ち、理解も深かったのですが、実際に大規模のプロジェクトで進めた際に、Security Championとして擁立された方のセキュリティスキルが十分ではありませんでした。そのため、開発側ですべきセキュリティの判断を、ほとんどセキュリティ部門に投げてしまい、セキュリティ部門が回らなくなってしまいました。

2つ目はIT関連企業です。同社では、コンテナセキュリティのツールの導入をきっかけにDevSecOpsに取り組みました。しかし、セキュリティ部門には「ある閾値以上の脆弱性には必ず対応する」という既存のルールがありました。このルールを開発側にも適用した結果、開発段階で大量に発見される脆弱性に対応することになり、開発スピードが以前より低下してしまいました。

3つ目はSaaSサービスを提供する企業です。同社では、すでにDevOpsを実践しており、高速な機能リリースを実現していました。上場企業でもあることからセキュリティ意識は高く、セキュリティを横串で見る部門を発足させ、DevSecOpsの推進を検討しました。しかし、高速なリリースが文化として定着していたので、セキュリティを組み込むとリリースが遅くなるとして、開発側に抵抗があり、セキュリティの強制力を効かせことが難しい状態でした。

「問題の本質は、開発チームが保有する『セキュリティの知識』『能力』『経験』と、開発チームが直面している『セキュリティリスクの複雑性と量』との関係性にあります。前者はそれぞれのスキルを底上げする必要があるのですが、簡単に変えられるものではありません。もし変えるとしたら、後者の複雑性と量を引き下げなければなりません」（前野）

阻害要因を克服するための考え方

こうした阻害要因を克服するためには、「セキュリティリスク」に立ち戻って考える必要があります。リスクは発生確率と影響度に分解できます。これをセキュリティの要素として分解すると、発生確率は脅威と脆弱性、影響度は資産価値となります。このうち、脅威と資産価値は事前に想定することができます。

脅威を想定する手法として、マイクロソフトが提唱している「STRIDE」というフレームワークを活用できます。また資産価値は、アプリケーションを構成するサーバーやコンテナといった要素が資産に対してどれぐらいセキュリティ的な影響度を持つものなのかを、セキュリティのCIA、つまり機密性、完全性、可用性で判別していくわけです。

脆弱性も可視化が必要ですが、CVSSのような公的指標に基づいてリスクを判別しようとした場合、CriticalやHighといった高いレベルの脆弱性が大量に発生することがあります。実は、CVSSの基本スコアのみをリスク判定に用いることは適切ではない面があるのです。そのため、脆弱性に関する他の条件を考慮する必要があります。例えば、脆弱性はそれを悪用する攻撃コードがあって初めて攻撃可能になります。そのため、攻撃コードの有無が有効な判断指標の1つになるのです。

DevSecOpsの実現に向けて取るべきステップ

では、DevSecOpsを実現するために必要なステップは何でしょうか。まず脅威と資産価値は、アプリケーションの「どこに」「どのような」脅威が存在して、「どれぐらい」の影響があるのかを机上で洗い出し、リスクの所在を明らかにできます。これには、脅威モデリングという考え方があります。

脆弱性に関しては、いかに情報を得ていくかが重要になります。例えば、どのような脆弱性が公開されているか、攻撃コードが存在するかなどは国内外のサイトで確認できます。ただし、こうした情報収集はある程度の時間を要します。

「当社では、例えば開発段階でツールが出す脆弱性の情報を、さらに本質的な個別のリスクを見たり、資産の状況やその資産に対する影響度を色づけしたりと、自動的にトリアージしていく仕組みが作れるのではないかと考えています。実際に試してみると、脆弱性検出ツールが検出した18個のクリティカルな脆弱性が、自動トリアージによって対処すべき重要な脆弱性は1件になりました。こうした実証を現在お客様と進めています」（前野）

最後に前野はまとめとして、「ソフトウェア技術とセキュリティを手の内化するためにDevSecOpsのアプローチは非常に重要です。DevSecOps実現のためにはツール以外の要素が重要であり、プラクティスをそのまま当てはめるだけではうまく行かないことがあります。直面するソフトウェアのリスクの複雑性・量をいかに引き下げて、開発チームが正しい理解・判断ができるように取り組みを進めていくことがポイントになります」と述べています。

脆弱性トリアージを自動化することで、開発スピードとセキュリティリスク低減の迅速化を実現できます

▼人物キャプション
マクニカネットワークス株式会社
DXビジネス推進部 DXビジネス部 第2課 課長
前野 秀彰
（2021年7月現在）