Skip to main content

Snykで継続的なセキュリティを実現したAxel Springer National Media and Tech

feature customer axel springer

2024年9月3日

0 分で読めます
How Axel Springer NMT Automated Dev-First Security in the SDLC

今年のAWS Summit Berlinで、SnykチームはSnykのお客様である、Axel Springer National Media and TechのCISO、Michael Steiner氏と話す機会を得ました。対談では、Steiner氏のチームとのパートナーシップをはじめ、Log4Shellを受けてSnykの導入を決めた経緯、既存の開発プロセスへのSnyk CodeとSnyk Open Sourceの実装、そしてチームが現在測定している具体的な成果について話し合いました。Axel Springerのシフトレフトセキュリティの取り組みについて、詳しくご紹介します。

Axel Springer National Media and Techの概要

Axel Springerは、ヨーロッパを代表するデジタルパブリッシャーです。同社のNational Media and Tech事業部門は、新聞社やその他のメディアブランド向けにテクノロジーサービスとデジタル製品を提供しています。600を超えるブランドがAxel Springerのデジタルジャーナリズムソリューションを利用し、300万人を超えるユニークユーザーが同社のデジタル製品やアプリケーションを活用しています。

Axel Springerのチームはフラットな組織体制を採用し、品質保証、IT、セキュリティについて、開発チームが共同で責任を担っています。開発者は自社製品を最もよく理解しているため、こうした取り組みをシームレスに統合する最適な方法も把握していると考えています。このフラットなモデルの一環として、Axel Springerの開発者は主にAWS上で自らのInfrastructure as Code(IaC)を運用しています。

「大規模なセキュリティチームやSOCはありません」とSteiner氏は説明します。「開発者がこの役割を担えると考えています。脆弱性をできるだけ早く、効率よく修正できるよう開発者を支援し、自動化されたプロセスもサポートするツールを整えることが重要です」

一貫性のないセキュリティプロセスとツールの課題

Snykを導入する前、Axel Springerには、コード内の脆弱性を検出・修正するための全社共通の一貫したプロセスがありませんでした。SonarCloudなどのオープンソースAppSecツールを一部で使用していましたが、全社には展開されていませんでした。さらに、この方法で静的コード解析を導入できたのは一部のチームに限られ、IaC、オープンソース、コンテナなど、組織のアプリケーション開発構造におけるその他の重要な要素をカバーできていませんでした。

また、Axel Springerのチームはアプリケーションをエンドツーエンドで可視化できておらず、各リポジトリにどのような脆弱性が含まれているのかを把握するのが困難でした。開発チームはすべてのセキュリティプロセスを手作業で進めており、多くの時間と労力を要していました。たとえばLog4Shellへの対応では、組織全体のデータ利用状況を手作業でスプレッドシートにまとめ、その結果を基に修正措置を講じていました。

「少なくとも全社で統一された、実質的なプロセスはありませんでした……脆弱性の可視性もありませんでした。各チーム自身も、リポジトリ全体にどれだけの脆弱性があるのか把握していませんでした」

— Michael Steiner氏、CISO、品質・ITセキュリティコンピテンスセンター責任者、Axel Springer

Snyk CodeとSnyk Open Sourceでシフトレフトを実現

Axel Springer National Media and Techの大半のチームが手作業でLog4Shellの脆弱性の該当箇所を探していた一方、あるチームではSnykの概念実証(POC)を実施していました。このチームはSnykの効果を実感し、リポジトリ全体でLog4Shellの利用箇所をすばやく特定して、従来の何分の一もの時間で対処できました。

Steiner氏によると、「Snykの[POC]では、このチームが脆弱性の影響を受けた箇所を簡単に特定できました。それをユースケースとして経営陣に示し、『こうした透明性を実現するには、このようなツールが必要です。特に脆弱性が発生したときには不可欠です』と伝えました」

このインシデントを受け、Axel SpringerのチームはSnyk CodeとSnyk Open Sourceを導入し、脆弱性を開発パイプラインの早い段階で検出・修正できるよう開発者を支援しています。

「現在、Snyk CodeとSnyk Open Sourceを700以上のリポジトリで利用しており、300人の開発者がこれらのツールを使っています……IDEやパイプラインに実装し、Jiraと連携させ、多くのプロセスを自動化できました。すべてSnykのおかげです」

— Michael Steiner氏、CISO、品質・ITセキュリティコンピテンスセンター責任者、Axel Springer

Snykチームは、以下のステップを通じてAxel Springerのソフトウェア開発ライフサイクル全体に統合しました。

  • 統合開発環境(IDE)内でスキャンし、プルリクエスト時に修正を提示

  • コマンドラインインターフェース(CLI)スキャナーでCI/CDパイプライン内をスキャン

  • 既存のすべてのリポジトリをSnykと同期し、パイプラインの後続段階で脆弱性を特定して担当チームに通知

  • 本番環境の脆弱性を特定(ゼロデイ脆弱性や新たな脅威など)

Axel Springerのセキュリティを完全に可視化

現在、Axel Springer National Media and Techのチームでは、対象リポジトリの90%以上をセキュリティスキャンできています。この高いカバレッジにより、既存コードやオープンソースに含まれる脆弱性を完全に可視化できるようになり、SDLC全体を通じて新たな脆弱性を継続的に修正できています。

Steiner氏は次のように述べています。「今では状況を可視化でき、脆弱性を継続的に修正するプロセスを導入するよう各チームに働きかけられます。脆弱性をたまに確認するだけでは不十分なので、これは重要です。この可視性は、こうした課題を経営陣に提起するうえでも役立ちます。私たちにとって最も重要な価値は、この可視性だと思います。それを実現してくれるのがSnykです」

今後、チームはSnyk Open Sourceのライセンスコンプライアンス機能をより頻繁に利用したいと考えています。これにより、見込み顧客のライセンス要件に基づいて、どの製品やリポジトリを他社に販売するかを判断しやすくなります。

さらに、今後はよりリスクベースのアプローチへ移行する予定です。プロジェクトをビジネス上の重要度で分類し、組織への潜在的な影響を正確に評価するリスクスコアに基づいて、脆弱性に優先順位を付けることを目指しています。これにより、脆弱性の正確な所在に応じて、最も重要な修正を優先できます。こうした取り組みを支援するため、Snyk AppRiskの導入を計画しています。

続きを読む

Blog

フロンティアモデルは脆弱性を発見した。攻撃者だけがエクスプロイトチェーンを見つけた。

静的解析で欠陥は見つかりましたが、ライブ攻撃テストで侵害につながる連鎖を実証できたのは唯一でした。Evo COS、Claude Security、Claude Code Securityを比較します。

feature insights context
Blog

自律型攻撃はすでに始まっている。防御もそのスピードに追いつかなければならない。

自律型攻撃者によって、防御に使える時間は短くなっています。継続的な検出、修復、検証、予防で、セキュリティチームが攻撃に歩調を合わせる方法をご紹介します。

Blog

AIコーディングエージェントが不適切なアクセス制御を繰り返し実装する理由

AIコーディングエージェントは、コンパイルが通りレビューも通過する一方で、あるテナントのデータを別のテナントに公開してしまう認可ロジックを生成することがあります。不適切なアクセス制御が検出しにくい理由と、その防止策をご紹介します。