3月14日、「セキュリティの自動化に向けたDevSecOpsの推進と苦労」に参加してきました。
今回はモデーレータのファインディ株式会社 北川 雅士 @OnigiriMa_shiさん、Ubie株式会社 水谷 正慶 @m_mizutaniさん、Snyk1社 相澤 俊幸 @ToshiAizawaさんを交えた座談会形式の回でした。
DevSecOpsとは
まず最初に、スピーカーのみなさんがDevSecOpsをどう定義づけているかという話題。
相澤さんは、以下のように定義されていました。
- ソフトウェア開発・運用モデルDevOpsにセキュリティを包含したもの
- DevOpsはソフトウェアデリバリの加速
- DevSecOpsによりセキュリティを考慮してもソフトウェアデリバリの速度が落ちない
- セキュリティは従来では開発の後の方でやっていたが、上流で行う
水谷さんの場合は、「厳密な定義はしていない」と前置きしつつ、以下のお話をされていました。
- プロダクト開発の工程の中で、エンジニアリングによってプロダクトの安全性を向上させる仕組みを構築・展開していく取り組み
- 人間による対応には限界がある
- ソフトウェアの力でスケールさせる
- Devの概念を取り入れてSecをやっていく
DevSecOpsにおける課題と悩み・乗り越え方
- Ubie社における推進や苦労したこと
スピーカーはUbie株式会社 水谷 正慶 @m_mizutaniさん。
- 推進するメンバーの必要性
- セキュリティに詳しいだけでは不十分。プロダクト開発、セキュリティ両方見通せる人が必要
- 文化や取り組みの浸透
- セキュリティとは別の問題(たとえば直近のビジネスの問題)に目が行きがち
- 対応策として
- DesignDocを作ってデザインレビューを導入している
- 脆弱性対応に関するガイドラインの作成
- セキュリティチームによる毎週のチェックと呼びかけ
- 自動化にも限度がある
- トリアージが困難
- 把握しきれない問題もある
- 対応策として
- CIによるセキュリティチェック
- プロダクトの脆弱性管理ツールの導入
- 海外で起きていること・事例など(Snyk社)
スピーカーはSnyk社 相澤 俊幸 @ToshiAizawaさん。
従来のセキュリティは「ノー」ということが仕事(「脆弱性があるからリリースできませんよ」ということ)だったが、
近年では、セキュリティ担当者がより有効的になり、サービスを利用する人々に重点が置かれるようになってきたとのことです。
Log4Shell(CVE-2021-44228)の脆弱性対応に関する調査2によると、Log4Shell修正対応に数週間から1ヶ月以上要したとの回答が52%とのことで、脆弱性対応の難しさがよく分かる結果でした。
Synk顧客でLog4Shell(CVE-2021-44228)を2日間で修正対応した割合についても紹介されていて、こちらは91%とかなり迅速に対応できているようです。DevSecOpsがセキュリティを重視しつつ開発の速度を落としていない好例と言えるのではないでしょうか。
また、Snyk社はセキュリティチェックの自動化を行うプロダクトを提供している会社ですが、前のトークでの水谷さんの「自動化にも限度がある」という発言には強く共感されていて、「自動化でできること・できないことの切り分けは重要」と話されていました。
DevSecOpsを考えるときにまずやること・意識すること
最後に、DevSecOpsを考えるときにまずやること・意識することについての話題。
水谷さんは以下を挙げられていました。
- investの小さい施策から始める
- 対応するメンバーのワークフローまで考えながら仕組み化する
- 全体としての統制や情報の管理をどうするかを考える
相澤さんは以下を挙げられていました。
- 開発の戦力化(みんながセキュリティに強くなるのは現実的に不可能なので、ツールの力を借りて強くなる)
- Test early, test often, and test fast
最後に
昔はセキュリティというと専門性が高くて分業化されているイメージが強かったのですが、近年ではDevOpsの文脈に組み込まれて、誰でも関わる分野になってきているようですね。
考えてみればソースコードレビューも静的解析ツールを使ってレビューアーの負担を軽くするなど、スーパーエンジニア的な人に頼らない傾向があります。
最短経路で成果を挙げるためには、自分自身が強くなる発想以外にも「以下に楽するか」3も考えるとよさそうです。
-
読みは「スニーク」です。 ↩
-
https://blog.isc2.org/isc2_blog/2022/02/log4j-remediation-exposes-cybersecurity-workforce-gap.html ↩
-
「プログラマの三大美徳」的な意味で ↩