エンジニアリングの生産性に最適化されたアプリケーション・セキュリティ

原文リンク(2024-04-17)

アジャイル・アプリケーション・セキュリティの著者であり、SafeStackの創設者でもあるLaura Bell Main氏は最近、「Decoding Dev Culture 2024」と題したウェビナーを開催し、2024年のセキュリティについて「現場からの視点」を提供した。Bell氏は、自身の経験と SafeStack の 12 か月にわたる調査から、DevSecOps 実践者が SAST やその他のツールへの過度の集中から脱却する必要性について論じた。彼女は、セキュリティプロセスとツールに関連する開発者の経験をよりよく理解することを提唱した。Bell氏は、効果的なセキュリティ・オーナーシップはコミュニケーションの改善を通じて促進され、エンジニアの生産性にプラスの影響を与えることができると説明した。

Bell氏は、開発、セキュリティ、運用を「目的意識を共有」した「フルスタック対応」のチームに統合することを目指すDevSecOpsを称賛する一方で、懸念すべき傾向も強調した。彼女は、DevSecOps能力のサイロ化へのシフトを指摘した。Bell氏によると、実際にはDevSecOpsはデリバリーチームから切り離され、専任チームやSREチームに分離されていることが多いという。このような分離は、文化的・運用的な課題から生じているとBell氏は説明する。たとえば、セキュリティの取り組みが、CI/CDのパイプラインを実行する開発チームではなく、CI/CDのツールと緊密に結合しているような場合だ。

『Effective Vulnerability Management』の著者であるNikki Robinson氏は、昨年11月、DevOps Summit Canadaで「Where Platform Engineering and Security Meet（プラットフォームエンジニアリングとセキュリティの出会いの場）」と題した講演した。Robinson氏は、「プラットフォーム・セキュリティ・エンジニアリング」という規律について、エンジニアリング・チームを顧客として扱うことで、複雑なシステムのセキュリティ確保において開発者を支援する実践について議論した。彼女は、ツールだけでなく、プロセスやコラボレーションモデルも含めて、開発者の経験に的を絞ったアプローチをとることの重要性について次のように語った。

チームがお互いにアイデアを出し合い、何が本当に起こっているのかについて話し合わなければ、プラットフォーム・エンジニアリングが成功するのは本当に難しいです。このアイデアは、セキュリティをチームメンバーとして、あるいはプラットフォーム・エンジニアリング・チームの一機能として統合することで、開発者にとって本当に素晴らしいエクスペリエンスを構築できます。

同様に、Bell氏は、「開発、セキュリティ、運用を一体化する」というDevSecOpsの目標に反して、セキュリティが「運用に採用される」という歴史的なパターンが繰り返されていると説明した。このような状況をもたらす緊張関係について、彼女は詳しく説明した。

私たちには、このサイクルを繰り返す原因となっている文化的・運用的な課題があります。まず、セキュリティへの取り組みなどは、CI/CD パイプラインと非常に密接に結びついています。つまり、パイプラインを管理する人たち、パイプラインを設定する人たち、しかし、必ずしもパイプラインを実行するわけではない人たちが、セキュリティ・ツールを触っている唯一の人たちであることが多いのです。このような場合、セキュリティ対策がアクティブな開発チームから切り離されることになります。

Bell氏によると、開発チームはDevSecOpsだけに集中するのではなく、自分たちのエンジニアリングの生産性を優先している。セキュリティの優先順位を確実に維持するために、Bell氏は、今後のセキュリティ対策を早期に可視化することで開発者の認知的負荷を軽減し、労力を軽減するためのツールを改善し、誤報を抑制し、承認のボトルネックなど自律性を制約する要因を最小限に抑えるといった戦略を提案した。SafeStack が現在実施しているアプリケーションセキュリティに関する調査によると、ほとんどの企業では、50 ～ 100 人の開発者に 1 人のアプリケーションセキュリティ担当者が割り当てられており、このようなボトルネックのリスクが浮き彫りになっている。

開発者とセキュリティ専門家の比率に関するSafeStackの調査。(出典：SafeStack : Decoding Dev Culture 2024 - A Security Leadership Perspective)

さらにBell氏は、セキュリティスペシャリストが、エンジニアリングチームに新たな摩擦をもたらす可能性があることに留意することの重要性を強調した。彼女は、既存の課題を悪化させるのではなく、改善策の採用を促進し、開発プロセスを加速させるアプローチを提唱した。彼女は次のように語った。

我々の開発者たちは苦しんでおり、我々はこれまで以上に彼らをサポートする必要があります。彼らにはやるべきことがたくさんあります。人手も予算もこれまでより少ないです。解決策は、ツールを買い足すことではなく、すでに開発者にお願いしていること、それが引き起こしている摩擦、開発者の世界への影響に目を向けることです。開発者の労力を減らし、生産性を向上させる改善ができれば、多くの友人を作り、ツールだけではできないような文化的変化をもたらすことができるでしょう。

Robinson氏はまた、プラットフォーム・セキュリティ・エンジニアリング・チームに対し、チームメンバーとの関係構築とコミュニケーションに投資するよう促した。彼女は、個人やチームの状況をサポートするツールやプロセスをよりよく最適化するために、セキュリティ実務の摩擦や課題を理解することの重要性を強調した。彼女はこう語った。

人の側面、関係構築の側面、無意識のバイアスの側面は、特定の方法で技術的なインフラを構築するのと同じくらい重要だと思います。つまり、開発者がどのように環境を使っているかを理解することです。セキュリティは彼らとどのように統合するのがベストなのか？どのようなタイムラインが開発者にとって効果的なのか？

開発者の労力を軽減することを優先し、継続的に改善する文化を醸成することで、組織は有意義な変化を推進し、ソフトウェア・インフラストラクチャの全体的なセキュリティを確保できる。Bell氏は、最近QCon Londonで「Securing Modern Software」トラックを主催し、何千もの組織のセキュリティ・ジャーニーを指導している。同氏は、セキュリティ・リーダーに対して、新しいシステムの管理だけでなく、レガシー・アプリケーションのセキュリティ確保においても開発チームを支援するよう促して、ウェビナーを締めくくった。彼女は次のように語った。

レガシーシステムと基盤システムがインターネットを動かしています。新しいものだけではないです。開発チームはこのことを知っていて、古いシステムのことを心配していますが、新しいものに取り組む時間とリソースしか与えられていません。セキュリティ・リーダーとしての私たちの仕事は、ソフトウェア開発チームに、新しいものだけでなく、私たちが構築し保守しているすべてのソフトウェアの面倒を見るための時間とサポートを与えるようにすることです。