DevSecOpsセキュリティチェックリスト

この記事では、チーム全体で共通認識を持つのに役立つ、10ステップから成るDevSecOpsセキュリティチェックリストをご紹介します。

開発プロセスのどの段階でセキュリティの問題が生じているかを把握する

GitLabの2022年グローバルDevSecOps調査では、デベロッパーとセキュリティチーム間の分断は縮小しているものの、いくつかの摩擦が残っていることがわかっています。アンケート回答者の57%は「組織のセキュリティがデベロッパーのパフォーマンス指標である」と回答しましたが、一方で「デベロッパーにコードの脆弱性の修正を優先させるのは難しい」と回答した割合は56%にのぼりました。さらに、回答者の59%は「セキュリティ上の脆弱性は、コードがテスト環境にマージされた後にセキュリティチームによって発見される可能性がもっとも高い」と答えています。「どのチームがセキュリティの責任を担うか」という問いに対するセキュリティ担当者の回答では、「セキュリティチーム」が43%、「全員」が53%という結果となり、意見が分かれました。要するに、大きな混乱が生じており、DevSecOpsパイプラインにおける最大の課題を把握することから始める必要があります。

全員が共通の目標に向かって足並みをそろえる

セキュリティや責任範囲に対する認識が多岐にわたっている状態では、明確なチーム目標を掲げることで、具体的な目的を持って取り組めるようになります。責任範囲と期待事項を把握できていないチームでは、ソフトウェアライフサイクルでセキュリティを推進しても、誰もメリットを得られません。たとえば、より多くのコードをテストするという目標に向かってチームの足並みをそろえることで、プロジェクトがスムーズに進み出せば、リリースのスピードが向上します。同様に、最初の段階からセキュリティチャンピオン（セキュリティを主導する人材）を確保することで計画プロセスを改善するという目標が確立されれば、プロセスのすべてのステップでセキュリティ対策が講じられることになり、摩擦が低減され、最終的にリリースサイクルのスピードが向上します。実績のあるDevSecOpsアプローチを実践し、セキュリティリスクの低減を全員の役割とする文化を醸成することで、セキュリティチーム以外のメンバーの間でも、責任意識が高まります。

監査を実施して、チームが時間を無駄にしている箇所を特定する

DevSecOpsを採用していない場合、セキュリティチームが、独自のツールを使用して、開発サイクルの最後でセキュリティ上の脆弱性を特定し、開発チームに差し戻して修正を依頼するのが一般的です。このように行ったり来たりの作業が生じることで、2つのチーム間に常に摩擦が生じ、非効率なコミュニケーションによって時間が浪費されます。コードがマージされた後の脆弱性の対処に、チームがどれだけの時間を無駄にしているかを把握することで、パターンを特定し、改善に向けて調整できる可能性があります。たとえば、セキュリティチームが致命的な脆弱性の修復状況を追跡するのに苦労している場合、最新情報を把握するために常に開発チームに確認しなければならないという状況である可能性もあります。このような状況の場合、デベロッパーとセキュリティ担当者の両方が致命的な脆弱性の修正状況を確認できる単一ダッシュボードの導入が必要な可能性があります。

課題とボトルネックについて話し合う

セキュリティは、ソフトウェアを迅速にリリースする上でボトルネックとなることがありますが、非常に重要であるため、軽視したり無視したりすることはできません。DevSecOpsによってソフトウェア開発ライフサイクルのセキュリティを強化できることは確実ですが、それを達成するには時間がかかります。重要なステップとして、すべてのチーム（開発、セキュリティ、オペレーション）のメンバーを集めて、セキュリティ関連の課題とボトルネックについて率直なディスカッションを行います。意見がまとまったら、それぞれの懸念点を解決するための計画を立てて、実行に移します。こうしたディスカッションを行うことで、全員の意見を確実にくみ取り、無機質なデータでは把握しづらい課題を特定できるようになります。

少しずつ、漸進的なコード変更を加える

GitLabでは、イテレーションをコアバリューの1つに掲げています。そのため、変更を加える際には、小規模で迅速に達成できる変更を加えて、そこにさらなる改善を重ねていきます。この原則は、DevOpsからDevSecOpsに移行する場合にも当てはまります。小規模かつ漸進的なコード変更は、レビューと保護が容易なほか、モノリシックなプロジェクトの変更よりも迅速にリリースできます。小さなチャンクや単位でコードを作成し、単位ごとにコミットした後で自動テストを実行することで、デベロッパーはその場で脆弱性を修正できるようになります。これにより、フィードバックを受け取るまで数日、数週間、または数か月も待つ必要がなくなります。そして定期的にテストを実行しておけば、完成したアプリを本番環境にプッシュする前にテストする際の時間を節約できます。

自動化とインテグレーション

自動化とインテグレーションはDevOpsの重要な要素であり、セキュリティスキャンを強力なツールにする要素だとも言えます。スキャンがいたるところに行きわたっていれば、すべてのコード変更がレビューされ、プロセスの早期段階で脆弱性が発見されます。スキャンはデベロッパーのワークフローに組み込む必要があります。セキュリティを統合することで、デベロッパーはコードが手元にあるうちに脆弱性を発見し、修正できます。これにより、セキュリティチームが担当するセキュリティ問題の量が減り、レビューが効率化されます。

デベロッパーがセキュリティレポートの結果にアクセスできるようにする

静的アプリケーションセキュリティテスト（SAST）や動的アプリケーションセキュリティテスト（DAST）の結果はセキュリティチーム内に留めず、チーム全体、特にデベロッパーと共有することが重要です。こうした情報は、修正作業の際に重要であるだけでなく、デベロッパーがソフトウェア開発ライフサイクルに必要なセキュリティ制御を組み込むのを支援する貴重なツールにもなります。

ウォーターフォール型セキュリティプロセスの監査を行う

従来のウォーターフォール型のセキュリティアプローチでは、脆弱性は通常、開発サイクルの終わりに発見されます。ソフトウェア開発ライフサイクル内の既存のセキュリティワークフローを入念に監査しましょう。ウォーターフォール型プロセスが見つかった場合、それらを排除するか、少なくとも依存度を大幅に減らすことが推奨されます。必要に応じて、いつでも方向を修正できるよう体制を整えておくことが大切です。組織内で俊敏な対応が取れるようにしましょう。

セキュリティチームが脆弱性のステータスを把握できるようにする

2022年グローバルDevSecOps調査によると、セキュリティ担当者が直面している最大の課題は、脆弱性の修正の優先順位付けであることが判明しています。その他の懸念事項として、誤検出の多さや脆弱性ステータスの追跡の難しさなどが挙げられました。これは、セキュリティ担当者が将来に対してやや否定的な見通しを持つ一因である可能性があります。実際、将来に向けて「ある程度準備できている」または「非常に準備できている」と回答したセキュリティ担当者の割合は56%にとどまり、デベロッパーとオペレーション担当者の平均回答を20ポイント近く下回りました。セキュリティチームが解決済みおよび未解決の脆弱性、その所在、作成者、そして修正状況をより正確に把握できるようにする必要があることは明らかです。

ツールを単一のDevOpsプラットフォームに統合する

チームが適切なツールを利用できなければ、全員でセキュリティを分担するのは困難になります。セキュリティをシフトレフトする上で最善な方法は、エンドツーエンドのプラットフォームを導入することです。このプラットフォームは、DevOpsチームのウォーターフォール型プロセスからの脱却、コミュニケーションの円滑化、および自動化や継続的インテグレーションの導入を促進するほか、セキュリティスキャンの結果や致命的な脆弱性のステータスに関する信頼できる唯一の情報源になります。