.png)
監査。この言葉だけで、開発者は戦慄を覚えるだろう。終わりの見えないミーティング、何ヶ月も前に書かれたコードに関する細かい質問、不明瞭なドキュメントの要求。しかし、そこまでひどくなる必要はない。
監査に備えることは、単に監査人をなだめることではなく、これまで行ってきたセキュリティとコンプライアンスの作業が実際に効果的であることを証明することです。開発者にとって、これは、監査人があなたのワークフローにおいてどのような証拠を求めているかを知り、あなたのスプリントを脱線させることなくそれを提示する方法を知ることを意味する。
開発ワークフローにおける証拠とはどのようなものか
監査人は通常、（特定のコード監査でない限り）生のソースコードを読みたがらない。監査人が求めているのは、あなたのプロセスや 管理が機能しているという証拠なのだ。典型的な開発ワークフローでは、証拠は次のようになる：
- バージョン管理の歴史：
- チケット/課題にリンクされたコミット：変更が計画され、追跡されたことを示す（変更管理コントロールに関連）。
- プルリクエスト（PR）の記録：コードレビュー、必要な承認、自動化されたチェック（SAST、SCA、テスト）がマージ前にパスした証拠。これは、セキュアな SDLC の実践（NIST SSDF、PCI DSS Req 6、ISO 27001 A.14）を実証するための金字塔です。
- ブランチ戦略の文書化：コード変更を管理するプロセスを示す。
- CI/CDパイプラインのログ：
- 実行履歴：ビルド/デプロイがいつ行われたかを示すタイムスタンプ。
- スキャン結果：特定のビルドのSAST、SCA、IaCスキャン結果を示すログまたは成果物（脆弱性管理の証拠）。
- テスト結果：自動化されたユニットテスト、統合テスト、セキュリティテストのレポート。
- 配備の承認：デプロイメントに合格した手動または自動のゲートを示すログ。
- 課題追跡記録（Jiraなど）：
- 脆弱性チケット：脆弱性チケット：スキャンまたはテストによるセキュリ ティ上の発見事項の特定、割り当て、修正、検証を追跡する。稼働中の脆弱性管理プロセス（PCI DSS Req 6/11、ISO 27001 A.12.6、NIST SSDF RV）を示す。
- 変更要求チケット：計画された変更、承認、関連するコードコミット/PRへのリンクを文書化する。
- ツール構成と出力：
- スキャナの設定：SAST/SCA/DASTツールがどのように設定され、どのルールが有効かを示す。
- IaCスキャンレポート：インフラストラクチャのコードに設定ミスがないかチェックした証明。
- 秘密のスキャンレポート：コードがハードコードされたクレデンシャルについてスキャンされた証拠。
- ドキュメンテーション
- セキュアコーディング標準：開発者が従うべきガイドライン。
- 脅威モデル：設計段階で作成される文書。
- トレーニング記録：開発者がセキュリティ意識向上トレーニングまたはセキュアコーディングトレーニングを修了したことの証明（多くの場合、人事部またはコンプライアンスチームが管理するが、関連する）。
- ランブック／手順：インシデント対応や、開発者が参加する特定のセキュリティプロセスに関する文書。
監査人は、統制が机上の空論ではなく、一貫して適用されていることを示す具体的な証拠、できればタイムスタンプ付きの証拠を求めている。
ドキュメンテーションとトラッキングの自動化
手作業による証拠収集は骨が折れ、ミスが起こりやすい。できるだけ自動化しましょう：
- 既存のツールを活用する： 既存の開発ツールは、すでにエビデンスの多くを生成しています。それらが正しく設定されていることを確認してください：
- Gitプラットフォーム（GitHub、GitLab、Bitbucket）：PR要件（レビュー、ステータスチェック）を強制する。課題トラッカーへのコミットメッセージのリンクを使う。
- CI/CDプラットフォーム（Jenkins、GitLab CI、GitHub Actions）：詳細なロギングが有効になっていることを確認する。スキャンレポートとテスト結果を成果物として保存するようにパイプラインを設定する。自動化された品質とセキュリティゲートを統合する。
- 課題トラッカー（Jira）：ワークフローを使用して脆弱性の修復状況を追跡する。課題をコミット/PR にリンクする。
- セキュリティスキャナー：簡単に取り込んだり保存したりできる標準フォーマット（SARIF、JSON）で結果を出力するようにツールを構成する。
- ログの一元管理：CI/CD、スキャナ、そして可能であればソース管理（利用可能な場合）からのログを中央システム（SIEM、ログ管理プラットフォーム）に送信し、検索と保存を容易にする。
- コンプライアンス自動化プラットフォーム：Vanta、Drata、Secureframeなどのツールは、APIを介して多くの開発ツール（クラウドプロバイダー、Gitリポジトリ、チケットシステム、スキャナー）と統合し、証拠を自動的に収集し、コンプライアンスコントロールにマッピングし、ステータスを追跡することができる。これにより、手作業による収集が大幅に削減される。
- コードとしてのインフラ（IaC）とコードとしてのポリシー（PaC）：インフラストラクチャとポリシーをコードとしてバージョン管理に保存することで、変更と承認された構成の固有の監査証跡を提供します。PaCツールは、実施決定を記録することができます。
目標は、エビデンスの作成を開発プロセスの自然なアウトプットとすることであり、監査前に別個に必死で奔走することではない。
内部模擬監査
外部監査人が穴を見つけるのを待つ必要はない。開発プロセスに特化した内部模擬監査を実施することで、後々の痛みを大幅に軽減することができる。
- 範囲を絞る：今後の監査に関連する特定の領域（変更管理プロセス、CI/CDにおける脆弱性管理、重要なアプリのセキュアコーディングの実践など）に焦点を当てる。
- 開発者を巻き込む：開発者に典型的なワークフロー（PR の提出、配備、脆弱性の修正）を説明させ、特定の管理要件を満たす方法を説明させる。
- 証拠を要求する：外部の監査人が要求するであろう実際の証拠（PRリンク、パイプラインログ、スキャンレポート、Jiraチケット）を引き出すように開発者に依頼する。彼らはそれを簡単に見つけることができますか？それは完全ですか？
- 監査人の質問をシミュレートする：フレームワークの要求事項に基づき、監査人が投げかける可能性のある厳しい質問をする（例については前のセクションを参照）。
- ギャップを特定する：プロセスが守られていない、文書が不足している、証拠が見つけにくい、または統制が期待通りに機能していない箇所をメモする。
- 真剣に取り組む：発見事項を文書化し、（実際の監査と同じように）アクションアイテムを作成し、所有者を割り当て、改善状況を追跡する。
模擬監査は、開発者が監査人の目を理解し、プレッシャーのかかる外部監査の前にプロセスや証拠収集の弱点を発見し、チームの準備態勢に自信をつけるのに役立つ。
一般的な監査指摘事項への対応
監査人は、開発ワークフローに関連する同様の問題を指摘することが多い。以下のような指摘に対処できるよう準備しておくこと：
- 一貫性のない変更管理： その証拠に、必要な承認なしにマージされたPR、標準プロセス外で展開された変更、チケットとコード変更の間のリンクの欠如などがある。
- 修正：ブランチ保護ルールの厳格化、CI/CDゲートの強化、Gitと課題追跡システムとの自動化・統合の改善、プロセス規律の強化。
- 非効率的な脆弱性管理： スキャンの結果、重要な脆弱性が要求されるSLA内で修正されていない、発見された内容が追跡されている証拠がない、またはスキャンが一貫して実行されていない。
- 修正：スキャンの早期化／確実な統合、発見事項に対するチケットの自動作成、明確なSLAとエスカレーションパスの確立、ダッシュボードを使用した修復の進捗状況の追跡。
- 証拠がない／不十分： 監査期間中のログ、スキャンレポート、承認記録が簡単に作成できない。
- 修正：証拠の自動収集と一元化を改善し（3.4.2参照）、適切なログ保持が設定されていることを確認する。
- セキュアコーディングのトレーニング／意識の欠如： 開発者が、SAST ツールや監査人によって指摘された一般的なミスを犯していることは、セキュアなコーディングの実践に対する認識不足を示している。
- セキュアコーディングのチェックリストを提供し、コードレビューを通じて強化する。
- 脆弱なアクセス制御： 本番環境または機密環境において、開発者が過剰な権限を持っている、共有アカウントが使用されている。
- 対策：RBACを厳格に導入し、最小権限を強制し、定期的なアクセスレビューを実施し、共有アカウントを廃止する。
- 秘密の暴露 コードレビューやスキャン中にハードコードされた認証情報を見つける。
- 修正：秘密スキャンを早期（コミット前）に実施し、承認された秘密管理ツールの使用を強制し、適切な取り扱いについて開発者を訓練する。
重要なのは、監査指摘事項を失敗としてではなく、改善の機会として扱うことである。是正措置を実施し、文書を更新し、必要であれば追加トレーニングを提供し、次回の監査サイクル（内部または外部）で修正が検証されるようにする。
