Skip to main content

48%が、セキュリティはソフトウェアを迅速に提供するうえで大きな制約になると回答

著者
DevSecOps Assets blog feature

2020年1月28日

0 分で読めます

チームや組織がソフトウェア開発ライフサイクル(SDLC)全体にセキュリティを組み込もうと急ぐなか、さまざまな課題が浮上しています。ソフトウェア提供のペースが速まり、利用できるセキュリティリソースが限られるなか、組織は社内文化の形成から、開発者を支援し、開発ワークフローへのセキュリティの組み込みを可能にし、予定外の作業による中断を最小限に抑える適切なツールの選定まで、文化、プロセス、ツールに関する課題に向き合わなければなりません。

データ侵害が公表されるたびに、顧客のプライバシーや資産、機能のセキュリティ、そして開発スピードを確保するため、SDLCの早い段階から全工程にわたってセキュリティに取り組む必要性への認識が高まっています。すべてをうまく実現するには、DevSecOpsをセキュリティ主導で進めながら、開発者の力を活用する必要があります。

DevOpsを適切に実践することが、DevSecOpsを実現する鍵

DevOpsの成熟度が高い組織ほど、セキュリティプラクティスを導入する可能性が高くなります。DevOpsのツールや文化を十分に取り入れている組織は、セキュリティプラクティスやDevSecOpsをさらに推進できる基盤が整っています。DevSecOpsの実践では、自動化を基盤とし、組織全体のエンジニアが部門を越えて連携し、セキュリティ向上に向けた対策を講じられるようにします。

最近、DevOpsとDevSecOpsの導入状況に関する調査を実施しました。主な調査結果の一つは、回答者の48%が、セキュリティはソフトウェアを迅速に提供するうえで大きな制約になると考えていることです。

DevSecOps Insights 2020のPDFをダウンロード

セキュリティは本当に全員の責任なのか?

組織全体でセキュリティを共有責任とする考え方は、誰もが口にします。それなのに、なぜ多くの場合、実践に移すのは難しいのでしょうか。Puppetの「State of DevOps」レポートは、この問題について、皮肉ではあるもののよくある見方を示しています。セキュリティ上の懸念は、組織全体のセキュリティ態勢を測定可能な形で改善するためではなく、責任を問われないようにする手段として捉えられがちです。

次に重要な問いとして、アプリケーションセキュリティの責任はセキュリティチームだけが担うものなのでしょうか。Snyk State of Open Source Securityレポート2019によると、回答者の81%は、開発者がセキュリティに責任を持つべきだと考えています。しかし、開発者にはそれを実践するための十分な準備ができていません。

「セキュリティの責任者は誰ですか?」という棒グラフ:開発者 81%、セキュリティチーム 28%、運用チーム 23%、担当者なし 12%、その他 3%。

この調査によると、自分が書いたコードとアプリケーションのセキュリティに責任を持つのは開発者です。

開発者がより成果を上げられるようにするには、どうすればよいでしょうか。セキュリティチャンピオンがワークフローにセキュリティをより適切に組み込めるようにするには、どうすればよいでしょうか。さらに議論を呼びそうな問いとして、セキュリティ修正の適用と発見、それぞれの責任は誰が担うべきでしょうか。

DevSecOpsのプロセスが広く取り入れられるにつれ、セキュリティが迅速な開発サイクルの妨げになるのではないかと考える人もいます。アジャイルチームのソフトウェア提供を加速させるものとして評価されるDevOpsとは異なり、セキュリティは開発を遅らせるものと見なされています。チームは、機能の提供を急ぐビジネス関係者からの強いプレッシャーにさらされ、技術的負債やセキュリティ上の問題よりも機能の提供を常に優先するよう求められます。こうした問題は未対応のまま残り、開発の遅延につながる可能性があるだけでなく、ビジネスに重大なリスクをもたらします。

実際、Puppetのレポートによると、回答者の48%は今も、セキュリティがソフトウェアを迅速に提供するうえで大きな制約になると感じています。

従来のセキュリティプラクティスは、たとえばリリースをQAに移す段階など、SDLCの後半で実施されます。短いスプリントを基盤とするアジャイルなソフトウェア開発を実践しているチームでも、セキュリティレビューは四半期ごとなど、頻繁には実施されません。また、開発や自動ビルド、テストの段階に組み込まれていません。

ソフトウェアデリバリーの制約としてセキュリティを挙げた割合をDevOpsレベル別に示す棒グラフ:レベル1は31%、レベル2は42%、レベル3は48%、レベル4は43%、レベル5は33%。

ツールの統合が鍵

ソフトウェアは「世界を飲み込んで」おり、その勢いは衰えていません。ソフトウェア・デファインド・ネットワーキングから、従来型サービスの管理全体を抽象化するクラウドプロバイダーまで、従来のテクノロジーが次々とソフトウェアの世界に取り込まれています。Infrastructure as Code(IaC)もその一例です。

ソフトウェアが私たちを取り巻く世界をますます制御するようになるなか、開発者はコードとそのセキュリティに直接影響を与えるため、セキュリティ上の懸念に効果的に対処するうえで重要な存在です。GitHubのような大規模なコードリポジトリホスティングサービスにおける重要なセキュリティインテグレーションなど、主要な開発者エコシステムでも、この変化が受け入れられつつあります。

DevOpsの世界で求められる俊敏性に対応するには、リスクの検出から修正までを自動化できるツールが必要です。これにより、エンジニアはセキュリティ上の懸念に先回りして対処し、リスクを迅速に低減できます。また、開発者がリスクを評価し、優先順位を付けやすいよう、適切なコンテキストを提供することも効果的なツールの条件です。いつの時点でも、潜在的なリスクの量は膨大であり、開発チームとセキュリティチームの双方に対応上のノイズをもたらします。アプリケーションやサービスのリスクを効率的に低減するには、どこに最大のリスクがあるかを把握することが不可欠です。

これにより、エンジニアがセキュリティ上の懸念に対処できるだけでなく、脆弱性が露出した状態にある時間も短縮されます。その結果、組織とその資産に対する全体的なリスクが低減します。

79%の組織がDevOpsの道のりの中盤にいる

Puppetの「State of DevOps」レポートでは、さまざまな組織におけるDevOps導入の状況と成熟度、そしてそれがセキュリティ導入に与える影響が明らかにされています。

レポートで示された調査結果の一つは、79%の組織がDevOpsの進化において中程度の段階に位置していることです。また、DevOpsの価値と期待される効果を十分に実現するために、ツール、文化、プラクティスを拡大するうえでも課題に直面しています。

DevOps導入の中間段階にある組織に対し、Puppetはビジネス成果の測定に注力し、DevOpsに基づく指標を活用することを推奨しています。このアプローチは現状を反映し、DevOpsの導入をさらに成熟させるために次に何をすべきかを把握するのに役立ちます。

2018年と2019年のDevOps回答者を比較した棒グラフ:大きな進化は11%対14%、中程度は両年とも79%、小さな進化は10%対7%。

DevSecOps Insights 2020の調査結果をさらに読む:

DevSecOps Insights 2020のPDFをダウンロード

続きを読む

blog feature ai lilac
Blog

エージェント型修正で脆弱性バックログをプルリクエストに変える

Evo Remediation Agentがオープンプレビューで利用可能になり、Evo Agentic AppSecに依存関係の自動解決機能が加わりました。AppSecチームは継続的な修正キャンペーンを実施できるようになりました

AI Background min crop
Blog

AIが、あなたが受け入れてきたあらゆるリスクを一気に顕在化させる:AI Security Panel: Unfilteredから得た7つの洞察

AIによって攻撃はより安価かつ高速になり、組織がすでに抱えているリスクが露呈しています。4人のセキュリティリーダーが、機械の速度に対応する防御と迅速な修復が今不可欠である理由を語ります。

blog feature ai violet
Blog

VulnBump:AIエージェントはビルドを壊さずに脆弱な依存関係を修正できるか?

VulnBumpでは、実際の依存関係のアップグレード307件をAIエージェントで検証します。脆弱性が解消され、ビルドとテストが正常に通った場合にのみ、修正成功と判定します。