DevSecOps: CD パイプラインへのセキュリティの組み込み

DevSecOps が CD パイプラインに与える影響と、アジャイル開発チームのセキュリティに対する姿勢について説明します。

Juni Mukherjee Juni Mukherjee

DevSecOps とは?

DevSecOps は、セキュリティに焦点を当てた継続的なデリバリーのソフトウェア開発ライフ サイクル (SDLC) を説明する用語です。DevSecOps は、一般的な DevOps の知識とベスト プラクティスに基づいて構築されています。ソフトウェア セキュリティに DevOps の価値を適用することで、セキュリティ検証が開発プロセスの有効な一部分として統合されます。従来は残念なことに、セキュリティはセカンダリ システムとして扱われてきました。通常、情報セキュリティチームは SDLC の最終段階に近づいた頃に開発チームと関わります。彼らの志が崇高な分、SDLC の最後にセキュリティの脆弱性が発見されることは苛立たしいものです。

DevSecOps は、SDLC のアクティブなプロセスに従来のセキュリティ エンゲージメントを促進します。一般的な DevOps は、継続的インテグレーション (CI) や継続的なデリバリー (CD) などのプロセスを導入しています。これらのプロセスによって、アジャイル開発プロセス中のコードの正確性のアクティブなテストと検証が保証されます。同様に、DevSecOps は、アクティブなセキュリティ監査とペネトレーション テストをアジャイル開発に組み込みます。DevSecOps は、セキュリティを完成品に適用するのではなく、製品に組み込むことを提唱しています。

鍵を差し込んだ錠前 | Atlassian CI/CD

なぜ DevSecOps なのか?

要するに、セキュリティです。安全でセキュアなソフトウェアの必要性は最重要です。さもないと、テクノロジー主導の生活が危険に晒されます。セキュリティ侵害は今日、組織と政府が直面している最大の脅威の 1 つです。近年、いくつかの大きな組織で情報漏えいが発生して、大規模なフォールアウトと経営幹部の突然の辞任を引き起こしています。消費者が侵害されたサービス プロバイダーへの信頼を失い続けているため、エグゼクティブの失敗が新聞を賑わせています。

DevSecOps の原則は共同作業を促進し、セキュリティ専門家へのハンドオフの遅延を防ぐことです。前後のサイクルタイムの違いを見ればその価値は明らかです。DevSecOps の導入以前は、最後の最後に製品が安全ではないと見なされ、コストが倍増するイテレーションを引き起こすことがありました。DevSecOps の導入後は、製品にセキュリティのゴールドスタンダードが組み込まれます。最後の最後で予期しない問題が発生する可能性はありますが、その確率は非常に低くなるでしょう。

したがって、要点は「なぜ DevSecOps なのか?」ではなく、むしろこの DevSecOps の時代にどのように正常に実行できるかです。従来のセキュリティ対策に巻き込まれている人々にとって、DevSecOps は新しい風です。ソリューションは、お客様のテクノロジー スタックとアーキテクチャによって異なる場合があります。これは、一元化された組織からの「万能であること」の命令ではありません。

全体として、セキュリティに対する姿勢は市場における信頼性を高めて、消費者との信頼関係を築きます。そのことを念頭に置くと、これは、DevSecOps が継続的なあらゆるもののパラダイムにどのように結びついているかを議論するのに良い話題の導入になります。

DevSecOps と継続的なあらゆるもの

セキュリティの脆弱性は、記述されたコードの中だけでなく、インポートする OSS (オープンソースソフトウェア) ライブラリにも存在する場合があります。大勢の開発者が毎日プログラミングを行っても手動のコードレビューは成長しません。ここで DevSecOps が本当の力を発揮します。

DevSecOps と継続的なあらゆるものは、表裏一体のようなものです。DevSecOps は継続的なあらゆるもののパラダイムと連携して、当社のソフトウェア成果物の保護に継続性をもたらします。

継続的なあらゆるもののパラダイムの実装である継続的なデリバリー パイプラインは、当社のチームが作成するすべてのコミットを検証するのに役立ちます。自動化されたセキュリティ チェックをパイプラインと統合して早期警告を提供し、見過ごされたセキュリティの脆弱性を絶えず監視します。統合された継続的なセキュリティ アプローチは、ビジネスの拡大に合わせて拡張できます。

ユニット テストと静的コード分析の動作は両方ともソース コードに最も近く、コードを実行せずにチェックを実行します。欠陥から生じるコストは、テスト環境では低く、ステージング環境では中程度、本番環境では高くなることを覚えておいてください。そのため、セキュリティのユニット テストと静的分析ツールに投資してください。これらは安価で高速であり、パイプラインのさらに下位で手間を省けるからです。

継続的なセキュリティの実装: ユニット テスト

継続的なセキュリティの最初の実装は、単体テストのセキュリティに行う必要があります。

継続的なデリバリー パイプライン 101 では、コンポーネントを配布可能でテスト可能な最小のユニットとして定義しました。コンポーネントはユニット テストで検証できます。セキュリティのユニット テストは当社が作成する他のユニット テストと同じく重要ですが、一部のチームは依然としてこのカテゴリを完全に見落としています。

SAST

静的コード分析ツールは、コーディングのベスト プラクティスの違反を検出すると同時に、所有しているコードおよびインポートする (安全でない可能性がある) ライブラリ内のセキュリティの脆弱性を検出します。これは静的解析セキュリティ テスト (SAST) と呼ばれて、最新のツールは継続的なデリバリー パイプラインとうまく統合されています。選択したプログラミング言語と互換性のある SAST スキャナを選択していることを確認してください。

注意: SAST は誤検出を報告することが多いため、パイプラインが「記憶」するのに役立つ永続的なレイヤーを計画します。誤検出は、壊れたパイプラインの通知への応答を停止する時点までチームを悩ませる可能性があります。これは危険です。チームがエラーを正当な理由で誤検出として特定したら、パイプラインに何度もフラグを立てないようにしてください。これによって、チームが SAST を無効にしたり、パイプラインに SAST エラーを完全に無視させたりする可能性があります。

DAST

ゆるく結合したコンポーネントがサブシステムを形成します。サブシステムは DAST (動的解析セキュリティテスト) を使用してデプロイされ、セキュリティの脆弱性がテストされます。SAST とは異なり、DAST は攻撃者の手法と同様に、実行状態にあるアプリケーションを外側から観察します。DAST スキャナーは外側からアプリケーションとやり取りするため、特定の言語に依存しません。

重要なことは、SAST と DAST の両方をセキュリティ戦略に含めることです。理由は、それぞれが独自のメリットをもたらすからです。両方のアプローチを CD パイプラインと統合することで、早期にフィードバックを得られます。

DevSecOps はセキュリティの未来

今日の世界では、セキュリティは品質同様、すべての人の仕事です。自称エキスパートがもたらすサイロによってビジョンが制限されないようにしてください。かつては悲惨な結果に直面していたリアクティブな企業や経営幹部は、今では新たな予算でセキュリティ戦略を活性化しています。

従来のセキュリティ専門家は、キャパシティがサイロ内のセキュリティ担当者の数によって制限されているサイロで活動します。代わりに、DevSecOps のアジャイルで分散されたアプローチを採用して、チームを再トレーニングして自律的に活動させます。さらに、製品開発チームに説明責任を持たせることで、情報セキュリティ部門と責任の擦り付け合いが生じないようにします。

DevSecOps コミュニティが盛り上がる中で、セキュリティはビジネスの優先事項であるだけなく、継続的なデリバリー パイプラインと統合するための最新で最高のものでもあります。セキュリティを備えた継続性によって、目前に控えるソフトウェア デリバリーの春に備えてください。