脆弱性対策で開発スピードが向上、バージョンアップの習慣化がポイント - KDDI株式会社
右：DX 推進本部 DX・IoT ソリューション部 1グループ コアスタッフ 加藤拓樹 氏
(2022 年 6 月現在)
KDDI 株式会社
業種：情報通信・IT サービス
事業概要：個人向けの通信サービスや au ブランドの展開、法人向け 5G/IOT 基盤の支援など、幅広い通信サービスを提供
従業員数：47,320 人（連結ベース：2021 年 3 月 31 日現在）
グローバルに活動の場所を広げる国内通信大手の KDDI。同社のソフトウェア技術部では、セキュリティ対策として脆弱性管理クラウド yamory を導入し、結果、開発スピードを向上させています。yamory 導入の経緯や活用状況などについて、同社の谷村氏と加藤氏にお話をうかがいました。
※本インタビューの情報は、2022 年 6 月現在のものとなります。
💡 課題背景
- 年数回のセキュリティ監査では、アジャイル開発のスピード感に追いつかず、その間にセキュリティが通用しなくなる不安があった
- OSS の脆弱性管理は代表的なものにとどまり、その依存関係も把握できていなかった
- 脆弱性対応は、セキュリティを担当しているグループ会社からの通知や、ニュースなどで取り上げられた重大なもののみ対応していた
🙌 導入の決め手・導入効果
- シンプルな UI がビジネスサイドでも理解しやすいため、開発サイドと一緒になって脆弱性リスクの解決に向かうことができる
- オートトリアージ機能により、何を初めに行うべきか分かりやすい
- Immediate は世の中的にも危険なものという認識がチーム内に浸透し、個人のセキュリティ意識の向上が確実に見られた
- Immediate が発生したら、すぐにバージョンアップして対応することが習慣化した
- アップデートの負債を貯めなくなり、細かくアップデートするようになることで相対的に開発スピードが向上した
🖥 活用シーン
- GitHub に Push するビルドスクリプトの中で毎回スキャンを走らせている
- Immediate が検知されたら、ビルドパイプラインを止めてすぐに対応し、終わり次第リリース
400 名超で 40 件ほどのプロダクトを開発する、ソフトウェア技術部
――お 2 人の自己紹介をお願いします。
谷村氏：
ソフトウェア技術部にて、2 つの案件でスクラムマスターを担当しています。ソフトウェア技術部は、ビジネス側から依頼を受けてさまざまなプロダクト開発を行う部署となっていて、案件ごとにメンバーがアサインされます。
加藤氏：
私もプロダクトオーナーですが、実は普段は法人向けソリューションの担当としてシステムの提案などをしています。KDDI で新規にプラットフォームを立ち上げるプロジェクトを始めた際に「アジャイル開発でやりたい」という流れがあって、ここ 2 年間は谷村と同じプロジェクトで開発を進めてきました。
従来の大企業が新しいプロダクトを作る時には、付き合いのある大手 SIer に外注することが多いと思います。しかし、障害が発生したときには SIer に聞かないと分からないわけです。当初は KDDI もそういった状況が続いていました。
「自分たちのスキルを上げて、KDDI グループ全体で内製開発をしないといけない」という危機感を持ったメンバーが、2013 年に 5 名で立ち上げたのがアジャイル開発センター（現在のソフトウェア技術部）です。今はメンバーも 400 人を超えて、40 件ほどのプロダクトを進めています。
――ビジネス側の要望により近い他部署のメンバーを PO に迎え、ひとつのスクラムチームを率いる形なのですね。
谷村氏：
基本的には企画、ソリューション担当部署のメンバーが PO として、ユーザーからの声を聞きながらプロダクトの優先度を決めたり、何を作っていくのかを決めたりします。
開発体制はスクラムを基本にソフトウェア技術部で主導する形です。チームによってはカンバンなど自分たちに合う方法を試しており、それぞれが「守・破・離」を意識しながら開発しています。
アジャイル開発における、プロダクトのセキュリティ対策
――これまでは、どのようなセキュリティ対策を行ってきたのでしょうか？
谷村氏：
全般的な対策は、全社のセキュリティガバナンスを担当している部署と協力して進めています。会社としてのセキュリティガバナンスや AWS 上でのガバナンス整備、侵入テストなどです。開発スタートのタイミングで、フォーマットにのっとりセキュリティ対策やセキュリティチェックを実施。その後は半期〜1 年に 1 回のペースで監査を行ってきました。
しかし、アジャイル開発は変化が早いため、数年のスパンでは以前の対策が陳腐化して、現在のプロジェクトには適用できず、やり直しが発生することも出始めてきました。ちょうどそのタイミングで DevSecOps がキーワードとして話題になり始めたため、まずは新しいことをやってみたいと思ったメンバーから自然とアジャイルに合わせたセキュリティ対策に取り組み始めたんです。
――アジャイルで DevOps には取り組んでいて、その流れで自然と DevSecOps にたどり着いた。
谷村氏：
非常に大きな課題を抱えていたというわけではなく、ボトムアップで始まった取り組みだったため、今思うとつたない部分も多かったかもしれません。それでも、セキュリティ対策が甘いのではないかという不安は少しずつ減っていきました。
――スクラムマスターとして、具体的にはセキュリティにどのような不安があったのでしょうか？
谷村氏：
OSS を使って開発を進める中で、最初になんとなく「Nginx 使うよ」、あるいは「log4j を使ってロギングするよ」などと決めて、リストを作る。ただ、そこでピックアップするのは本当に代表的なものだけなので、どんどん OSS を入れていくとどんどん依存関係が見づらくなってきます。新たなバージョンを適用して動作確認まではするけど、セキュリティは本当に大丈夫なのか気になってしまう。
セキュリティガバナンスの担当部署から「Apache に重大な脆弱性の情報が出ている」といった連絡はタイムリーに来ており、セントラルとしての脆弱性サポートは信頼していますし、ニュースや Twitter でバズっているのをチェックもしています。それでも、そもそもライブラリの依存関係を網羅的に見れていないので、他に取ったほうがよい施策があるかもしれないという不安が残っていましたね。
選定ポイントは、PO・ビジネスサイドへのわかりやすさだった
――さまざまなソリューションやツールがある中で、その解決策として yamory を導入した決め手を教えてください。
谷村氏：
当時は DevSecOps の話や、コードの品質の話がソフトウェア技術部でよく出るようになり、全体としていかにプロダクトの品質を守っていくのかを問題視するようになっていました。そこで、私と同じチームだった加藤が「チームメンバーが yamory というサービスを気になっている」と教えてくれたんです。
他にもいくつか検討はしたのですが、開発チームからボトムアップで出てきた yamory をまずは試してみようということになりました。そこで試用してみたところ、非常に分かりやすくシンプルな UI で、PO である加藤にも見やすい。ビジネス側でも見やすく、オートトリアージによって何を最初にしないといけないのかもひと目で分かります。関わるみんなに優しいサービスだという印象を持ちました。
他のサービスでは、知識や知見のある技術者なら理解できる UI であっても、それを PO に対して「最優先で対応する必要がある」と説明する際に難しいと感じました。yamory なら PO もすぐに理解できます。非常に使いやすいということで、採用させていただきました。
――PO の加藤様とアジャイル開発チームが一体となって、脆弱性について議論できているんですね。
加藤氏：
脆弱性が発見されたものの、次のバージョンは出ていない。ではどうするのか？といった具体的なコミュニケーションを私から取れるようになったことは大きいですね。技術者なら、より分かりやすいでしょう。
――比較候補に BlackDuck があったとうかがっていますが、違いはありましたか？
谷村氏：
BlackDuck の特徴は、エンジニア向けに最適化された管理画面と多機能さにあります。一方で、私たちの目的は PO とアジャイル開発チームがともに利用でき、脆弱性対策を加速しうるプロダクトの選定です。CI への組み込みの手軽さや、横展開のしやすさ、ビジネスメンバーでも理解できる UI といった点に yamory らしさを感じましたね。
CI 連携と Slack 通知機能で活用
――yamory の導入で苦労した点を教えてください。
谷村氏：
実は、導入ではほとんど苦労しなかったんです。ソフトウェア技術部は、新しい取り組みをするうえで必要なものであれば、きちんと予算を捻出して後押ししてくれます。「DevSecOps をやってみたい、そこでこういうツールがある」という話をしたら、すぐ「いいんじゃない、入れてみてよ」という感じで申請が通り導入が決定しました。
また、チームからのボトムアップで採用したツールというのも大きかったです。メンバーも素直に受け入れてくれて、自分たちで使いこなす動きをしてくれています。
――以前登壇されていたイベントで、CI に組み込んで、常にスキャンが回るような仕組みにしているとお話をされていました。
谷村氏：
GitHub へのプッシュ時に動作するビルドスクリプトの中に入れていて、毎回スキャンが走る形にしています。そこで Immediate があったらすぐに対応し、終わったらリリースするというルールです。実際には、スキャン時に Immediate になることはほとんどないですね。
どちらかというと、Slack 通知をもとに脆弱性の対応をすることが多いです。すでにスキャンしたものが、あるタイミングで攻撃手法が確立され、Immediate な脆弱性になりましたという連絡が来るわけです。
※Immediate は、危険度が高く、攻撃コードが流通し悪用可能な状態の脆弱性です。オートトリアージ機能について詳しくはこちら
オートトリアージ機能について | 使い方 | yamory - 脆弱性管理クラウド
――ビジネス側にセキュリティリスクの重要性が伝わらず、対策が進まないという話をよく聞きますが、yamory の画面をビジネス側の人と一緒に見ることでそこに貢献できていますか？
加藤氏：
スキャンツリーにオレンジ（Delayed）のところがあれば警戒しようと認識し、それが Immediate になったら世の中的にも危険なものというイメージを持つことができています。その認識を PO と開発チーム内で共有できたので、Immediate の場合は最優先で脆弱性に対応するというルールを決めました。脆弱性リスクの 3 段階のレベル分けは対応もしやすいと思います。
チーム全体のセキュリティへの意識向上と、開発スピードが上がったことが導入効果
――yamory を導入した効果や、メリットを感じている部分について教えてください。
谷村氏：
ビジネスの達成度よりも、セキュリティをおろそかにしたことで失うものの方が大きいと個人的に考えています。私たちがひとつセキュリティ上のミスを犯してインシデントが発生してしまうと、会社の信用を落としてしまう可能性があるわけです。運用ルールを決める際にはそのあたりを意識しましたし、加藤も同じ観点で考えてくれています。
加藤氏：
ビジネスへの影響を考えれば、決断しやすいです。その意味でも、yamory は状況を把握しやすいですし、ビジネス側とエンジニアの橋渡し、共通言語になるというメリットがあります。
谷村氏：
個人やチーム全体で、セキュリティへの意識向上が確実にみられたことも良い効果でした。そのおかげで、パッケージのアップデートをあまり怖がらなくなりましたね。最新のパッケージを取ってくることもセキュリティ上の効果が高いと分かっているので、あとは動作さえすればいいという感じになっています。
また、開発スピードが上がったのも良かったです。なんとなく後回しにして溜めたアップデートを一気に実施する状況から、少しずつ都度対応するという形に変化したことで、結果的に開発スピードが上がったのは思わぬメリットですね。
ビジネスとエンジニアが手を取り、スピーディーな DevSecOps の仕組みを作る
――御社のケースは、ボトムアップから始まったセキュリティ対策がうまくいった事例といえそうですね
加藤氏：
部長陣の予算の取り方が非常にうまく、ボトムアップでのアイデアにすぐ予算をつけられるのは、本当にすごいですよね。
谷村氏：
開発スピードを上げていく、プロダクトの品質を上げていくところに寄与するのがソフトウェア技術部という認識があって、全社の DX を推進していくことがミッションになっています。
さらに 2022 年 5 月にはその機能とノウハウが「KDDI アジャイル開発センター株式会社」という新会社としてスピンアウトし、社内だけでなく KDDI グループ全体に先進的な開発・セキュリティ体制を展開できる仕組みが整いました。
ボトムアップの取り組みと会社の成長戦略がマッチすると、こんなにもスピーディーに新しい取り組みが進められるのだと実感しています。
――次はどんな新しいことに取り組むのか、ぜひおうかがいしたいです。そのとき yamory に期待したいことはありますか？
谷村氏：
加藤とは別の案件ですが、サーバーホストがでてくるものがあります。yamory のホストスキャン機能を利用して、アプリケーション内部の OSS に加え、サーバーホスト内部の MW・OS の脆弱性についても一貫性をもったセキュリティ対策をしていこうと考えています。まだ開発中なので、セキュリティのスキャンまではできていませんが、リリースまでには入れられたらいいなと考えています。
――最後に、DevSecOps に取り組んでいる方たちに、アドバイスをお願いします。
加藤氏：
私はプロダクトの目線なので技術に詳しくないですし、実際そうやって敬遠してしまう方も多いと思います。そこで怖がらず、見やすい UI にこだわっていけば、意外に意見や優先順位を決められるようになるものです。そういったところから一歩踏み出していただきたいですね。
谷村氏：
セキュリティはスピードが重要です。脆弱性対策においても、積もったものを一気に対応する従来のやり方では疲弊してしまい、新しいものにチャレンジすることが億劫になりがちです。新しいものを取り入れて、自分たちでセキュリティを回していく、その両輪が重要なのではないでしょうか。
セキュリティ対策をしないという選択肢はないですし、yamory に関しては導入が非常に楽なので、躊躇しているのであれば、まずはスピーディーにやってみるのもおすすめです。