2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
水谷正慶氏:では始めたいと思います。TrivyとRegoを用いてパッケージ脆弱性を管理する話です。簡単に自己紹介をします。水谷と言います。Ubie Discoveryでセキュリティのエンジニアをしています。
略歴としては、日本IBMの基礎研究所やセキュリティオペレーションセンターでセキュリティのアナリストを少ししていて、2017年にクックパッドに移り、インフラ関連のセキュリティやセキュリティアラートの対応などをしていました。
2021年の9月に転職したばかりで、自分としてはすごく濃密な日々を過ごしていて、もう半年以上いるような気がしつつ、実はまだ3ヶ月しか経っていないので、けっこうびっくりしています。Ubieでも、特にプロダクト周りのセキュリティをしていて、今回お話しするパッケージ管理も、プロダクト開発に関連しています。
外部パッケージの脆弱性管理が今回の話のテーマですが、昨今のWeb系の開発で言うと、サードパーティーのパッケージを使わずに開発するシチュエーションはほぼない気がしています。
サードパーティーは主にOSS(Open Source Software)が多いですが、いろいろなパッケージの恩恵を受けながら素早く開発することで、ビジネスとしても価値検証がやりやすくなっていると思います。
サービスそのものの機能や、フレームワークとして動かして使ったり、例えばwebpackのように、開発をする際のサービスとしてプロダクトに出す時に、いろいろとやるために使ったりするものもあるのではないかと思います。
そういったパッケージ関連のエコシステムが、昨今すごく発展しています。例えば、あるプロダクトがいろいろな外部パッケージを使うというものもあるし、使っているパッケージがさらに別のパッケージを使っているという、孫関係やひ孫関係のようなパッケージの依存関係もどんどんできています。
そうすると、今は1つのプロジェクトあたりで使っているパッケージが、数百や数千あるのはよくあることという世界観になっているのではないかと思います。このような関係性がすごく広くなってくると、きちんと管理することが必要になってくると思います。
脆弱性自体が常にいろいろ出てきます。やはりパッケージを使っている以上、なんらかの脆弱性が出てくるのはどうしても起こることなので、脆弱性をきちんとキャッチして管理していくことが必要になっていきます。
脆弱性の情報自体は、昔に比べればすごく取りやすくなっています。インターネット上のSNSや、専用のフィードの情報も取れる状態がどんどん整ってきているので、脆弱性がある情報自体を取ることは、すごく容易になったと思います。
また、プロダクトを使っている中で、脆弱性が入ったものを使っていないかをスキャンするツールも最近はいろいろ出てきています。そういったツールを使うことによって、自分たちが開発しているプロダクトに脆弱性が入っているかどうかを、けっこう簡単に検査できるようになりました。
さらに、いわゆるCI(Continuous Integration)の文化がいろいろ普及してきて、それを後押しするためのサービスやツールもすごく充実してきて、とてもやりやすい環境になってきたのではないかと思います。
ただ、その状況で既にわかっている脆弱性が全部駆逐されて、すごくハッピーな世界になったかというと、実際問題はそうでもないと思います。
では、なぜ知らない脆弱性ではなく、知っている脆弱性を駆逐できないのかに関して、3点ほどポイントがあるのではないかと思っています。
1つ目が、修正版のリリースのタイミングです。そもそも、外部のパッケージを利用しているので、外部のパッケージがどういったタイミングで脆弱性の修正をするかや、それをリリースするかは、自分たちでコントロールできません。そのため、考慮していく必要があると思います。
特にOSSの場合は、コントリビュータの方もボランティアでやっていることがほとんどだと思うので、OSSのパッケージを更新するタイミングは、やはりコントリビュータの方の都合に依存するところもあります。
例えば、こちらからプルリクエストを出して「こういうふうに修正してください」とお願いしても、それを取り入れてくれるかどうか、そのタイミングに関しては、基本的にコントリビュータのタイミングによるので、必ずしもすぐに対応できるとは限らないという状況があるかと思います。
特に難しいのが、依存関係の先の孫の部分にあるパッケージが脆弱で、使っているパッケージの側で上げないと、その先のパッケージがアップグレードされないパターンがあることです。
次の問題は、更新によって、プロダクトが破壊的に変更されてしまうかもしれないということです。これは一定あるのではないかと思います。
基本的に、パッケージを更新することによって、今まで使っていた機能の後方互換性がきちんと担保されているかは必ずしも保証できません。もちろん、テストなどできちんと検証していければすごく簡単ですが、やはり本番環境にデプロイしてみないと再現しない問題も、絶対に一定はあります。そのため、一定のリスクを抱えながら変更作業をする必要は、どうしても出てくると思います。
そういった状況では、すぐに変更していく作業をすることによって、ビジネス自体が止まってしまうこともあります。影響の大きい脆弱性に関しては、すぐに修正しないと厄介なことになります。しかしそうではなく、それほど広い範囲で影響を及ぼさないことがわかっていて、変更によって発生するリスクを考えて少し優先順位を下げてやっているうちに、だんだんそれが溜まっていくようなケースも現場では多々あるのではないかと考えています。
ほかのパターンとしては、パッケージ更新。いわゆるバージョンアップをして、ソースコード自体の脆弱性を修正しなくても、ほかの方法で緩和されている状態もあったりします。
これは別に、緩和されているから直接的に問題ではありません。しかし、脆弱性によっては外部の要因、フィルタした時に、それをフィルタしているかどうかをきちんと管理したいということがあるので、更新がきちんとできていないかどうかの判断が、難しくなってくるのかなと思っています。
必ずしも既存の脆弱性がすぐ更新できるわけではないとなると、脆弱性がどういう状況なのか、そしていつ更新するべきなのか、あるいは更新するべきではないのかを、それぞれ管理していく必要があるかと考えています。
その時に実際にどういうことをしなければいけないかも、3点ぐらいポイントがあるかと思っています。
1つ目が、プロダクトや脆弱性ごとに状態を管理したいということです。プロダクトはすぐに修正できません。リリースのタイミングがなかったり、なんらかの緩和策でやっているから、今は修正しなくていいという状況がどうしても発生します。
そうすると、すぐに修正できないのか、それともしないのか。しないにしてもいつまで待っていればいいのかを、組織ごとに管理することが必要になってくるのではないかと思います。
アップデートできないのに、「今はまだ脆弱性があります」という警告だけずっと出ているとなると、本来見るべき脆弱性の情報がノイズになるので、そういったものをなるべく出さないようにして、対応するべきものだけをわかりやすくしていく必要があるのではないかと考えています。
2点目が、脆弱性がどうなっているかを組織全体で管理したいということです。出てくる脆弱性はプロダクトごとに変わってくるので、組織全体ではどういう脆弱性を抱えているのかの問題であったり、新しく検出された脆弱性で、例えば新しく使い始めたパッケージに脆弱性があったというパターンもあるので、そういったものがどこまできちんと管理されているかの全体を把握していくのも、組織の統制という観点からは必要かと思います。
あとは、独自の脆弱性ごとにも評価をしていく必要があると思っています。CVSS(Common Vulnerability Scoring System)など、共通の企画で「この脆弱性はだいたいHigh severityです」とか、「この脆弱性はだいたいミドルです」ということがあります。
共通の公式によって求められた深刻度になるので、やはり組織ごとの事情に応じて「これは深刻だ」とか「これは別にそうでもない」というのは、ブレがけっこう大きくなってきます。そのため、そういったブレに対して、外部の評価を過度に考慮するだけではなく、なるべく自分たちで判断した内容を管理する必要があるのではないかと考えています。
この2つに関しては、既存の製品でカバーされているところが多いかと思っていて、そういったものを使っていく選択肢もありました。
しかし、3つ目の判定やCIの結果をなるべくカスタマイズしたいということは、けっこう難しいところです。もちろん既存のツールでも、例えば「この脆弱性は無視します」とか、「このパッケージに関しては無視します」というような、単純な1項目ごとの条件の判定ができるツールはけっこう多いです。
複数の条件を組み合わせて例外を発生させたり、あるいはリポジトリに合わせた対応、例えば外部に公開しているプロダクトであれば即座にやらなければいけないものの、外部のネットワークから切り離されて使っているプロダクトであれば、それほど猛ダッシュでやる必要はなかったりするということです。
そういった脆弱性の条件に関してもいろいろあるので、プロダクトの文脈をきちんと判断した上で、「これはすぐにやるべきだ」とか、「これはちょっと待ってもいい」という判断をする必要があると思っています。
こういうものをルールとしてきちんと記述できていないといけないのですが、先ほど少し言ったとおり、すごく細かい単一の条件を指定できるツールはたくさんありますが、全体的に自由に表現できるツールがなかなかなかったので、そこを含めてやるとなると、自分たちで用意したほうがよいということでやったのが今回の話です。
(次回に続く)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには