Shift left導入は、迷走の連鎖
近年、CSPM(Cloud Security Posture Management)をはじめとしたクラウド設定管理の取り組みが広がり、さらにその発展形としてCNAPP(Cloud Native Application Protection Platform)を導入する組織も増えてきました。クラウド環境全体を横断的に可視化し、リスクを一元的に管理する動きは、すでに一般的なものになりつつあります。
その一方で、「本番環境での検知や対処だけでは十分ではないのではないか」という課題意識も高まっています。クラウド運用側だけでなく、開発段階からセキュリティを意識し、早いフェーズでリスクを是正すべきだという考え方が広がってきました。
こうした流れの中で注目されているのが、「Shift left」というアプローチです。
考え方自体はシンプルですが、実際の開発・運用プロセスに組み込もうとすると、「何から始めるべきかわからない 」と感じる方も少なくありません。
例えば「Shift left」とネットで検索してみると、SASTやSCA、IaCスキャンなど、対象も役割も異なる機能や仕組みが混在して検索結果に表示されます。 そのため、「結局どこから着手すべきなのか」「自社の開発プロセスでは何が足りていないのか」が捉えにくい傾向があります。
それらを踏まえ、今回はShift leftを取り入れる際 によく起こる課題を、開発者/運用者目線それぞれで取り上げつつ、それらの課題をOrca Security社のOrcaプラットフォームでどのように解決できるか、ご紹介していきます。
Shift leftを取り入れた際によくあるお悩み
ここからは、Shift leftを取り入れた組織が実際に直面する課題について、開発者と運用者それぞれの視点から整理していきます。
開発者側で起きがちな課題
Shift left を進める多くの場合、運用側では既に別のセキュリティツールを導入していることがほとんどです。そのため、Shift leftを進めようとすると、「開発の初期段階でセキュリティチェックをしてほしい」という要望だけが先行し、開発者側には新しいツールが次々と追加されることになります。 開発者はその都度、新しいツールの使い方を覚え、動作を確認しながら、「この指摘は本当に対応すべきなのか」という判断をしなければなりません。結果として、通常の業務に加え、新ツールにも時間を割り当てる必要が出るため、大きな負荷となるケースがあります。
また、SASTやSCAなどの機能を持ったツールを導入した結果、ツールから多くの指摘が出てくるものの、それらの優先順位が付けられていないケースがあります。ツールによって修正推奨箇所が大量に検知される一方で、その脆弱性が「実際に攻撃される可能性があるのか」「本番環境で外部に公開されているのか」「機密データに影響するのか」といった点までは分からず、結果として、本番への影響度を判断できないまま、目の前のアラートを一つずつ対処していかなければならず、作業負担が増加します。
運用者側で起きがちな課題
一方、運用者側にも別の課題があります。
例えば、開発時にどのようなセキュリティチェックが行われていたのか分からず、本番でリスクが見つかっても、その背景をすぐに追えないというケースがあります。
具体的には、発見したリスクがどのコードやIaCテンプレートでデプロイされたか確認するために、その都度開発者へ問い合わせが必要となり、対応が長期化することがあります。
また、時間の経過とともに顕在化するリスクも考慮すべき要素の一つです。
開発時には問題ないと判断された設定やコードが、本番環境や運用の中で、後から重大なリスクとして浮かび上がることもあります。
開発と運用が分断されたままでは、こうした「時間差のリスク」を追いかけることが難しくなります。この点も、Shift leftを実運用に落とし込むうえで避けて通れない課題です。
Orca Securityで実現するShift left（AppSec/IaC）
こうした課題に対し、Orca Security（以下「Orca」と記載 ）は開発から運用までを分断しないShift leftを実現 します。
実際の開発現場では、TerraformやCloudFormationを用いたIaCをCIパイプラインで回し、tfsecやcheckovなどのツールで静的なセキュリティチェックを行っているケースがよくあります。
しかし、CI上のIaCスキャンでセキュリティチェックを止めてしまうと、「本番環境で実際にどうなっているか」は運用側の管理になり、開発側の判断と運用側のリスク把握がつながりにくくなります。
OrcaではGitHubなどのリポジトリ連携により、IaCをプルリクエスト（PR）単位で自動スキャンできます。IaCの変更により新たに混入した構成ミスやポリシー違反などを検出し、「この変更で何が問題になったか」を開発の段階で把握できるようになります。
単なるルール違反の指摘にとどまらず、変更内容とリスクを結びつけて把握できるため、開発者は実稼働時の影響をイメージしながら対応できます。
またOrcaの特徴として、開発段階だけでなく本番環境も同じプラットフォームで可視化できる点があります。IaCテンプレートを使ってデプロイされたクラウド資産に、継続的にリスクチェックが行い、担当者はその詳細な情報を確認することができます。
その結果、「この本番リソースは、どのIaCコードからデプロイされたのか」「開発時にどんな設定変更が行われていたのか」といった情報を、UI上で追跡できます。
これにより、開発者と運用者が別々の画面/別々の根拠で判断する状態から、同じ事実、つまり「どのコード変更が、どのクラウド資産に影響したのか」を整理したうえで、アラートに対処していくことができます。
まとめ
Shift leftは、単にセキュリティチェックのタイミングを早期化し、開発側に対応を求める考え方ではありません。
重要なのは、開発と運用が同じリスクを、同じ基準で理解できることです。
弊社では CNAPP×AppSec 製品として、Orca Security社のOrcaプラットフォームを提供しています。
クラウド全体を統一されたリスクスコアで可視化し、変更内容や機密情報といったコンテキストを踏まえてリスクの優先順位付けを行います。これにより、CI/CDと本番運用のどちらにおいても、同じ判断基準でリスクを捉えながらShift leftを進めることができます。
また、導入前にOrca プラットフォームの検出結果や精度をご確認いただける無償アセスメントサービスに加え、実際の使用感をお試しいただけるPoC のご提供も可能です。
クラウドセキュリティやShift leftの実運用でお悩みがありましたら、ぜひお気軽にご相談ください。
