Snyk導入によりセキュリティリスクの可視化、対策の効率化が可能に

Snyk導入前は、緊急性のある脆弱性に対して、どのリポジトリ・ファイル・Imageが対応する必要があるのかをエンジニア総出で調査する必要がありました。またPRレビューでセキュリティチェックはしていたものの、レビュワーの経験値に依存している状態でした。

そのため、下記2点に対応できる環境を整備するため、ツール導入の検討をスタートしました。

1. どこにリスクがあるのか、またそのリスクに対応するために必要な情報が、ダッシュボードで一覧的に入手できる
   
2. CIでのレビュー依存を脱却し、脆弱性が存在する場合は自動でデプロイされない
   

ツールを比較するに当たっては、

1. SREの人数が少ないので、その人数で脆弱性のトリアージができること
   
2. 開発者が対応する際にどのように対応すれば良いかがわかりやすいこと
   
3. CIに組み込めること
   の3点を意識して検討をしました。
   

比較したサービス

• Trivy
  
• Aqua
  
• Amazon Inspector
  

Snyk導入の決め手となったのは下記のポイントです。

• ダッシュボードで、セキュリティリスクの状態が分かりやすいという点。特にどのように対応すれば良いのかがわかるサジェスト機能が良かった。
  
• BaseImageをどれに更新するとどれくらい脆弱性が減るか予め分かる点
  
• ECRのImageをScanする場合に、Tagで追跡して継続的にScanしてくれる点
  
• OSSライブラリの脆弱性指摘に対して、Fixの有無や、依存関係先のどこで脆弱性があるのかが分かりやすく表示してくれる点
  
• VSCode拡張、CIへの組み込み、イメージリポジトリのScan、EKS上のImageのScanと一気通貫で対応できる点
  
• 全社的なチェックルールが作れる点
  
• Importして設定するだけで、PR Checkが可能な点
  
• 課金体系が開発者数単位である点
  

Snykのダッシュボードによって、セキュリティリスクの可視化は達成できました。
実際に運用をスタートして、対応すべき脆弱性が出てきた時も、対応が必要なリポジトリをスプレッドシートに整理し、エンジニアに周知するまで30分以内に完了できました。

また、PR Checkについても、Importして設定するだけで有効にでき、現在は全てのリポジトリに対して脆弱性チェックができている状態です。

脆弱性がある程度減るまでは、トリアージの量が多く、開発者の工数もかかり、定常運用に乗せるまでが苦労しました。またセキュリティ対応することと通常の開発の優先度調整ができるまでが大変でした。

Snykを使っている中で失敗したエピソード

1. GitHubのBranch protection ruleでSnykのPR Checkをrequiredにした場合に、Snyk側に障害があるとマージができなくなりました。一時的にrequiredを外して対応し、Snyk側が回復したタイミングで再度requiredに戻しました。
   
2. 最初はCritical、Highも含めてSREがトリアージしていましたが、対応が回らなくなったのでトリアージ対象をCriticalのみに絞った運用に変更しました
   

開発者数課金なので、開発組織によって向き不向きがあります。比較的少数の開発者で多くのリポジトリをメンテナンスしている組織では、リソース課金のツールよりも低価格で使えます。
脆弱性指摘の修正方法のサジェストが強力なので、開発者からの抵抗が少ないことや、修正工数の低減が期待できます。
なによりダッシュボードが見やすくて強力なので、兼務でセキュリティ管理をしている組織にとっては使いやすいと思います。