AWS Summit Japan 2024 Day1 セションレポート「安全とスピードを両立するために ~ DevSecOps とプラットフォームエンジニアリング~」

カスタマーサクセス部の井出です。
AWS Summit Japan 2024 にてセッション「安全とスピードを両立するために ~ DevSecOps とプラットフォームエンジニアリング~（AWS-09）」に参加したため、重要と思った箇所のまとめを記載します。

オンデマンド配信: japansummit.awslivestream.com

資料: https://pages.awscloud.com/rs/112-TZM-766/images/AWS-09_Builder-Experience_AWS_Summit_JP_2024.pdf

参加目的

参加目的としては、最近DevSecOpsに興味があり、開発サイクルの全体像やどのようにSec部分を導入するかを学ぶことです。

セッション概要

ご登壇: アマゾンウェブサービスジャパン合同会社金森政雄氏

内容

安全とスピードが求められる理由

デプロイ頻度が高い・変更のリードタイムが短いほど変更の失敗率は下がる。
デプロイ頻度が低い・変更のリードタイムが長いほど変更の失敗率が上がる。
→ スピードと品質は比例する

アジリティのための分割

モノリスの開発の課題
- 変更が競合したり、別の開発に影響を与える可能性
  → 調整の負担が増える
- デリバリーパイプラインが1本しかなく変更が滞留してしまう
  → 開発スピードが落ちる
マイクロサービスの開発のメリット
- 変更の競合、別の開発への影響が小さくなる
- 同時並行で複数のデリバリーが可能になる

自動化

マイクロサービスの開発となることで、計画・開発~運用までを一つのチームで担うことになる
→ 自動化することがポイントになる

DevSecOps

ShiftLeftの考え方

セキュリティへの取り組みを開発サイクルの早い段階に移すこと
→ 早い段階に移すとは、テストやリリースの段階でセキュリティチェックをするのではなく、設計やビルドの段階から考慮するということ
→ セキュリティの問題を放置放置することなく、迅速なデリバリーが可能になる

開発の各段階で導入できるセキュリティ対応

ローカル開発

IDEプラグイン
Pre-Commitフック
コードレビュー

Build

静的解析（SAST）
ソフトウェア構成解析（SCA）
ライセンスチェック

Test

動的解析（DAST）

パイプライン自体のセキュリティ

ソフトウェアサプライチェーンにも脅威が潜んでいる
例えば

不正な（権限のない）コード変更
ビルド実行環境

対策例

SLSA（Supply chain Levels for Software Artifacts）を使用したソフトウェアサプライチェーンの評価

プラットフォームエンジニアリングと運⽤モデル

こちらは割愛します。
実際にチームで開発を進める際の方法をご説明されていました。

印象に残ったこと

パイプラインに組み込まず、個人ですぐに対応できるものがあること（IDEプラグインやPre-Commitフック）
→ 導入が容易なので導入がしやすいため、チームで標準として取り入れてセキュリティ対策の一歩としても良いのではないかと思いました。
パイプライン自体のセキュリティ
→ DevSecOpsと聞くとソフトウェアチェックの視点のみになりがちでしたが、パイプライン自体のセキュリティにも目を向ける必要があると改めて認識しました。
AWSでできるハンズオン・検証方法があること
→ 「Security for Developers ワークショップ」や「SLSAの検証」の紹介がセッション内でありました。実際にやってみて今後ブログにしようかなと思います。

まとめ

最後までご覧いただきありがとうございました。

本セッションで出てきた「Deployment Pipeline Reference Architecture」は一度目を通すと理解が深まると思います。 pipelines.devops.aws.dev

個人としては今CDKを使用しているため、下記のセッションもオンデマンドで見てみようと思います。 japansummit.awslivestream.com

他のセッションについても2024年7月5日までオンデマンドで配信や資料公開もされています。
興味のある方はこちらよりご視聴ください。