O’Reillyの著者Guy Podjarnyが語るオープンソースセキュリティ

先週、Snykの共同創業者Guy Podjarnyがライブチャットに参加し、著書O’Reillyの書籍Securing Open Source Librariesについて語りました。この記事では、ウェビナーで得られた興味深いポイントをいくつかご紹介します。まだご覧になっていない方は、こちらから録画をご覧いただけます。またSnykでは、本書を無料でご提供しています。

なぜオープンソースセキュリティなのか？

議論は、「なぜオープンソースセキュリティについて考える必要があるのか」という重要な問いから始まりました。Guyは、現在の市場ではオープンソースライブラリに伴うリスクが過小評価されていると考えています。開発チームがデプロイするコードの大部分は、実際には自分たちが書いたものではなく、オープンソースライブラリです。これは、チームが車輪の再発明をせずに済むという点では素晴らしいことです。一方で、オープンソースコンポーネントに存在するリスクも引き継ぐことになります。

このリスクの一因は、自社で開発したアプリケーションコードと比べて、オープンソースライブラリの数が膨大であることです。また、オープンソースコンポーネントは攻撃の標的として特に魅力的です。攻撃者はまず、簡単に成果を得られる標的を狙うことが多く、1つの脆弱性を多数の被害者に対して悪用できるオープンソースは、投資対効果の高い攻撃対象となります。

業界では現在、この問題にどう対処しているのでしょうか？

業界の一部では、現在もこの問題に対処できていません。特に悪質なエクスプロイトについて耳にしたとき、その都度、個別に対応することはあるかもしれません。しかし、オープンソースの部品表はなく、どのコンポーネントをどこで使っているかも追跡していません。また、脆弱性データベースと照合してコンポーネントを継続的に監視することも、ほとんどありません。

一方、使用するオープンソースライブラリを決める際に、セキュリティを考慮する組織もあります。多くの場合、これはライブラリを導入する前に行われますが、導入後も継続して監視されるとは限りません。新たな脆弱性が発見されたり、バージョンアップによって新たな脆弱性が持ち込まれたりすることがありますが、こうした変化を監視する仕組みが整っていないのです。

そして、オープンソースのセキュリティ脆弱性を継続的に発見し、修正することに取り組んでいる企業もあります。本書では、その実践方法について詳しく解説しています。まずは、オープンソースライブラリで新たな脆弱性が開示されたときに何が起こるのか、見ていきましょう。

時間との戦い

プロジェクトについて考えるときは、バグがあることを前提にすべきです。完璧なコードを書くことはできませんし、最適な条件下でコードを書いたり使ったりしているわけでもありません。セキュリティバグも同様です。したがって、導入するオープンソースプロジェクトには、まだコミュニティに発見されていないだけで、セキュリティ脆弱性が存在する可能性があると考えるのが健全です。

脆弱性が発見されて開示されると、競争が始まります。コミュニティは脆弱性の修正をリリースし、利用者に適用してもらおうとします。一方、悪意ある攻撃者は、あらゆる場所で脆弱性を悪用しようとします。脆弱性の存在はすでに知られているため、攻撃者が自ら発見する必要はなく、行動を起こすだけです。脆弱性が開示されると、それに伴うセキュリティリスクは大幅に高まります。攻撃者は、セキュリティ衛生が不十分な状態につけ込みます。チームは、脆弱性の開示から修正までの時間をできるだけ短縮する必要があります。その差を完全になくすことはできませんが、1時間と1日、1週間、1か月、1年では大きな違いがあります。

では、チームはどうすればこの差を縮められるのでしょうか？また、各メンバーにはどのような役割があるのでしょうか？

現場で実践するDevSecOps

DevSecOpsは、業界でよく耳にする理想を表す言葉です。分野を越えて協力し、機能的で安全な製品という共通の目標に取り組むことを意味します。この目標に向けて個々のメンバーが取るステップは、セキュリティ担当者か開発者かによって異なります。

セキュリティ担当者の役割は、潜在的なリスクを意識的かつ計画的に管理し、組織の安全を守ることです。そのため、自組織の現在のリスク状況を把握し、どのリスクに優先して取り組むべきか判断できる必要があります。ただし、セキュリティ専門家が直接修正を行うことを期待されると、規模を拡大できず、問題を招く可能性もあります。開発チームほどコードベースに精通していないからです。

DevSecOpsにおけるセキュリティ専門家の役割は、DevOpsにおけるサイト信頼性エンジニア（SRE）の役割に似ています。セキュリティ専門家はシステム全体の健全性を俯瞰し、ポリシーを策定します。チームのセキュリティ担当者は、ガバナンスの責任を担うだけでなく、共に働く開発者が日々の業務に責任を持てるよう、教育し支援します。ガバナンスから自動化まで、担当する業務を通じて、開発者が適切なセキュリティ判断を下し、実行できるようにします。

ワークフローが適切に整備されていれば、こうした業務の大部分はセキュリティ担当者が介入しなくても進められます。ポリシーを整え、開発者に優れたツールとトレーニングを提供できていれば、日々の業務はセキュリティ部門の干渉をほとんど、あるいはまったく受けずに進められます。

目指すのは修正すること

では、DevSecOpsチームが目指すものは何でしょうか？脆弱性の修正です。

脆弱性があることや、その場所を把握することは有益です。しかし、システム全体の健全性を高めるには、修正に取り組む必要があります。開発者に必要なツールがなく、セキュリティ部門やマネジメントから適切な支援も受けられない場合、脆弱性を見つけるだけで修正に至らないことがあります。

では、勢いを保ちながら、問題を発見するだけでなく修正するにはどうすればよいでしょうか？多くの組織では、トリアージが行われてからでないと修正に着手できず、トリアージは開発チームが関与する前に行われます。トリアージでは脆弱性の深刻度とリスクを確認しますが、修正の容易さまでは考慮しないことがあります。トリアージが完了すると、開発チームは、簡単に修正できる問題もあれば、根深く修正が難しい問題もあることに気づきます。

脆弱性によっては、トリアージするより修正するほうが簡単です。修正が簡単でない場合はトリアージが必要ですが、簡単に直せるなら、すぐに修正しましょう。修正を容易にするための投資をしていれば、トリアージを行わずに多くの脆弱性を修正できます。

脆弱性の修正を妨げるもう1つの要因は、規模です。チームは通常、多数のコンポーネントを利用しており、その多くに脆弱性があるため、大規模に対処するのは困難です。この場合、優れたガバナンス計画が役立ちます。緊急の問題に対応するためにチームがすべての作業を止めるべきタイミングと、通常のスケジュールに脆弱性の修正を組み込めるタイミングを判断しやすくなるからです。

Guyは目標をこうまとめます。プロジェクトにすでにある問題を見つけて修正し、そのうえで将来の問題を防ぎ、発生時に対応することです。見つける。修正する。防ぐ。対応する。大規模に取り組むべきことは、この4つに集約されます。

まずは被害の拡大を食い止める

では、始めましょう。まず何から取り組めばよいのでしょうか？

トリアージという言葉は、救急医療と結び付けて語られることがよくあります。大きな交通事故に遭った患者が搬送されてきた場面を想像してください。患者には、1週間続く風邪や季節性アレルギー、さらには重い慢性疾患など、さまざまな問題があるかもしれません。どれも医師の診察を受けるべきものですが、事故直後の対応で最優先すべきことではありません。重要なのは、まず出血を止めることです。医師は患者の状態がこれ以上悪化しないようにできる限りの処置をし、容体が安定してからほかの問題に対処します。

オープンソースセキュリティへの取り組みを始めるとき、チームは圧倒されてしまうことがあります。プロジェクトには、最初から多くの問題が存在するかもしれません。まずは被害の拡大を食い止めることが大切です。状況のさらなる悪化を防いでから、既存の問題に対処できます。差分に取り組みましょう。プロジェクトに脆弱性が7件あると分かっていて、新しい変更を含むPRを出したところ、脆弱性が8件になって戻ってきたとします。プロジェクトを安定させるには、追加された脆弱性を防ぐか修正すればよいのです。新旧コードの差分で発生したセキュリティ上の問題を修正しましょう。このワークフローを整えたら、レガシーなセキュリティ上の課題に取り組みます。

まずは被害の拡大を食い止めましょう。ただし、そこで終わりではありません。防ぎ、対応する。見つけ、修正する。オープンソースセキュリティの課題に継続して取り組み、新たな問題を持ち込まないようにしましょう。自信を持ち、責任ある形で、安全にオープンソースを活用しましょう。

インタビュー全編を見るには、こちらをクリックしてください。

Securing Open Source Librariesの無料コピーを入手する