企業によるDevSecOpsの導入にこれほど時間がかかっている理由とは?

How does your business approach application development? If you’re like many companies, DevOps is your watchword, and with good reason. Historically, a strong DevOps program allowed for agile operations, shortened the development lifecycle, and gave customers consistent access to the immediate solutions they demand. DevOps has been a powerful solution for tech companies of all sizes – but the problem is that it’s not enough.

Over the last several years, industry experts have encouraged businesses to shift left, taking a DevSecOps approach to application development. Security, these experts argue, needs to be part of the initial development process if applications are actually going to be secure. Why, then, are so many companies hesitant to deploy a DevSecOps approach? It’s a complicated problem, but one that, with proper examination, can be solved to everyone’s advantage.

ホワイトペーパーをダウンロード DevSecOps クラウドセキュリティガイド

議論#1:スローダウン

When the concept of DevSecOps was first introduced, one of the first arguments that companies offered against it was that, instead of encouraging agility, foregrounding security would slow application development down. This can happen, but only if companies don’t sufficiently automate the security code review process. As long as that happens, though, DevSecOps doesn’t actually make application development and deployment slower. It can even be faster than the older DevOps model.

 

DevSecOps はアプリケーション開発プロセスをどのようにスピードアップしますか? アプリケーションを構築して最後までセキュリティ要素を統合する場合は、これらの重要なコンポーネントを既存のインフラストラクチャに適合させる方法を見つける必要があります。 タワーを建てて、完成後に中央に桁を差し込もうとするようなものです。 それは可能かもしれませんが、すでに行ったことをすべて中断する必要があります。 一方、シフトレフトを選択し、セキュリティを組み込むことを選択した場合は、より強力なシステムと、きちんと組み合わされたピースができあがります。

Argument #2: More Breaches

It may sound ridiculous, but if you talk to some DevOps-focused businesses, you’ll occasionally hear people say that a DevSecOps approach leads to more security breaches, not fewer. Like other assertions about DevSecOps, though, this one is also rooted in serious misunderstandings of the practice. While top DevSecOps users report more breaches than their DevOps counterparts, experts agree that this is only because they’re aware of those breaches, not because they actually experience more of them. DevOps-based companies simply can’t detect security breaches.

 

Obviously, it’s better for businesses to be aware of potential or actual security risks because that enables them to actually address and remedy their weaknesses, but many businesses are hesitant to admit that they’re at risk. It’s important for companies to acknowledge that DevSecOps enables risk detection, and that acknowledging breaches is less likely to damage a company than being oblivious to digital attacks.

Argument #3: Expensive Implementation

ビジネス慣行の変更にはコストがかかる可能性があります。 古いプログラムから移行する場合でも、コーディング言語を変更する場合でも、大きな変更を行うとビジネスが停滞し、契約や利益を失う可能性があります。 これは、DevSecOps への移行に関しても当てはまりますか? 短期的には、新しいシステムの学習においてチーム メンバーをサポートすることで問題が抑制される可能性がありますが、長期的にはDevSecOps によって ROI を最大化できます

 

DevSecOps アプローチにより、どのようにして会社の収益性が向上するのでしょうか? 確かに、重大なセキュリティ問題を未然に防ぎ、攻撃を受けたときに迅速に行動できることは経済的に有益ですが、それだけが理由ではありません。 DevSecOps は実際には、DevOps アプローチよりも迅速に起動および更新できる、より機敏なシステムを作成するという上記の議論を思い出してください。 また、専門家によるサポートは、企業がセキュリティインフラストラクチャを自動化し、時間と高度な技術プロセスを簡素化するのにも役立ちます。

引数 #4: プロセス サイロ

DevOps highlights two main elements of the application creation process – the development side and the operations, or customer-facing, side – but despite the shorthand conjunction of the two, it doesn’t really connect them. A DevOps approach still allows professionals to work within their familiar siloes. Developers build apps that enable smoother operations, and operations teams may provide guidance and feedback, but they don’t really have to work together. That all changes when companies shift-left to DevSecOps, and that’s a key reason why businesses have been reticent to make the change.

 

一般に、セキュリティ機能はコーディング プロセスの後半でアプリケーションに追加されるため、アプリケーション開発者とセキュリティ専門家は別々にプロジェクトに取り組んできました。 しかし、基本的な開発機能とセキュリティ機能を同時に構築する場合、以前はサイロ化されていたこれらのチームが集まる必要があります。 これを成功させるには、リーダーは チーム間のコミュニケーションを促進し 、クロストレーニングを奨励する必要があります。 セキュリティの専門家はプロのコーダーではないかもしれませんが、開発者にガイダンスを提供することはできます。 逆に、開発者はセキュリティが機能上の優先事項であることを認識する必要があります。

 

情報をサイロに隔離する現在の傾向が多くのクラウド セキュリティ侵害の原因となっているため、開発者とセキュリティ専門家間のコミュニケーションを増やすことが特に重要です。 実際、最近の調査では、侵害の 60% が、不適切なデプロイメントが原因でパブリック クラウド (アプリケーションのユーザー側) で発生していることが示唆されています。 開発者はクラウド デプロイメントに関して適切な構成決定を下せません (少なくともサポートなしでは)。そのため、企業は攻撃にさらされます。 DevSecOps の観点に移行すると、そのギャップは埋められますが、すでにベスト プラクティスを使用していると考えている開発者の防御力が高まる可能性もあります。

DevSecOps への取り組み

These four arguments are just some of the reasons that businesses have been slow to shift-left and adopt a DevSecOps approach, but they’re hardly the only ones. Like so many other changes, companies are resistant to change, even when it’s in their best interest. The problem is that sometimes you have to let go of the old ways in order to be successful.

 

If your business is stuck in the old DevOps mentality, it’s time to move forward – and Check Point can help. Contact us today for a free security assessment and to learn more about how DevSecOps can benefit your company. Making a big change isn’t easy, but with the right support, you’ll see big improvements.

×
  フィードバック
このWebサイトは、機能性と分析およびマーケティングの目的でCookieを使用しています。Webサイトを引き続きご利用いただくことで、Cookieの使用に同意したことになります。詳細については、Cookieに関する通知をお読みください。
OK