セキュリティ事故を防ぎたいなら知っておくべき、「DevSecOps」における推奨事項：GitHub直伝、「DevSecOps」初めの一歩（後）

ソフトウェアの開発スピードを迅速化させられるかどうかが重要になる一方、セキュリティの取り組みも欠かせません。そこで注目されているのが「DevSecOps」です。DevSecOpsを組織で推進するためには何から取り組めばよいのか紹介します。

[田中裕一，GitHub]

開発者ファーストのアプローチがセキュリティ強化に役立つ

　安全なアプリケーションやシステムを開発できるかどうかは、開発中のコードレビュープロセスにおいて、開発者がどれだけ多くの脆弱（ぜいじゃく）性を修正できるかどうかに依存しています。これは現在のソフトウェア開発における課題の一つです。

　そこで最近目にするのが「DevSecOps」です。前回記事では、DevSecOpsという言葉が生まれた背景、DevSecOpsの意味を解説しました。

　後編となる今回は、DevSecOpsを進めていくに当たってどのような取り組みが重要なのかを紹介します。2022年7月時点でDevSecOpsの正式なガイドラインはありませんが、企業や組織がDevSecOpsに取り組んでいく際、以下のような取り組みが重要になります。

開発部門とセキュリティ部門がお互いの認識をあらためる

　開発部門とセキュリティ部門が互いのことを「自分たち」と「彼ら」のように分けて考える認識をあらため、両部門が同じチームとして日常的にコラボレーションを促進する体制に変えましょう。そのために実践できる簡単なアクションとして、開発の早い段階でセキュリティ部門にも設計レビューに参加してもらうことが挙げられます。

　セキュリティ部門のメンバーがレビューをする場合、コードの内容ではなく、脆弱性を生み出しそうな設計になっていないか、脆弱性がないかという観点でチェックすることが大切です。

可能な限り自動化する

　ソースコード内における脆弱性や、脆弱な依存関係の検出は、適切なツールを利用して自動化することを推奨します。その際のツールの選定は、開発とセキュリティ双方の観点から検討します。開発の観点からは「十分な精度で脆弱性を検知してくれるのか」「現状の開発ワークフローを必要以上に複雑なものにしないか」「解析にはどのくらいの時間がかかるのか」を重視します。セキュリティの観点からは「必要な脆弱性がきちんと検出できるか」「複数のプロジェクトを横断して、どのような指摘が検出されているか、一望できるか」「指摘は適切に優先順位付けされているか」を重視しましょう。

開発フローにツールを組み込む

　セキュリティ観点でのチェックは、コードレビュー時の観点の一つとして組み込むという限定的な方法もあれば、CI/CD（継続的インテグレーション／継続的デリバリー）のプロセスに統合したワークフローを構築する、より大掛かりな方法もあります。どちらの方法を採るにせよ、選定したツールを実際の開発フローに組み込みましょう。

　これらの取り組みを推進することで、開発部門とセキュリティ部門の信頼関係はさらに強固なものになります。この信頼関係は、いつどこで脆弱性を解決するかに関わるだけではなく、どの結果を優先すべきか、誰が効果的に対処できるかなど、体制作りにも役立ちます。

ツール導入における注意点

　一方で、もし脆弱性を探知するためにセキュリティツールを導入したとしても、セキュリティツールの誤検知が多いと、本当は存在しない脆弱性の調査に時間を費やすことになってしまいます。開発者が脆弱性の対処に悪戦苦闘する最大の理由は、この高い誤検知率にあるという話を頻繁に聞きます。セキュリティ問題への対処のために作業が何度も中断され、そのたびに「誤検知だった」「本当は問題なかった」ということでは、開発者は開発に意識を集中させることが難しくなってしまいます。

　セキュリティにおける開発者ファーストのアプローチは、開発者のワークフローを途切れさせないことに重きを置く必要があります。DevSecOpsのゴールは「開発途中に正しく問題が特定され、その問題を素早く解決できるようになること」です。

　Facebookが開発のワークフローに高品質な静的解析ツールを追加したとき、それに伴うバグの修正率は70％という前例のない数字に達しました。しかし、開発のワークフローと関係ないところで問題のリストを開発者に提示したとき、バグの修正率は0％でした（Scaling Static Analyses at Facebook, Communications of the ACM, August 2019）。

　これは開発のワークフローの中で問題に優先順位を付け、最も重大な影響を及ぼすバグを報告することの重要性を浮き彫りにした例です。開発のワークフローに組み込まれれば、時間とともに修正される問題の数は増加します。これに加えて、問題を早い段階で報告することで、開発者はその問題を最後に対処する必要があるものと見なすのではなく、開発プロセスの一環として問題解決を図るようになります。

オープンソースの安全な利用

　近年開発されるアプリケーションにおいては、その90％以上でオープンソースのコードが利用されています。つまり、オープンソースの依存関係は既にコードベースの一部になっています。オープンソースに依存している場合、それらのコードの中に脆弱性が見つかっているか、もし見つかっている場合にはどのバージョンにどういった内容でどのくらい深刻な脆弱性が存在しているのか、どのバージョンでその修正が行われているのかなどといった情報を収集することが必須です。

　しかし、日々オープンソースはアップデートされていますし、依存するオープンソースの数が多い場合、こういった情報を人手で収集し続けるのも現実的ではありません。そのため、オープンソースコードに含まれる脆弱性を、プロアクティブかつ自動的に特定できる「ソフトウェアコンポジション解析」（SCA）ツールの利用が重要になります。

　SCAツールによる解析は、オープンソースを利用し始めるタイミングで行えばよいというものではありません。日々新たな脆弱性が見つかったり、昨日までは安全だと考えていたオープンソースに深刻な脆弱性が新たに見つかったりすることもあります。そういった場合に備えてあらゆるソフトウェア開発のプロジェクトに対して常時SCAツールによる解析を「継続的に実行し続けること」が大切です。

最後に

　セキュリティは、安全なアプリケーションやシステムをリリースする上で、開発、セキュリティ部門だけでなく、組織全体が取り組むべき問題です。効率的な新しいセキュリティツールを導入するだけでは不十分です。オープンソースの依存関係の管理から適切なバグの修正、顧客データの保護に至るまで、組織内で責任を共有し、あらゆるステップで安全性を確保するのがDevSecOpsの取り組みです。

　GitHubは「GitHub Advanced Security」を通じて、コミュニティー主導型かつ開発者ファーストのアプローチで、安全なアプリケーションの構築を支援しています。GitHub Advanced Securityでは、以下のような機能を提供しています。

• コードスキャニング：コードに存在する潜在的なセキュリティの脆弱性とコードエラーを自動で解析します
• シークレットスキャニング：リポジトリに記録されたシークレット（クレデンシャルやトークンなど）情報を検出します
• 依存関係のレビュー：GitHubでPull Requestをマージする前に、そのPull Requestで追加、変更しようとしている依存関係に既知の脆弱性があるか、どういったライセンスを使用しているかチェックを行います
• セキュリティオーバービュー：上記のようなGitHubのセキュリティ機能によって検知されたアラートをGitHub リポジトリや組織を横断して可視化します。セキュリティ部門が社内にリスクの高いリポジトリが存在しないかどうかを確認するのにも役立ちます

　2回にわたってお伝えした内容が、皆さんの組織で「DevSecOps」を推進する一助になれば幸いです。

筆者紹介

田中 裕一（たなか ゆういち）

GitHub シニアソリューションズエンジニア

大学院卒業後、企業向けパッケージ開発のソフトウェアエンジニアとしてキャリアをスタート。その後、Webサービス開発のソフトウェアエンジニア、プロダクトマネジャーを経て、2018年よりGitHubに所属している。著書・訳書に『Java最強リファレンス』（SBクリエイティブ）、『システム運用アンチパターン』（オライリー・ジャパン）がある。