「DevSecOps」って何？ GitHubが考える全ての組織が開発スタイルとして取り入れるべき理由：GitHub直伝、「DevSecOps」初めの一歩（前）
企業のビジネスにソフトウェアが欠かせない今、ソフトウェアの開発スピードを迅速化させられるかどうかが重要になる一方、セキュリティも欠かせない要素です。そこで最近目にするのが「DevSecOps」というキーワードです。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
はじめに
企業のビジネスにソフトウェアが欠かせない今、ソフトウェアの開発スピードを迅速化させられるかどうか、いわゆる「DevOps」の実現が重要になっています。一方、開発スピードの向上と同時に考えていかなければならないのがセキュリティです。迅速かつ効率的にソフトウェアをリリースできても、セキュリティの問題で顧客に影響が出れば、顧客満足度の低下、企業ブランドの価値毀損（きそん）につながりかねません。
とはいえDevOpsは決して新しい考え方ではなく、ソフトウェアを迅速に提供するための開発スタイルとしてITエンジニアの間で広く知られています。DevOpsでは、開発チームと運用チームがコラボレーションすることで、より信頼性の高いソフトウェアを迅速にリリースすることを目指しています。
そうした中で最近、DevOpsと関連して「DevSecOps」という言葉を目にした方もいると思います。今回は2回に分けて、DevSecOpsとはどのような考え方なのか、組織でDevSecOpsの文化を広めるためにどう取り組んでいけばよいのか解説していきます。
全員が責任を負う――「DevOps」という言葉が生まれた背景
DevOpsという言葉が生まれたのは2008年。システム管理者のPatrick Debois氏とソフトウェア開発者のAndrew Clay Shafer氏が、運用チームと開発チームの間の隔たりをなくすことを目的として結成したワーキンググループにまでさかのぼります。そこで誕生したベストプラクティスのプロセスが現在のDevOpsとして知られています。
これ以前の2000年代半ばまでは、開発チーム、品質保証チーム、IT運用チームが連携しておらず縦割りで作業することが一般的でした。開発チームはソースコードを書くことのみに責任を持ち、品質保証チームはそのコードをテストして一定の品質を満たしていることを保証することに責任を持ち、IT運用チームは本番環境にコードをデプロイし、そのソフトウェアを安定して運用することに責任を持っていました。
こういった状況では、運用しているソフトウェアに問題が起きた際、その問題を誰が調査、修正するかについて責任の所在を巡って議論が発生してしまいます。その結果、問題が修正されるまでに時間がかかったり、ソースコードを修正したりすべきものに対して運用チームが対症療法的な修正をするにとどまってしまい、同様の問題が何度も再発するという事態を招いてしまいます。
こういった状況を受けて、DevOpsでは、開発チーム、品質保証チーム、IT運用チームが運用するソフトウェアに共同で責任を持ちます。そのため、職務の垣根を越えてコラボレーションし、開発の早い段階から品質保証や運用の観点でのテストやフィードバックをすることで、品質の高いソフトウェアを迅速に提供することが可能になります。これと同じ考え方をセキュリティにも拡張するというのがDevSecOpsなのです。
従来、セキュリティチームが関わるのはソフトウェアをデプロイする直前段階であることが一般的でした。それまで、セキュリティチームがソフトウェアに関わることはありませんでした。その結果、セキュリティチームによるテストで問題が発見された場合、多大なプロセスのやり直しが必要で、修正には時間がかかり、関係する全ての人にとって不満がたまりやすいものでした。また修正に時間がかかり過ぎるため、付け焼き刃の修正にとどめることも起きやすくなり、同じような問題が何度も再発することに悩まされることもありました。
こうした状況を改善していく取り組みがDevSecOpsです。
DevSecOps：DevOpsの原則をセキュリティに適用
ソフトウェア開発において、セキュリティの確認は最後の工程に行うのが一般的でしょう。リリース前にセキュリティに問題がないかどうかチェックする最後の項目というイメージです。通常、開発者は開発に注力し、セキュリティの責任はセキュリティチームに任せています。こういった縦割りのワークフローを続けていては、開発スピードは上がりません。ソフトウェアのセキュリティでビジネスが阻害されないようにするには、開発プロセス内でセキュリティが果たす役割を、根本から変える必要があります。
DevSecOpsは、プロセスのあらゆる場所にセキュリティを組み入れることで、セキュリティをより適切に開発体制や開発方式に統合するスタイルです。セキュリティを開発関係者全体の責任にすることで、セキュリティが開発プロセスに深く根付き、より信頼性の高いソフトウェアをさらに迅速にリリースできるようになります。その波及効果として、組織がイノベーションを生み出す能力の向上も考えられるでしょう。
DevSecOpsとDevOpsの違い、ポイントは「セキュリティのシフトレフト」
では、DevSecOpsが成功する環境は、どのようにして作られるのでしょうか。
DevSecOpsを成功させ、さまざまな関係者でソフトウェアに共同で責任を持つようにするには、開発ライフサイクルの早い段階にあらゆるプロセスをシフトレフト（注：開発ライフサイクルを左から右に時系列に並べた場合、これまでにサイクルの終盤、つまり右側で行われていた取り組みをサイクルの初期、つまり左側にシフトすることを指す）する必要があります。
DevSecOpsの考え方は、DevOpsチームがセキュリティをソフトウェア開発ライフサイクルの一環としてどのように認識し、受け入れるかという点で考え方の転換をもたらします。セキュリティテストとレビューをシフトレフトし、ソフトウェア開発の全ステップに効果的に組み入れることを意味しています。
セキュリティのシフトレフトは、ユーザーに影響を及ぼす前にセキュリティバグを発見し、新たに発見されたセキュリティバグへの対処と修正を迅速化できるようにするために重要です。セキュリティをゲートとして機能させる代わりに、開発ライフサイクルの全てのステップにセキュリティテストを統合することで、開発チームは問題を早期に見つけることができるようになります。
開発者中心のアプローチを採用することで、修正の際にも開発者の記憶が新しいうちにコードを修正できます。これがデプロイの数日後またはペネトレーションテストレポートが提出される数カ月後に初めてセキュリティバグが報告される場合と比較すると大きな効果があることは明らかです。
DevSecOpsは運用環境で発生する脆弱（ぜいじゃく）性を減らすことを目的としていますが、それだけではなく過度な負担がかかっているセキュリティチームの負荷を軽減することも目的としています。セキュリティ専門チームは、常に人材不足に悩まされており、全てのセキュリティに関する問題をチーム単独で対処するには限界に来ているでしょう。実際、セキュリティリサーチャーの数は、開発者と比較して平均で500分の1に過ぎないと推定されている調査もあります。
まとめ
DevSecOpsがもたらす新たな開発文化、スタイルにより、開発者がセキュリティに責任を持つようにすることで、開発、運用、セキュリティの各チームがセキュリティ問題をより迅速に見つけて修正できるようになるでしょう。
開発者は開発ライフサイクルの終盤にセキュリティチームが対処するのを待つのではなく、コード作成時にセキュリティの脆弱性を見つけて対処できるように変わっていきます。しかし、手作業だけでセキュリティの問題やソースコード上の問題を確認することは不可能といっても過言ではありません。
セキュリティチームが持っていた知識、ノウハウを開発チームに共有した上で、さまざまなツールを駆使することで、開発者は自ら一般的な問題へ対処できるようになり、セキュリティのエキスパートは一番必要とされているところに時間を集中させることができます。
後編では、DevSecOpsを進めていくに当たっての第一歩として、どのようなツールや考え方で進めていけばよいのか紹介していきます。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。