シフトレフトセキュリティ

TL;DR: シフトレフトセキュリティ

シフトレフトセキュリティとは、ソフトウェア開発プロセスの早い段階でセキュリティテストと施行を開始することを意味します。デプロイ直前まで待つのではなく、チームは最初からセキュリティに取り組みます。

このアプローチは以下の利点があります:

• 脆弱性を早期に発見 し、修正が最も簡単で安価な段階で対応できます。
• 開発者にセキュリティの所有権を与える ことで、ワークフローを遅らせることなくセキュリティを管理できます。セキュリティチェックがユニットテストのように自然に感じられたらどうでしょうか？セキュリティを開発者のエンパワーメントの手段として位置付けることで、日常のルーチンにセキュリティをシームレスに統合する内発的動機を育みます。この自律性はセキュリティに対する積極的なアプローチを促進し、生産性と全体的なセキュリティ姿勢を向上させます。
• 再作業のコストを削減 し、問題をプロダクションではなくコーディングフェーズで修正します。

シフトレフトセキュリティの目標は、コードを設計段階で安全にするために、開発プロセスの継続的な一部としてセキュリティを組み込むことです。

シフトレフトセキュリティとは

シフトレフトセキュリティはアプリケーションセキュリティの戦略です。セキュリティ問題のテストや脆弱性のスキャンを、テストやデプロイ時だけでなく、コーディングやビルド中に行うことを意味します。

従来の「ウォーターフォール」モデルでは、セキュリティチェックは最後に行われます。これはタイムラインの「右側」として視覚化されることが多いです。左にシフトすることで、これらのチェックを「左側」に移動します。これにより、統合開発環境（IDE）、Gitリポジトリ、CI/CDパイプラインに統合されます。

簡単に言えば：

Shift Left Securityとは、コードを書いている間にセキュリティの欠陥をテストすることを意味します。これにより、バグを本番環境に出荷しないようにします。

Shift Left Securityが重要な理由

セキュリティを開発の最終段階に残しておくと、ボトルネックを作り出します。もし重大な脆弱性が発売直前に発見された場合、リリースを遅らせるか、リスクを伴って出荷するかの選択を迫られます。

では、なぜShift Left Securityが重要なのでしょうか？

本番環境でのバグ修正は高コストです。 NISTによれば、本番環境で欠陥を修正するコストは、コーディング中に修正するコストの30倍から100倍になる可能性があります。

速度には自動化が必要です。 現代のDevOpsチームは1日に何度もデプロイします。手動のペネトレーションテストでは追いつけません。自動化された「左シフト」ツールは、コミットごとに実行されます。自動化されたスキャンは効率的に問題を表面化しますが、人間によるレビューは依然として重要なコンテキストと判断を提供し、バランスの取れたアプローチを保証します。

開発者は迅速なフィードバックを必要としています。 コードがまだ新鮮なうちにセキュリティ問題を修正する方が、数週間後に他のことに移った後に修正するよりも簡単です。

セキュリティは共有責任です。 これはセキュリティチームとエンジニアリングの間のギャップを埋めます。これにより、セキュリティはゲートキーパーではなく、イネーブラーになります。

Shift Left Securityの仕組み

Shift Left Securityは、アプリケーションが構築またはデプロイされる前にコードや依存関係の脆弱性をキャッチします。

1. IDEでの問題検出（プリコミット）

ツールは開発者のコーディング環境（VS Code、IntelliJ）に直接統合され、リアルタイムで問題をフラグします。

• 静的アプリケーションセキュリティテスト (SAST): ソースコードをスキャンして、SQLインジェクションなどの安全でないコーディングパターンを検出します。
• 秘密検出: 開発者がAPIキーやトークンをコードに貼り付けようとした場合に警告します。

目標: 安全でないコードがバージョン管理システムに入るのを防ぐ。

2. CI/CDでのスキャンの自動化 (プルリクエスト)

コードがリポジトリにプッシュされるか、プルリクエストが開かれるたびにセキュリティスキャンが自動的に実行されます。

• ソフトウェア構成分析 (SCA): オープンソースライブラリを既知の脆弱性 (CVE) についてチェックします。
• コードとしてのインフラストラクチャ (IaC) スキャン: TerraformやKubernetesファイルの設定ミスをチェックします。

目標: コードをマージする前にピアレビューの過程で問題を検出する。

3. 品質ゲートの強制

パイプラインは、高度な脆弱性が検出された場合にビルドを失敗させるように設定されています。

• 例: Dockerイメージで「重大」な脆弱性が見つかった場合、パイプラインは停止します。問題が解決されるまでデプロイメントはブロックされます。

目標: 脆弱なアーティファクトがステージングやプロダクションに到達するのを防ぐ。

4. 継続的フィードバックループ

スキャン結果は、Jira、Slack、GitHub Issuesなど、開発者が使用するツールに直接送信されます。これにより、別々のPDFレポートが不要になります。

目標: セキュリティの発見を既存のエンジニアリングワークフローに統合する。

シフトレフトによって検出される一般的なリスク

シフトレフトセキュリティが早期に検出できる問題の例:

• ハードコードされた秘密: AWSキー、データベースパスワード、またはAPIトークンがGitにコミットされていること。これらを早期に検出することで、セキュリティ侵害を防ぐだけでなく、後に高価な資格情報のローテーションに必要な時間とリソースを節約できます。
• 脆弱な依存関係: 既知のエクスプロイトがある古いバージョンのLog4jやOpenSSLを使用すること。
• インジェクションの欠陥: SQLインジェクション (SQLi) や クロスサイトスクリプティング (XSS) がソースコードに存在すること。
• 安全でないインフラストラクチャ: 公開アクセスがあるS3バケットやルートとして実行されているコンテナ。
• コンプライアンス違反: GDPRやPCI-DSSの要件に違反するコード。

実践例

開発者がNode.jsアプリケーションの新しいログイン機能に取り組んでいます。

シフトレフトなし: 開発者はコードを完成させ、マージしてステージングにデプロイします。2週間後、セキュリティチームがスキャンを実行し、ハードコードされたデータベースパスワードを発見します。チームは問題に対処するために混乱とパニックに陥ります。期待されていた金曜日のローンチは延期され、月曜日の朝の緊急会議に変わり、リリースは保留されます。開発者は認証モジュールの書き直しを任され、関係者は望ましくない遅延に不安を感じます。

シフトレフトあり (Plexicusを使用):

1. 開発者がコードをコミットします。
2. CI/CDパイプラインがPlexicusスキャンをトリガーします。
3. スキャンは直ちにハードコードされたパスワードを検出します。
4. ビルドが失敗します。プルリクエストは特定の行番号でフラグが立てられます。
5. 開発者はパスワードを削除し、環境変数を使用して再度コミットします。
6. ビルドが成功します。

結果: 脆弱性は開発ブランチを離れることはありませんでした。リリーススケジュールは予定通りに進みました。

シフトレフトセキュリティを使用する人々

• 開発者 - ピアレビュー前に自分のコードをエラーがないかチェックするため。
• DevOpsエンジニア - CI/CDパイプラインでセキュリティゲートを自動化するため。
• AppSec / DevSecOpsチーム - ポリシーを設定し、全体的なセキュリティ姿勢を監視するため。
• エンジニアリングマネージャー - 技術的負債とセキュリティリスクを速度を落とさずに管理するため。

シフトレフトセキュリティを適用するタイミング

シフトレフトセキュリティは早期のSDLCを通じて適用されるべきです。

• ローカル開発 - プリコミットフックとIDEプラグイン。
• コードコミット - ブランチとプルリクエストの自動スキャン。
• ビルドアーティファクト - コンテナイメージとコンパイル済みバイナリのスキャン。
• ステージング - 動的解析 (DAST)を本番環境に出荷する前に実行中のアプリケーションで行う。

シフトレフトツールの主要機能

ほとんどのシフトレフトセキュリティソリューションは以下を提供します：

• SAST (静的アプリケーションセキュリティテスト): ソースコードの分析。
• SCA (ソフトウェア構成分析): オープンソースライブラリのチェック。
• シークレット検出: ハードコードされた資格情報の発見。
• IaCセキュリティ: インフラストラクチャ構成のスキャン。
• CI/CD統合: GitHub、GitLab、Jenkinsなどのネイティブプラグイン。
• 開発者優先の修正: 修正が必要な場所を正確に表示（ファイルと行番号）。

例: 専門的なスキャナーや、コード、シークレット、コンテナのスキャンを単一のワークフローに統合するPlexicus ASPMのような統合プラットフォーム。

シフトレフトセキュリティのベストプラクティス

• 小さく始める: 軽微な問題でビルドを中断しない。「重大」および「高」重大度の発見のみをブロックすることから始める。
• 誤検知を最小化する: 開発者が無視しないように、無関係な問題に対してアラートを出さないようにスキャナーを調整する。
• 高速スキャン: セキュリティチェックがビルドプロセスに大幅な時間を追加しないようにする。
• 開発者を教育する: 発見を罰ではなく学習の機会として利用する。
• すべてをスキャンする: 独自コード、オープンソースの依存関係、インフラストラクチャ構成をカバーする。

関連用語

• DevSecOps
• SAST (Static Application Security Testing)
• SCA (Software Composition Analysis)
• CI/CD Security