コードリリースサイクルにおけるシフトレフトの概念は、ソフトウェア開発ライフサイクルの早い段階、多くの場合はコードが記述される前に、テスト、品質、パフォーマンス評価を統合することを目的としたプラクティスです。これにより、欠陥の発見と予防、品質の向上、そして安全なソフトウェアのより迅速な提供が可能になります。シフトレフトの概念の重要な側面の一つは、継続的インテグレーション、継続的デリバリー、継続的テストツールなどを活用し、ソフトウェアコードの問題を早期に特定して対処するための自動化を組み込むことです。自動化は、手作業によるエラーの削減、フィードバックループの高速化、効率性と信頼性の向上に役立ちます。123 その他の選択肢は、以下の理由により正しくありません。
* 選択肢Aは不正解です。リリースサイクルが遅く、システムが地理的に分散している大規模な組織は、複雑でレガシーなシステム、依存関係、そして俊敏性とコラボレーションを阻害するプロセスを抱えている可能性があるため、シフトレフトの概念を導入する際に課題に直面する可能性が高くなります。シフトレフトの概念には、継続的な改善、実験、そして学習の文化が必要であり、これは従来型の組織やサイロ化された組織とは両立しない可能性があります。4
* 選択肢Cは不正解です。ウォーターフォールモデルは、ソフトウェア開発ライフサイクルの後半で開発、テスト、導入という段階的なフェーズを経るため、シフトレフトの概念とは正反対です。ウォーターフォールモデルでは、欠陥、フィードバック、変更の早期発見と修正が不可能であり、コスト、遅延、リスクの増大につながる可能性があります。5
* 選択肢Dは不正解です。スタートアップ企業において、高いイテレーションから低いコードコミットへと成熟度が移行していることは、シフトレフトの概念ではなく、アジャイルまたはリーンソフトウェア開発手法の表れです。これらの手法は、短いイテレーションまたはスプリントで、頻繁なフィードバックと適応を伴いながら、動作するソフトウェアを提供することで顧客に価値を提供することに重点を置いています。これらの手法は、テストとデリバリーサイクルを迅速化することでシフトレフトの概念をサポートできますが、シフトレフトの概念と同等または同義ではありません。6 参考文献：1：AWS. What is DevSecOps? - Developer Security Operations Explained - AWS.
[オンライン]. 公開日: 4. [アクセス日: 2023年4月14日]. 2: Dynatrace. シフトレフト vs シフトライト：DevOpsの謎を解く - Dynatraceニュース. [オンライン]. 公開日: 2. [アクセス日: 2023年4月14日]. 3: BMC Software. シフトレフトテスト：シフトレフトとは何か、なぜ、そしてどのように行うのか - BMC Software | ブログ. [オンライン]. 公開日: 3. [アクセス日:
[2023年4月14日]。4: GitLab。継続的インテグレーションでシフトレフトを実現する方法 | GitLab。
[オンライン]. 公開日: 4. [アクセス日: 2023年4月14日]. 5: DZone. DevOpsとシフトレフトの原則 - DZone.
[オンライン]. 閲覧可能日: 5. [アクセス日: 2023年4月14日]. 6: Devopedia. Shift Left - Devopedia. [オンライン]. 閲覧可能日: 6.
[アクセス日: 2023年4月14日]

組織で NIST SP 800-53 r4 制御フレームワークを適切に実装するには、まず情報システムのセキュリティ分類を実行する必要があります。セキュリティ分類とは、情報システムおよびそのシステムによって処理、保存、送信される情報の機密性、整合性、可用性の損失によって生じる、組織の業務、組織の資産、個人、他の組織、および国家への潜在的な影響を判断するプロセスです。セキュリティ分類は、FIPS 出版物 199「連邦情報および情報システムのセキュリティ分類の標準」の適用に基づいており、低、中、高の 3 つの影響レベルを定義しています。セキュリティ分類は、NIST SP 800-37、改訂 2「情報システムおよび組織のリスク管理フレームワーク: セキュリティとプライバシーのためのシステムライフサイクルアプローチ」に記載されているリスク管理フレームワーク (RMF) の最初のステップです。セキュリティ分類は、情報システムのセキュリティ要件を特定し、NIST SP 800-53 r4（連邦政府の情報システムおよび組織のためのセキュリティとプライバシー管理）に基づいて、ベースラインセキュリティ管理策の初期セットを選択するのに役立ちます。その後、ベースラインセキュリティ管理策は、組織固有のニーズ、リスク要因、コンプライアンス義務12に対応するために、必要に応じてカスタマイズおよび補完することができます。
参照：
SP 800-53 Rev. 4、連邦情報システムのセキュリティとプライバシー制御 ...
SP 800-37 Rev. 2、情報のリスク管理フレームワーク...

説明
継続的監査とは、定期的なスナップショットや証明に頼るのではなく、クラウド環境における統制とコンプライアンスの現状を保証する監査手法です。継続的監査では、継続的な監視データと自動化ツールを活用してコンプライアンスの証拠を収集・分析し、逸脱や問題を監査人や関係者に警告することができます。継続的監査は、クラウド環境における統制とコンプライアンスの有効性に関するよりタイムリーで頻繁なフィードバックを提供することで、認証や監査などのポイントインタイムの保証アプローチを補完することができます。参考文献：ISACA、「Certificate of Cloud Auditing Knowledge (CCAK) Study Guide」（2021年）、p. 821 ISACA、「Cloud Auditing Knowledge: Preparing for the CCAK Certificate Exam」（2021年）、p. 30

PaaS (Platform as a Service) 開発環境に関するメトリクスは、多くの場合未成熟です。これは、PaaS が比較的新しく進化を続けるクラウド サービス モデルであり、クラウド アプリケーションの開発、テスト、展開、管理のためのさまざまなツールとプラットフォームを提供しているためです。PaaS メトリクスは多くの場合、明確に定義されておらず、標準化されておらず、さまざまなプロバイダーやプラットフォーム間で一貫性がないため、PaaS サービスの価値とパフォーマンスを十分に把握できない可能性があります。また、PaaS メトリクスは、アプリケーションの種類、複雑さ、品質、カスタマイズと統合のレベル、使用パターンと需要、セキュリティとコンプライアンスの要件など、さまざまな要因に依存するため、測定、監視、比較が困難な場合があります。したがって、PaaS メトリクスでは、PaaS サービスの有効性、効率、信頼性、セキュリティについて、クラウド カスタマーや監査担当者に十分な洞察や保証を提供できない可能性があります12。
参考文献:
* クラウドコンピューティングサービスのメトリクスの説明 - NIST
* 成功を測定するために必要なクラウド KPI - VMware ブログ