yamoryを利用した開発チームとセキュリティチームを横断する脆弱性管理

ツール導入前の課題

組織拡大フェーズでのセキュリティ担保

サービスに利用しているOSSの脆弱性対策、ライセンスのリスク管理、パッチマネジメント、EOL管理などが属人的になっていた。新製品開発のため組織拡大が必要になり、特定のリーダーの力量によらないセキュリティ対策の仕組みが必要になった。各サービス開発チームで利用するツール、その開発チームを裏で支援するセキュリティチームが利用するツールが必要となった。

どのような状態を目指していたか

• セキュリティ対策の属人化解消
• セキュリティチームによる対策状況の把握＆監査

• Snyk
• JFrog

• コスト
• カバー範囲（SCAが必須）
• 運用が回せること

運用可能な機能がそろっており低コスト、且つ、スモールスタートでの導入が可能だったこと

改善したかった課題はどれくらい解決されたか

• 新メンバーがリードする製品であっても基準が守られる状況になっている
• セキュリティ担当者が各チームの脆弱性対策状況を一元的に確認できるようになっている

どのような成果が得られたか

• SCAをCICDに組み込むことで、リリース関門としている外部業者によるWebアプリケーション診断で深刻なエラーを指摘されるケースがほぼ無くなっている
• AWSで動作中の本番環境に対するホストスキャン、コンテナスキャンの抜け漏れがなくなった
• 本番環境に対するホストスキャン、コンテナスキャンによる脆弱性検出タイミングの高速化と抜け漏れ防止と第三者チェックの実現
• サービス開発チームの状況をセキュリティチームでWatchする運用が回せるようになった

新サービスでウォーターフォールからアジャイルに移行した。それに伴いSCA、SAST、DAST、CSPM、リリース判定基準などセキュリティ全般のルール改定と、その基準を満たす為の開発・運用体制の構築

サービス開発のセキュリティ対策をどこから手を付けるか？は悩ましい問題だと思います。これから着手する方や改めて対策の見直しを検討されている方は、IPAが公開している安全なウェブサイトの作り方に立ち返るのをお勧めします。こちらのサイトを確認して頂くと「SQLインジェクション」「OSコマンドインジェクション」などの一般的な対策が記載されています。これらは有名なフレームワークを利用して開発し、適切にパッチをあてていれば対策することは可能です。開発完了時には顕在化していなくとも日々脆弱性は増え続けますので、脆弱性管理ツールを活用して対策していくことをお勧めします。yamoryはSCAを中心とした機能がシンプルに提供されていますのでとっつきやすいと思います。ツールを導入しただけでは意味が無いので運用についても併せて検討して下さい。

現在はAWSで稼働しているサービスを中心にyamoryで運用しているのですが、Azureやオンプレミスのシステムにも広げていきます