なぜDevSecOps?

重要なポイント

  • DevSecOpsは、DevOpsの拡張として、ソフトウェア開発プロセス全体にセキュリティを統合するものです。
  • ソフトウェアサプライチェーンへの攻撃は年々増加しており、オープンソースコンポーネントのリスクを積極的に管理することが不可欠になっています。
  • 開発プロセスにセキュリティを組み込むことで、チーム間の摩擦を増やし開発を遅らせる可能性のある「scan and scold」アプローチから、アプリケーションセキュリティに組織を移行させることができます。
  • ソフトウェア開発ライフサイクルを通じてセキュリティの問題に対処することは、時間と費用の節約につながり、顧客の信頼を維持することにもつながります。

はじめに

DevSecOpsトラックの最初の技術記事「DevSecOpsとは何か?」では、DevSecOpsはDevOpsの拡張であり、品質を作り込むことで、ソフトウェア開発者によるオープンソースソフトウェア(OSS)コンポーネントの選択を含むソフトウェア開発ライフサイクル(SDLC)全体に、アプリケーションセキュリティ対策を統合することを主張するものである、と説明しました。

DevSecOps戦略の一環として、OSSコンポーネント管理を優先させるべき説得力のある理由がたくさんあるので、今回の記事ではそれについて説明します。

 

ソフトウェアサプライチェーンの現状

(オープンソース)ソフトウェアが世界を食べようとしている

ソフトウェアが世界を席巻する」と言われる昨今、開発者はより複雑な機能を持つソフトウェアを、これまで以上に早くリリースする必要に迫られています。

この任務を果たすために、OSSのコンポーネントに依存するケースが増えています。結局のところ、アプリケーションに必要な同じ機能を提供する、自由に利用できて広く使われているコンポーネントがあるのに、なぜ独自のコードを書いて「車輪の再発明」をしなければならないのでしょうか?

実際、Sonatype社の「State of the Software Supply Chain」レポートによると、現代的なアプリケーションの80%以上をオープンソースソフトウェアコンポーネントが占めているとのことです。

 

オープンソースがますます重要な位置を占めるようになり、ソフトウェア開発者の役割も「コーダー」という狭い枠組みから、ソフトウェアプラットフォームとそのプラットフォーム内のビジネス要件の両方を実現するためのコードの組み立てやコードの統合を担うといった、広い定義に変わってきています。

そして、ソフトウェア開発プロセスそのものが、従来の製造業のサプライチェーン、いわばソフトウェアのサプライチェーンのように見え始めているのが最近の特徴です。SonatypeのIQ for Developers 100コースでは、このアナロジーをさらに詳しく解説しています。

 

サプライヤー=OSS

従来の製造業ベースのサプライチェーンでは、完成品の最終的な組み立てに使用されるコンポーネントを製造するための信頼できるサプライヤーが存在します。 ソフトウェアのサプライチェーンの場合、オープンソースプロジェクトは、開発中のアプリケーションで使用される最も一般的なコンポーネントのいくつかを供給しています。

ウェアハウス = コンポーネントリポジトリ

また、従来のサプライチェーンでは、それらのコンポーネントをより安全かつ効率的に保管・配布するために、大規模な集中倉庫を利用することで物流や調達を効率化してきました。同様に、ソフトウェア開発者は現在、Sonatypeが管理するCentralリポジトリ(Java)、rubygems.orgpypi.orgnpmレジストリ(javascript)、NuGet Gallery(.net)などのコンポーネントリポジトリに頼ることが多くなっています。

メーカー=ソフトウェア開発チーム

メーカーは、アプリケーションの構成要素として使用されるオープンソースコンポーネントを調達し、消費するソフトウェア開発チームに似ていると言えるでしょう。

組み立てられた製品=ソフトウェア・アプリケーション

最後に、従来のサプライチェーンで組み立てられ、検証された製品は、顧客に公開するソフトウェアアプリケーションのテスト済み最終ビルドに匹敵するものです。

OSSへの侵入が増加している(そして巧妙化している)

ここからが少し怖い話です。オープンソースのコンポーネントは、プロプライエタリなソフトウェアよりも安全である、あるいは侵害される可能性が低いという認識が一般的ですが、これはおそらく、OSSプロジェクトに貢献しレビューする「多くの目」というアプローチによるものでしょう。

しかし、「2019 DevSecOps Community Survey」によると、OSSコンポーネントに結びついた侵害は、過去5年間で71%増加しています。

Sonatype CTOのBrian Foxは、Forbesの記事「Open Source Developers and Infrastructure Are the New Frontline of Security」でこれらの攻撃のいくつかを詳しく紹介しており、その発表以降も多くの攻撃が発生しているとのことです。

攻撃の数が増えていることに加え、Fox氏が説明するように、攻撃者自身のアプローチもより巧妙になってきています。

 

“調査の中で証拠の断片をつなぎ合わせると、オープンソースの配布に使われる社会的信用とインフラに対する組織的な攻撃の真っ只中にいることが明らかになります。わずか数年の間に、既存の脆弱性に対する攻撃は、公開から数カ月後に発生していたものが、2日後に発生するようになりました。そして今、我々は、攻撃者がこれらのコンポーネントにおいて、悪用可能で、(暗号によって)直接マネタイズ可能な状態を積極的に作り出す段階にきているのです。”

オープンソースコンポーネントに対する非常に巧妙な攻撃の最近の一例は、Elisa Velardeのブログ記事「Corrupting the Software Supply Chain: Lessons from the Bootstrap-sass Attack」で記されています。ここでは、この攻撃を暴くきっかけとなった出来事の推移を簡単にまとめています。

  1. bootstrap-sass (RubyGems) コンポーネントに依存している開発者が、ビルドに失敗
  2. 開発者が調査したところ、彼のアプリケーションで使用されていたバージョンが削除され、その数分後に新しいバージョンがRubyGemsのリポジトリに追加されたことが判明。
  3. さらに調査を進めると、コンポーネントライブラリのソースコードはGitHub上で更新されていないことがわかり、開発者は赤信号を点滅。

この開発者が不審な痕跡を追ったおかげで、新たに追加された脆弱なバージョンの bootstrap-sass コンポーネントは、同日中にチームによって RubyGems リポジトリから削除され、悪質なバージョンをプッシュしたと考えられるアカウントの権限も削除されました。

しかし、このような安易な置き換えや強制アップグレードの手法は、ソフトウェア内のコンポーネントの依存関係を適切に管理していない人に大打撃を与える可能性があり、より一般的になりつつあります。

 

オープンソースソフトウェアのコンポーネントはどのように管理されているのか(あるいはされていないのか)?

2019 DevSecOps Community Survey」によると、開発者100人以下のソフトウェア開発組織の約40%が現在のインフォセックチーム/プロセスが足かせになっていると考えており、開発者5000人以上のソフトウェア開発組織の約53%が現在のインフォセックチーム/プロセスが足かせになっていると考えていることが判明しました。

セキュリティのプロセスが、開発者の使命であるソフトウェアのデリバリースピードにそぐわない場合、緊張が生まれます。

ソフトウェア開発コミュニティの進化において、高摩擦でレガシーなプロセスがセキュリティと開発の間に溝を作ったというのは、この時点では議論の余地がないことです。しかし、もっと議論を呼びそうなのは、生まれた溝を現場までたどり、レガシーなプロセスが開発者の足を引っ張り始めたときに忍び寄る可能性のある(不注意かもしれないが)結果に目を向けることです。

例えば、開発者が「良い」OSSコンポーネントと「悪い」コンポーネントを簡単に自動選択する方法がない場合、主観的な選択をせざるを得ません。

その開発者がたまたま「悪い」選択をした場合(「scan and scold」タイプの環境で)、再挑戦できるようなインセンティブはあるでしょうか?開発者たちは、OSSコンポーネントの選択における必要情報を備えているのでしょうか?

あるいは、たまたま「良い」選択をしてしまった場合はどうでしょうか?ふぅ、そうですね?なぜ、うまくいったものにこだわらないのでしょうか?他のバージョンのコンポーネントの脆弱性に関する具体的な情報もなく、そのようなシナリオでアップグレードするインセンティブはあるのでしょうか?

最後に、承認プロセス自体に時間がかかり、セキュリティからの決定がやっと戻ってきたときに、開発者が何もできないとしたらどうでしょう。その場合、新しいコンポーネントを選択するために必要な手直しが障害となり、開発者は「悪い」コンポーネントに固執せざるを得なくなる可能性があります。

このように、統合され自動化されたオープンソースガバナンス戦略の欠如は、開発者が「間違った」ことをするのを不注意に促す可能性があります(同時に、イノベーションを阻害することにもなります)。

 

Accelerateによると 「The Science of Lean Software」と「DevOps: Building and Scaling High Performing Technology Organizations」にはより良い方法があるそうです。

“ソフトウェアにセキュリティを組み込むことが開発者の日常業務の一部となり、情報セキュリティチームがツール、トレーニング、サポートを提供し、正しいことを簡単に実行できるようになれば、納品パフォーマンスは向上します。それだけではなく、セキュリティにも良い影響を与えます。”

DevSecOpsのビジネスケース

誰も次のEquifaxのような見出しにはなりたくありません。

最も広く知られたオープンソースの侵害の1つは2017年に起こったもので、ハッカーがEquifaxのWebサイトを介して数百万人の消費者の個人情報にアクセスしたのですが、このサイトはたまたま人気のあるオープンソースのWebフレームワーク・コンポーネント「Apache Struts」に依存していました。

その結果、多くの人に影響を与え、多くの見出しを集め、Equifaxの評判と信頼は大きく損なわれました。

顧客の信頼を得る(維持する)ことは、どの企業にとっても簡単なことではありません。セキュリティ違反やプライバシー関連の問題が多発する中、顧客の信頼を失うリスクを最小限に抑えることは、多くの企業にとって優先事項のトップに挙げられています。

以下のグラフに見られるように、悪用されるまでの平均時間は劇的に減少し続けているため、企業はこれらのセキュリティ侵害に対処するための時間を大幅に短縮することができます。

 

残念ながら、自社にセキュリティ侵害が発生したときだけセキュリティの優先順位を上げるという組織もあるようです。しかし、より良い戦略とは、セキュリティに加えて、顧客の信頼がそもそも侵害されないような予防ではないでしょうか?

競争上の差別化要因としてのセキュリティ

キャロライン・ウォン氏は、「Why Does Security Matter for DevOps?」という講演で、セキュリティが企業レベルのコンプライアンス志向の組織にとって、利害の一致だけでなく、競争上の差別化要因になりつつあることを論じました。

“DevOpsにとって、ソフトウェアのセキュリティ確保は、競争上の差別化要因にだってなり得ます。つまり、セキュリティはマーケティングに適した機能であり、顧客やパートナーとの必要な信頼関係を促進します。そのため、同業他社や競合他社がアプリケーション・セキュリティに注力しているのに、自社はそうでない場合、実際に遅れをとる危険性があるのです。”

開発コスト削減

最初は確信に至らないかもしれませんし、開発者が一定の速度を維持する能力と見合わない可能性もありますが、ソフトウェア開発プロセスの早い段階でオープンソースガバナンスの自動化を統合することで、全体としてコスト削減につながる可能性があります。

  • 開発者は、OSS コンポーネントの調査や審査に費やす時間を減らすことができます。
  • セキュリティ関連のコードレビューが開発サイクルの終盤に行われる場合、その段階で発生する再作業や技術的な負債を伴う発見があれば、セキュリティ問題が開発サイクルの初期に発見された場合よりも長期的にコストが高くなります。
  • さらに、運用開始後にアプリケーションのセキュリティ脆弱性が発見された場合、「全員参加型」のアプローチによる修復にかかるコストはとんでもない数字になる可能性があります。

Accelerateの著者によると、DevSecOpsのワークフローを採用することで、修復にかかる時間は大幅に短縮されるとのことです。

“高業績者は、低業績者に比べて、セキュリティ問題の修正に費やす時間が50%少ないことがわかりました。言い換えれば、セキュリティの懸念を最後に後付けするのではなく、日々の業務にセキュリティを組み込むことで、セキュリティ問題への対処に費やす時間を大幅に減らしていたのです。”

悪者がますます「井戸に毒を盛る」中で、顧客の信頼を維持し、競争力を維持することが重要となっています。その中で、コスト超過を防ぐために、DevSecOpsのビジネス・ケースは、より一層フォーカスされ始めているのです。

前の投稿
OSSライセンス
次の投稿
AssetIT IT資産管理システム
メニュー