KDDI株式会社様

脆弱性対策で開発スピードが向上、バージョンアップの習慣化がポイント

グローバルに活動の場所を広げる国内通信大手のKDDI様。同社のソフトウェア技術部では、セキュリティ対策として脆弱性管理クラウドyamoryを導入し、結果、開発スピードを向上させています。yamory導入の経緯や活用状況などについて、同社の谷村氏と加藤氏にお話をうかがいました。

KDDI株式会社様
個人向けの通信サービスやauブランドの展開、法人向け5G/IOT基盤の支援など、幅広い通信サービスを提供

業種　　　情報通信・ITサービス

従業員数　47,320人（連結ベース・2021年3月31日現在）

掲載日　　2022年6月

課題

• 年数回のセキュリティ監査では、アジャイル開発のスピード感に追いつかず、その間にセキュリティが通用しなくなる不安があった
• OSSの脆弱性管理は代表的なものにとどまり、その依存関係も把握できていなかった
• 脆弱性対応は、セキュリティを担当しているグループ会社からの通知や、ニュースなどで取り上げられた重大なもののみ対応していた

•  
• シンプルなUIがビジネスサイドでも理解しやすいため、開発サイドと一緒になって脆弱性リスクの解決に向かうことができる
• オートトリアージ機能により、何を初めに行うべきか分かりやすい
• Immediateは世の中的にも危険なものという認識がチーム内に浸透し、個人のセキュリティ意識の向上が確実に見られた
• Immediateが発生したら、すぐにバージョンアップして対応することが習慣化した
• アップデートの負債を貯めなくなり、細かくアップデートするようになることで相対的に開発スピードが向上した
•  

活用シーン

• GitHubにPushするビルドスクリプトの中で毎回スキャンを走らせている

• Immediateが検知されたら、ビルドパイプラインを止めてすぐに対応し、終わり次第リリース

谷村氏：
ソフトウェア技術部にて、2つの案件でスクラムマスターを担当しています。ソフトウェア技術部は、ビジネス側から依頼を受けてさまざまなプロダクト開発を行う部署となっていて、案件ごとにメンバーがアサインされます。

加藤氏：
私もプロダクトオーナーですが、実は普段は法人向けソリューションの担当としてシステムの提案などをしています。KDDIで新規にプラットフォームを立ち上げるプロジェクトを始めた際に「アジャイル開発でやりたい」という流れがあって、ここ2年間は谷村と同じプロジェクトで開発を進めてきました。

従来の大企業が新しいプロダクトを作る時には、付き合いのある大手SIerに外注することが多いと思います。しかし、障害が発生したときにはSIerに聞かないと分からないわけです。当初はKDDIもそういった状況が続いていました。

 

 

「自分たちのスキルを上げて、KDDIグループ全体で内製開発をしないといけない」という危機感を持ったメンバーが、2013年に5名で立ち上げたのがアジャイル開発センター（現在のソフトウェア技術部）です。今はメンバーも400人を超えて、40件ほどのプロダクトを進めています。

 

谷村氏：
基本的には企画、ソリューション担当部署のメンバーがPOとして、ユーザーからの声を聞きながらプロダクトの優先度を決めたり、何を作っていくのかを決めたりします。

開発体制はスクラムを基本にソフトウェア技術部で主導する形です。チームによってはカンバンなど自分たちに合う方法を試しており、それぞれが「守・破・離」を意識しながら開発しています。

 

谷村氏：

全般的な対策は、全社のセキュリティガバナンスを担当している部署と協力して進めています。会社としてのセキュリティガバナンスやAWS上でのガバナンス整備、侵入テストなどです。開発スタートのタイミングで、フォーマットにのっとりセキュリティ対策やセキュリティチェックを実施。その後は半期〜1年に1回のペースで監査を行ってきました。

しかし、アジャイル開発は変化が早いため、数年のスパンでは以前の対策が陳腐化して、現在のプロジェクトには適用できず、やり直しが発生することも出始めてきました。ちょうどそのタイミングでDevSecOpsがキーワードとして話題になり始めたため、まずは新しいことをやってみたいと思ったメンバーから自然とアジャイルに合わせたセキュリティ対策に取り組み始めたんです。

 

谷村氏：
非常に大きな課題を抱えていたというわけではなく、ボトムアップで始まった取り組みだったため、今思うとつたない部分も多かったかもしれません。それでも、セキュリティ対策が甘いのではないかという不安は少しずつ減っていきました。

 

谷村氏：
OSSを使って開発を進める中で、最初になんとなく「Nginx使うよ」、あるいは「log4jを使ってロギングするよ」などと決めて、リストを作る。ただ、そこでピックアップするのは本当に代表的なものだけなので、どんどんOSSを入れていくとどんどん依存関係が見づらくなってきます。新たなバージョンを適用して動作確認まではするけど、セキュリティは本当に大丈夫なのか気になってしまう。

セキュリティガバナンスの担当部署から「Apacheに重大な脆弱性の情報が出ている」といった連絡はタイムリーに来ており、セントラルとしての脆弱性サポートは信頼していますし、ニュースやTwitterでバズっているのをチェックもしています。それでも、そもそもライブラリの依存関係を網羅的に見れていないので、他に取ったほうがよい施策があるかもしれないという不安が残っていましたね。

 

谷村氏：
当時はDevSecOpsの話や、コードの品質の話がソフトウェア技術部でよく出るようになり、全体としていかにプロダクトの品質を守っていくのかを問題視するようになっていました。そこで、私と同じチームだった加藤が「チームメンバーがyamoryというサービスを気になっている」と教えてくれたんです。

他にもいくつか検討はしたのですが、開発チームからボトムアップで出てきたyamoryをまずは試してみようということになりました。そこで試用してみたところ、非常に分かりやすくシンプルなUIで、POである加藤にも見やすい。ビジネス側でも見やすく、オートトリアージによって何を最初にしないといけないのかもひと目で分かります。関わるみんなに優しいサービスだという印象を持ちました。

他のサービスでは、知識や知見のある技術者なら理解できるUIであっても、それをPOに対して「最優先で対応する必要がある」と説明する際に難しいと感じました。yamoryならPOもすぐに理解できます。非常に使いやすいということで、採用させていただきました。

 

 

加藤氏：
脆弱性が発見されたものの、次のバージョンは出ていない。ではどうするのか？といった具体的なコミュニケーションを私から取れるようになったことは大きいですね。技術者なら、より分かりやすいでしょう。

 

谷村氏：
他社製品とも比較しましたが、私たちの目的はPOとアジャイル開発チームがともに利用でき、脆弱性対策を加速しうるプロダクトの選定です。CIへの組み込みの手軽さや、横展開のしやすさ、ビジネスメンバーでも理解できるUIといった点にyamoryらしさを感じましたね。

 

谷村氏：
実は、導入ではほとんど苦労しなかったんです。ソフトウェア技術部は、新しい取り組みをするうえで必要なものであれば、きちんと予算を捻出して後押ししてくれます。「DevSecOpsをやってみたい、そこでこういうツールがある」という話をしたら、すぐ「いいんじゃない、入れてみてよ」という感じで申請が通り導入が決定しました。

また、チームからのボトムアップで採用したツールというのも大きかったです。メンバーも素直に受け入れてくれて、自分たちで使いこなす動きをしてくれています。

 

谷村氏：
GitHubへのプッシュ時に動作するビルドスクリプトの中に入れていて、毎回スキャンが走る形にしています。そこでImmediateがあったらすぐに対応し、終わったらリリースするというルールです。実際には、スキャン時にImmediateになることはほとんどないですね。

 

 

どちらかというと、Slack通知をもとに脆弱性の対応をすることが多いです。すでにスキャンしたものが、あるタイミングで攻撃手法が確立され、Immediateな脆弱性になりましたという連絡が来るわけです。

※Immediateは、危険度が高く、攻撃コードが流通し悪用可能な状態の脆弱性です。オートトリアージ機能について詳しくはこちら
オートトリアージ機能について | 使い方 | yamory - 脆弱性管理クラウド

 

加藤氏：
スキャンツリーにオレンジ（Delayed）のところがあれば警戒しようと認識し、それがImmediateになったら世の中的にも危険なものというイメージを持つことができています。その認識をPOと開発チーム内で共有できたので、Immediateの場合は最優先で脆弱性に対応するというルールを決めました。脆弱性リスクの3段階のレベル分けは対応もしやすいと思います。

 

谷村氏：
ビジネスの達成度よりも、セキュリティをおろそかにしたことで失うものの方が大きいと個人的に考えています。私たちがひとつセキュリティ上のミスを犯してインシデントが発生してしまうと、会社の信用を落としてしまう可能性があるわけです。運用ルールを決める際にはそのあたりを意識しましたし、加藤も同じ観点で考えてくれています。

加藤氏：
ビジネスへの影響を考えれば、決断しやすいです。その意味でも、yamoryは状況を把握しやすいですし、ビジネス側とエンジニアの橋渡し、共通言語になるというメリットがあります。

谷村氏：
個人やチーム全体で、セキュリティへの意識向上が確実にみられたことも良い効果でした。そのおかげで、パッケージのアップデートをあまり怖がらなくなりましたね。最新のパッケージを取ってくることもセキュリティ上の効果が高いと分かっているので、あとは動作さえすればいいという感じになっています。

また、開発スピードが上がったのも良かったです。なんとなく後回しにして溜めたアップデートを一気に実施する状況から、少しずつ都度対応するという形に変化したことで、結果的に開発スピードが上がったのは思わぬメリットですね。

 

 

加藤氏：
部長陣の予算の取り方が非常にうまく、ボトムアップでのアイデアにすぐ予算をつけられるのは、本当にすごいですよね。

谷村氏：
開発スピードを上げていく、プロダクトの品質を上げていくところに寄与するのがソフトウェア技術部という認識があって、全社のDXを推進していくことがミッションになっています。

さらに2022年5月にはその機能とノウハウが「KDDIアジャイル開発センター株式会社」という新会社としてスピンアウトし、社内だけでなくKDDIグループ全体に先進的な開発・セキュリティ体制を展開できる仕組みが整いました。

ボトムアップの取り組みと会社の成長戦略がマッチすると、こんなにもスピーディーに新しい取り組みが進められるのだと実感しています。

 

谷村氏：
加藤とは別の案件ですが、サーバーホストがでてくるものがあります。yamoryのホストスキャン機能を利用して、アプリケーション内部のOSSに加え、サーバーホスト内部のMW・OSの脆弱性についても一貫性をもったセキュリティ対策をしていこうと考えています。まだ開発中なので、セキュリティのスキャンまではできていませんが、リリースまでには入れられたらいいなと考えています。

 

加藤氏：
私はプロダクトの目線なので技術に詳しくないですし、実際そうやって敬遠してしまう方も多いと思います。そこで怖がらず、見やすいUIにこだわっていけば、意外に意見や優先順位を決められるようになるものです。そういったところから一歩踏み出していただきたいですね。

谷村氏：
セキュリティはスピードが重要です。脆弱性対策においても、積もったものを一気に対応する従来のやり方では疲弊してしまい、新しいものにチャレンジすることが億劫になりがちです。新しいものを取り入れて、自分たちでセキュリティを回していく、その両輪が重要なのではないでしょうか。

セキュリティ対策をしないという選択肢はないですし、yamoryに関しては導入が非常に楽なので、躊躇しているのであれば、まずはスピーディーにやってみるのもおすすめです。