開発者によるセキュリティツールとプロセスの導入を促進するベストプラクティス

現代の組織でアプリケーションセキュリティを拡大するには、アジャイルプロセスやDevOpsパイプラインの自然な一部として、開発ワークフローに直接組み込むことが重要だという認識が広く浸透しています。しかし、実現は簡単ではなく、開発者や開発チームの受け入れや導入に関して多くの課題があります。このホワイトペーパーでは、成熟度がさまざまな段階にあるDevSecOpsプログラムを実施している多くの組織との対話から得た知見をまとめています。話を聞いたすべての個人やグループに共通していたのは、開発チームにワークフローの一部としてセキュアな開発手法を取り入れてほしいという思いでした。

話を聞いたグループの間で、まったく同じ方法を採用しているところはありませんでした。また、成功を左右する要因は数多くあるため、ある組織でうまくいく方法が、別の組織でも同じようにうまくいくとは限りません。このホワイトペーパーにある実践方法やアプローチから、自社の組織、文化、チームに最適なものを見極めることが重要です。

開発者のセキュリティには、文化、プロセス、ツールが必要

文化

1. 開発チームの立場に立つ

• 変化に対するチームの全般的な受容度を把握する。

• 最新のテクノロジーや開発プロセスを導入しやすいチームやプロジェクトと、変化に抵抗があるチームやプロジェクトを把握する。

• プロジェクトのオーナーシップと責任の所在がどの程度明確かを確認する。

• デリバリーに加え、パフォーマンスや信頼性など、ほかの業務にチームがどれだけ対応できるかを把握する。

2. 経営主導でセキュリティの優先順位を決める

• 優先順位がビジネス側の判断によるものだと明確に伝える。

• セキュリティチームは、開発チームの負担を増やすのではなく、ビジネス上のセキュリティ優先事項への対応を支援する。

3. 開発者とセキュリティチームの連携を促す

• セキュリティチャンピオンプログラムやセキュリティギルドを設け、連携しやすくする。

• 恐怖心に頼るのではなく、開発者と協力して信頼関係を築く。

• セキュリティチームと開発チームが共に取り組むプログラムを立ち上げ、共通の目標を設定する。

• 開発チーム内の担当者を明確にし、セキュリティチームからの依頼が適切なものになるようにする。

4. 教育を通じてセキュアな開発を実現する

• プログラムを展開する前に、チームに教育を行う。

• 教育内容によっては、すべてのチームに関係するわけではないことを認識する。

• 過去のインシデントを例に、各チームに影響する具体的な脆弱性についてトレーニングする。

• スコアカードで教育の進捗を追跡する。

• 可能であれば、教育にゲーム要素を取り入れる。

5. 報奨と評価

• 個人の成果やセキュリティの改善を取り上げて称える。

• チームの成功やプログラムの導入事例を紹介し、進捗を示すとともに、ほかのチームでの展開を促す。

• エンジニアリング部門のリーダーがチームの功績を認め、セキュリティが重要であることを示すようにする。

• 認知向上のために、グッズやギフト、セキュリティカンファレンスへの参加機会などを提供する。

プロセス

1. プロセス変更の意思決定に開発者を含める

• 開発チームが現在どのようにセキュリティ対策をパイプラインに組み込んでいるかを把握し、そのワークフローに合わせる。

• 新しいセキュリティルールやプロセスを策定する際は、開発チームと協力してしきい値や作業方法を決める。

• プロセスを変更する場合は、ブログ、ドキュメント、学習ハブなどを通じて、変更内容の教育と周知を十分前もって行う。

2. 正しい方法を最も簡単な方法にする

• プロセスを複雑にしすぎない。開発チームと協力して、シンプルに保つ。

• ほかのチームの作業方法や各業務の進め方を、わかりやすく文書化する。

• 開発者がデフォルトで正しい判断をできるよう、舗装された道（paved road）となる選択肢を用意する。

• 新しいワークフローを作ろうとするのではなく、既存のワークフローにプロセスを組み込む。

• プロセスやツールは、問題の指摘ではなく解決に重点を置く。

3. チーム間の可視性と透明性を高める

• スコアカードは、組織にセキュリティの進捗や状況を報告するうえで有効です。

• チームはスコアカードの結果に責任を持ち、自チームの状況や計画に基づいてセキュリティを優先する必要があります。

• 開発者が大切にしている価値観やゲーム要素を活用して、スコアカードのデータを根拠に作業をスプリントに組み込む。

4. 展開のスピード

• 順応性が高く、新しいセキュリティプログラムの導入に前向きなチームを特定する。

• まずはそうしたチームに展開し、当初は負担を抑え、状況の可視化を中心に進める。

• まずはアプリケーションに加えられる小さな変更のセキュリティに焦点を当て、セキュアな開発活動を開発ワークフローに追加する。

• チームに過度な負担をかけず、変化に対応できるペースでガードレールを段階的に強化する。

• 早期導入チームで効果が確認できたら、次に展開するチームを特定する。

• 初期展開で明らかになったベストプラクティスを活用し、導入を促進する。

ツール

1. 開発者向けツールを取り入れる

• 開発者向けセキュリティツールには、簡単なオンボーディング、直感的なワークフロー、わかりやすいドキュメントなど、優れたセルフサービス機能が必要です。

• ツールは、IDE、Git、パイプラインなど、既存のワークフローに統合できる必要があります。

• ツールには充実したAPIがあり、自動化に対応している必要があります。

• オープンソースコミュニティやセキュリティコミュニティで広く採用されているツールを選ぶ。

• 自社開発コード、サードパーティライブラリ、コンテナ、IaCなど、アプリケーション全体をカバーするツールを選ぶ。

• ツールは、問題の検出や報告よりも、修正や修復を重視すべきです。

2. 開発者に過度な負担をかけない

• 組織やチームにツールを導入する際は、まず状況の可視化に活用する。

• 時間をかけてポリシーを通じたルールやガードレールを強化し、セキュアな開発プロセスを改善する。

• ツールの変更にあたっては、周知、コミュニケーション、理由の説明、適切なプロセス文書、教育で支える。

• 開発者の負担を軽減するため、まず新規コードのデリバリーにツールを適用し、その後バックログの問題に対応する。

3. すべてを自動化する

• チームに合わせて適切な場所でワークフローに統合し、自動化する。

• ワークフロー内のテストに加え、チケット管理、レポート、アラートなど、ツールを連携できるほかの仕組みも検討する。

• ツールからレポート用のデータを取得できるようにする。できればAPIを利用し、既存のダッシュボードやスコアカードに反映する。