開発速度（ベロシティ）はDevSecOpsの1つの柱です。自動化の力によって、DevSecOpsチームは開発者がコードを変更してから、その変更がデプロイされるまでの期間を劇的に短縮できます。その期間が評価尺度として用いられることもあります。「開発チームがコミットしてから4分でデプロイに移行できます」とか、「1日に6回デプロイを行います」といった具合に。
物事が迅速に進行することは好ましいことですが、DevSecOpsで迅速化を目指す理由を正しく認識しておく必要があります。
大きな飛躍
振り返ってみると、ソフトウェア工学に対する従来のアプローチは単純でした。ビジネスという観点から、顧客に価値を提供するソフトウェアの構築が常に目標でした。つまり、現状から出発して、顧客ニーズを満たすと思われるソフトウェアを構築すればいいという考え方です。
そのギャップを埋めるために、従来のウォーターフォール・モデルの手順を実行します。
- 要件収集
- 設計
- 実装
- テスト
- リリース
ものごとは思ったよりも少し長い時間がかかるものです。ソフトウェア開発は、常に想定より時間がかかりますが、それでも30か月後には構築が完了していることでしょう。完成したソフトウェアはあなたが意図したとおりではありませんでしたが、あなたが想定した顧客ニーズにはかなり近いものになっています。
残念ながら、何かが間違っていました。顧客との話し合いが不十分だったり、問題を解決しようとしているうちに新しい顧客基盤が生じたり、顧客に価値をもたらす方法を本当には理解していなかったり、ソフトウェアを開発していた30か月の間に市場が大きく変化したなどの原因が考えられます。
これはウォーターフォール型開発で起こる悲劇です。せっかく美しい橋を建設しても、誰も橋の向こう側に興味がないという結果に終わります。
反復あるのみ
DevSecOpsの基礎は、1つの大きな跳躍ではなく、小さなステップを数多く重ねていくことです。これにより、間違った方向に進んでいたことが判明した場合に進路を調整しやすくなります。DevSecOpsは、アジャイル開発と継続的インテグレーションから継承した原則に基づいて、スプリントと呼ばれる設計/ビルド/テスト/デプロイの短いサイクルを用いた反復を重視します。各スプリントの期間は通常2週間です。ソフトウェア全体を一挙に構築するのではなく、機能を反復的に構築していきます。これにより、市場に対する理解や市場自体が進化するにつれて臨機応変に進路を変えることができます。
リリース間隔が短いことで、ウォーターフォール型開発の場合よりも迅速に変更を評価し、顧客の前で新機能を提示することができます。機能がうまく動作するかどうかにかかわらず、すぐ結果がわかりますし、必要に応じて次のスプリントで進路を調整することができます。
DevSecOpsの自動化
DevSecOpsのもう1つの基礎は、ソフトウェアの構築／デプロイを自動化して手動の手順を排除することです。これにより、開発チームが変更を加えてから、その変更がデプロイされるまでの時間が短縮されます。これは、構築とデプロイの頻度を増やせばプロセスを可能な限り最適化できるという点で理にかなっています。
DevSecOpsではソフトウェア開発の迅速化として現れるこの概念は、多くの場合にベロシティと呼ばれます。この概念は経営幹部に対して効果てきめんです。仕事が速く片付くと聞けば、どんな管理者も喜びます。そこには幾分の錯覚があります。それは大きな飛躍ではなく、小さな一歩の積み重ねにすぎないのですから。DevSecOpsでは継続的な改善を提案しますが、これはプロセスを批評的に検討し、調整しながら最適化していくことを意味します。この観点に立てば、実際に時間の経過とともに開発プロセスは迅速化し、俊敏になるはずです。DevSecOpsを導入してしばらくすると、従来のウォーターフォール型モデルよりはるかに効率が向上するはずです。
セキュリティ用バッテリーの組み込み
セキュリティはどこに存在するかというと、ソフトウェア開発の各フェーズに組み込まれています。スプリントの計画、設計、開発、テストの一部に組み込まれている必要があります。ウォーターフォール型開発でも各フェーズに組み込まれていてしかるべきでしたが、従来、セキュリティは軽視されたり、全く無視されたりしていました。セキュリティが組み込まれていたとしても、多くの場合、リリース前に克服すべき関門として開発サイクルの最後に取り入れられていました。
ソフトウェア開発にセキュリティを組み込むという発想は新しいものではありませんが、DevSecOpsでは話が変わってきます。ソフトウェアの構築、パッケージ化、デプロイのタスクが高度に自動化されている場合、セキュリティはこのシナリオにどのような形で組み込めばよいでしょうか。
答えは、適切なタイミングで適切なテストを行うということです。これは、ほとんどの場合、必要な成果物が利用可能になり次第、開発サイクルの一番左（最初）の時点でセキュリティツールを自動化することを意味します。たとえば、静的テストはソースコード上で実行します。したがって、セキュリティは開発者のデスクトップのパイプラインに統合され、コードがソースコードのリポジトリにプッシュバックされたときに実行する必要があります。オープンソースおよびサードパーティーコンポーネントを管理するには、ソフトウェア・コンポジション解析を同時点で統合する必要があります。ファジングテストは、バイナリが利用可能になり次第、統合する必要があります。
さらに、セキュリティテストはコンテキストに基づいて最適化する必要があります。開発者がコードの変更をコミットすると、自動的に変更が解析され、適切な種類とレベルのセキュリティテストが選択されます。たとえば、静的解析では、常にすべてのコードをスキャンする必要はありません。多くの場合、差分解析で十分です。テストの適切なレベルを決定して自動的に調整することが自動化の目標です。
また、一部のセキュリティテストは常に非同期的に実行する必要があります。これには総合テスト、拡張ファジングテスト、レッドチームなどのアクティビティが該当します。リリースゲートは、自動テストと非同期テストの結果の組み合わせで設定する必要があります。
計画的な迅速化
DevSecOpsの真の成功は、必ずしも迅速化することではなく、より優れたソフトウェアを構築することです。迅速な反復（イテレーション）により、組織の俊敏性が向上し、市場の状況や意識の変化により的確に対応できます。自動化を多用することで、開発チームは従来のウォーターフォール型プロセスよりも迅速に変更をテスターや顧客の手に渡すことができます。
セキュリティはこのプロセスの重要な部分です。ソフトウェア開発のあらゆる部分にセキュリティを統合することにより、製品開発中に発見・修正されるバグが増え、最終製品にバグが潜んでいるリスクが軽減されます。迅速な反復処理と高度に自動化されたDevSecOpsのプロセスを備えることにより、セキュリティテストのチューニングと最適化を行うことで、適切なテストが適切なタイミングで実行されます。
Continue Reading
