重要なポイント

• DevSecOpsは、DevOpsの拡張であり、セキュリティの懸念を開発プロセスの早い段階に移すことに重点を置いています。
• 「シフトレフト」とは、セキュリティを考慮し、開発プロセスを前倒しして実施するという概念です。
• DevSecOpsは、セキュリティへの配慮を開発の最後まで残しておくことで生じる摩擦や手戻りを減らすことを目指しています。
• DevSecOpsは、開発、運用、およびセキュリティがビジネスゴールに沿って連携し、より効率的なイノベーションを実現するための画期的な手段です。
• DevSecOpsは、作業原則の集合体です。ソフトウェアコンポジション解析や、安全なコンポーネント管理に関連しており、1つのツールや手順というよりも、組織が連携する手段に関するものです。

一言で言うと？

Dev.Sec.Ops.

上記の言葉を聞いたことがありますか？そうでない場合、あなただけではありません。DevSecOpsの基本的な前提は、話す相手によって異なる名前で呼ばれていることもあります（Rugged DevOps、SecDevOpsなど）。

では、DevSecOpsとは一体どういう意味なのでしょうか？まず知っておかなければならないのは、DevSecOpsの「sec」はセキュリティを意味するということでしょう。

多くの企業にとって、DevOpsの考え方を導入することは、ソフトウェア開発チームとIT運用チームの間の「ギャップを埋める」、つまり「サイロ化を防ぐ」ことであり、多くの場合、より速く、より安定したソフトウェアをリリースできるようになることを目的としています。

DevSecOps は、DevOps の概念を拡張したものであり、ソフトウェア開発ライフサイクル（SDLC）の中で「セキュリティを（つまり、より早い時期に）シフトレフトする」というキャッチフレーズで紹介されることがよくあります。セキュリティレビューや検査は、緩和措置が必要な発見があった場合、実施するのがより困難でコストがかかるサイクルの終盤に取り組むよりも、より効率的に実施することができるのです。

実際、DevSecOpsの背後にある原則、すなわち品質をソースに近づけ続けることは、「The DevOpsハンドブック」で述べられているように「DevOpsの第二の道（フィードバック）」の重要な信条でもあります。

“複雑なシステムでは、検査プロセスや承認プロセスを増やすと、かえって将来の不具合の可能性が高まります。意思決定を作業現場から遠ざけると、承認プロセスの有効性が低下します。そうすると、意思決定の質が下がるだけでなく、サイクルタイムが長くなるので、原因と結果のフィードバックの強度が低下し、成功と失敗から学ぶ能力が低下するのです。”

1. Edwards Demingは、エンジニア、統計学教授、経営コンサルタントであり、米国で「総合品質管理（TQM)」を立ち上げるきっかけとなったことでよく知られていますが、同じ考えを（ずっと以前に）「ビジネスの有効性を変革するための（14の）主要経営原則」の3番目に提唱しています。

“品質を実現するための検査への依存をやめましょう。そもそも製品に品質を作り込むことで、大規模な検査を不要にするのです。”

原則は必ずしも実践と一致しない

こういった原則は目新しいものではなく、理論的には非常にわかりやすいと思われますが、実際には多くの組織がこのように運用されていないのが現状です。

組織でセキュリティが優先される場合、多くの場合、何らかのコンプライアンスのための最低限の基準を達成することを目的としており、通常、セキュリティチームの人数は不足しています。

DZoneの記事「DevOpsにセキュリティを組み込むための10のヒント」の中で、Gene Kimはこの課題について以下のように述べています。

 

“一般的な技術系組織では、開発、運用、情報セキュリティのエンジニアの比率は、100：10：1です。これだけ情報セキュリティが劣勢になると、自動化や情報セキュリティを開発・運用の日常業務に組み入れなければ、情報セキュリティはコンプライアンスチェックしかできず、セキュリティエンジニアとは真逆の仕事になってしまい、しかもみんなに嫌われてしまいます。”

このシナリオの1つの例として、 The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Winという書籍が挙げられます。この小説では、あまり人気がなく、バインダーを持ち歩く最高情報セキュリティ責任者（CISO）の主人公であるジョンが、自分の会社がプロセス重視のセキュリティ管理に依存する必要なくSOX-404監査に合格したときに、実存の危機を経験することになります。

CISOのジョンは、自分の努力が会社の価値を高めていないことに気づき、悩んだ末に”灰の中から”立ち上がります。謙虚になり、自分の役割が会社のビジネス目標の達成にどう役立つかを理解しようとし、ソフトウェア開発部門やIT運用部門とより協力し、彼らの仕事をどうすれば楽にできるかを把握し始めたのです。やがて、開発部門、運用部門、情報セキュリティ部門の3者が協力して共通のビジネス目標に取り組み始め、その過程でより俊敏になり、可能な限り労力とセキュリティリスクを削減するために自動化を進めるようになりました。

 

文化の転換-双方向に

Computer Business Reviewのインタビューで、SonatypeのCTOであるBrian Foxは、DevOpsとDevSecOpsの領域で起きているシフトについて、自身の考えを述べています。

“私たちが市場で目にするのは、今日のお客様の最大の課題は、すべてのプロセスオーナーに、自分たちが置かれているレガシープロセスの枠にとらわれない考え方を身につけさせるために必要な文化的変革であることが多いということです。”

DevSecOpsの創設者の1人であるIntuitのShannon Lietzは、devsecops.orgに投稿したDevSecOpsとは？というブログ記事で、「… DevOpsの変化が進行する中、従来のセキュリティはもはや選択肢ではありません」とその気持ちを代弁しています。Lietzは以下のように述べています。

“DevSecOpsの目的と意図は、「全員がセキュリティに責任を持つ」という考え方をベースに、必要な安全性を犠牲にすることなく、スピードとスケールで最高レベルのコンテキストを持つ人たちにセキュリティの決定を安全に分散させることです。”

DevSecOpsを協調的な規律として考える場合、アプローチを成功させるための重要な要素は、多くの場合、シフトレフトに伴う組織の文化的な考え方の転換にあります。

The DevOpsハンドブックの著者もこれに同意しています。

“これを行うことで、品質が別の部門の責任であるのとは対照的に、本当に全員の責任となるのです。情報セキュリティは情報セキュリティだけの仕事ではなく、アベイラビリティはオペレーションだけの仕事ではないように。”

Sonatypeでは、DevSecOpsのアプローチとして、最初のオープンソースコンポーネントの選択からアプリケーションの構築、ステージング、リリースまで、DevOpsパイプラインのすべてのステージにセキュリティ対策を統合し、シフトレフトやシフトライトを繰り返しながらも「品質を作り込む」ことを掲げています。

SDLCのすべての段階にセキュリティを統合している場合、以下のようなことも行っています。

• 新規および既存のレガシーアプリケーションにおけるオープンソースコンポーネントのリスクのスキャンと評価
• 「悪質な」OSSコンポーネントがエコシステムに入り込むことへの防止
• 運用中のすべてのアプリケーションの継続的監視/アプリケーションに影響を与える脆弱性が発生した場合、開発チームに警告を発動

それでは、Sonatypeのミッションの中心であるdevsecops.orgのDevSecOpsマニフェストを抜粋してご紹介します。

“セキュリティをコードとして開発することで、優れた製品やサービスを生み出すことに努め、開発者に直接インサイトを提供し、一般的に、導入前に常に最善の答えを導き出すことよりも、反復を優先するように努めます。当社は、セキュリティとコンプライアンスをサービスとして利用できるようにするために、開発者のように活動します。新しい道を切り開き、他の人のアイデアが現実のものとなるよう支援します。”

 

 

デフサムライは、Sonatypeのゴールドパートナーとして日本国内で同社製品を販売し、インストール、設定、テクニカルサーポートなどの導入支援サービスを提供しています。