それは単に言葉の問題のように思えるかもしれませんが、言葉の順序はすべてを語るものです。セキュリティへの対処に関して、どのように文化を変えていけばいいのでしょうか。まずなによりも、セキュリティにしかるべき重点を置き、セキュリティを作り込むことから始めなければなりません。
DevOpsとセキュリティがソフトウェア組織にとって最優先事項であることは間違いありません。セキュリティをDevOpsに統合した結果、 SecDevOpsおよびDevSecOpsという言葉が作られました。どちらも同じものとして使用されていますが、単語の順序の違いは重要です。なぜでしょうか？セキュリティは依然としてデプロイメントプロセスの最後に「後付け」されることがほとんどだからです。この記事では、セキュリティを開発の不可分の要素とし、デリバリーパイプラインの最後のゲートとしてではなく、ソフトウェア開発プロセスの開始時から組み込むことで、安全なソフトウェアのデリバリーがどれほど容易になるかについて説明します。
DevSecOpsのセキュリティ
セキュリティへの関心は高まるいっぽうですが、セキュリティをプロセスとパイプラインに組み込むことは容易ではありません。スケジュール通りかつ予算内でプロジェクトを完成させなければならないというプレッシャーは、しばしば他のすべてに優先します。結果として、以下に示すように、セキュリティはリリース候補が通る最後の関門として追加される傾向があります。
従来のDevSecOps型のセキュリティへの取り組み
通常、セキュリティに関する知識を持っているのは組織内の少数の個人に限られており、その人たちが専任のセキュリティチームにまとめて配属されることがよくあります。セキュリティチームに期待されているのは、デプロイメントの前にリリース候補の脆弱性を見つけるため、彼らが持つ「魔法の箱」によって製品をテストすることです。セキュリティチームが脆弱性を発見すると、必然的に、開発チームに「悪い知らせ」が送り返されることになります。しかし、開発チームはセキュリティに関するトレーニングを受けていませんし、セキュリティチームが使用しているツールの使い方も知らないので、彼らの目には、セキュリティチームが「よくわからないセキュリティ脆弱性」を理由としてリリースを差し止める「悪い奴」と映ることがよくあります。そうなると、チームはどのように反応するでしょうか？
従来のアプローチは、リリースの遅延/本番環境でのセキュリティ脆弱性発見につながる
事実に目を向けましょう。開発チームにしてみれば「すっかりできあがった」プロジェクトに、重要なセキュリティの修正、管理、コーディング標準を入れ込むのは困難です。すると何が起きるでしょうか？製品は、既知の、および未知のセキュリティ上の脆弱性を抱えたまま、おそらくは「次のリリースで修正する」という約束つきで送り出されます。これがセキュリティを開発の後に置いた場合 －「Dev」、「Sec」、そして「Ops」の場合 －の結果です。誰もそうしたいと意図しているのではありませんが、これが多くの組織での現実です。どうぞ次に説明するより良いアプローチを検討してください。
SecDevOpsのセキュリティ
セキュリティ管理策、ガイドライン、コーディング標準、およびポリシーは、ソフトウェア開発プロセスに完全に統合されている必要があります。これは、セキュリティを最初からプロセスとパイプラインの一部にすることによって実現されます。つまり、「Sec」、「Dev」、そして「Ops」の順になります。セキュリティチーム（あるいはセキュリティを専門とするアーキテクチャまたは上級開発者）が、必要なポリシーを事前に定義します。
ポリシーは、セキュアコーディング標準、安全でないAPIや脆弱な暗号化を回避するためのルール、静的および動的解析の実施方法、およびテストガイドラインなどで構成されます。目標は、開発者が日常業務の一環として、より安全なソフトウェアを目指すようになることであり、自動化はこれを実現するのに役立ちます。
自動化を利用すると、次の図のように、SecDevOps戦略に合わせてセキュリティ対策をシフトレフトできます。
開発の開始時にセキュリティが組み込まれるようになると、当然ながらチームのセキュリティ習熟度が上がり、パイプラインの終わりに発見されるセキュリティ脆弱性が少なくなります。
パイプラインを通過する脆弱性を調査し、根本原因分析の結果を使用してセキュリティポリシーとガイドラインを改善することができます – つまり、サイクルが進むほど結果が改善されます。
次の図のように、ポリシーの反復的な改善を推進すると、サイクル終盤での負荷はそれほど大きくはなりません。
このようなインクリメンタルで統合されたアプローチは、プロジェクトの最後にセキュリティ監査を後付けするよりもはるかに優れています。
実現方法
セキュリティを確保するために開発者に対する要求が増えるという事実を避ける方法はありませんが、この作業の影響をどのように管理するかによって、 オンタイムにリリースされ安全な製品と、リリースが遅延する安全でない製品との違いが生まれます。ここで重要なのは、セキュリティを既存の開発プロセスに統合することです。これは、CWE-互換性テストツールであるParasoft 製品を統合し、セキュリティを品質と全体的なワークフローの一部にすることによって実現できます。
セキュリティ重視のワークフローでセキュリティを品質の一部にする
ワークフローはセキュアコーディングポリシーから始まります。アーキテクトまたはリードエンジニアが（おそらくCERT、CWE、OWASP、UL-2900、またはPCI-DSSなどのコーディングガイドラインに基づいて）コンフィギュレーションを作成し、他のチーム メンバーはIDE内で直接コンフィギュレーションを活用します。これにより、開発者はコードをソース管理にコミットする前に自分のローカル マシンでチェックし、修正のコストが低く簡単な時期と場所でセキュリティの違反を見つけて修正できます。
その後、同じコンフィギュレーションを使用して、ビルドプロセスの一環として解析が実行されます。この包括的な解析は、開発者がローカルで修正したコードより大きな範囲をカバーしており、セーフティネットとして、安全でないコードが後続のステージにプロモートされないようにデリバリーパイプラインを制御します。
最後に、解析結果は集中型のレポートおよび分析ダッシュボードを介して開発者のIDEに送り返され、そこで進捗状況や行われた修正を追跡し、監査レポートをリアルタイムで生成できます。
完全なSecDevOpsワークフローは次のようになります。
マネージャーとセキュリティ担当者は、以下に示すように中央ダッシュボードでCWEなどのセキュリティ標準に基づいてプロジェクトを評価できます。
これらのダッシュボードは、トレンド情報を表示し、「プロジェクトは改善しているか、悪化しているか」、また「コードのどの部分で最も多くの問題が起きているか」などの疑問に答えます。
このような疑問に答えを出し、行動を起こすことで、開発チームはDevSecOpsからSecDevOpsに変わります。
まとめ
DevSecOpsとSecDevOpsは同じように使用されていますが、単語の順序は、単語が示唆するツール、テクニック、およびプロセスと同様に重要です。依然として、セキュリティは製品をリリースする前のアドオンまたはゲートプロセスとして置かれることが多くありますが、製品がリリースされる寸前にセキュリティ問題を解決するのは容易ではありません。SecDevOpsのようにセキュリティをシフトレフトすることが成功への鍵です。セキュリティは、各開発者の日々のワークフローの一部であり、ソフトウェアパイプラインに統合されていなければなりません。Parasoftは、SecDevOps（およびDevSecOps）の影響とリスクを軽減しながらセキュリティ制御とポリシーのシフトレフトを自動化し、セキュリティをパイプラインに組み込むのに役立ちます。
（この記事は、開発元Parasoft社 Blog 「Is it DevSecOps or SecDevOps?」2019年3月7日の翻訳記事です。）