私たちはオープンソース・ソフトウェア・セキュリティ・モビリゼーション・プランに向けて十分に成熟していますか？

現在の経済情勢と脅威環境では、平均的なCISOは決してうらやましくありません。安全、コンプライアンス、イノベーション、ビジネス価値の提供を任されている一方で、予算の縮小と監視の強化という困難な戦いに直面しています。おそらくもっと差し迫っているのは、すべての組織 (およびそれぞれの開発チーム) がセキュリティの成熟度においてさまざまな段階にあり、すべての組織がサイバー防御の観点から最善を尽くす準備ができているわけではないという事実です。

ここ数年、サイバーセキュリティインシデントの激化により、セキュリティリーダーが一歩先を行くことは非常に困難になっています。増大する苦境に対するデータ主導型の洞察をちらっと見ただけで、粉末の樽のようなものが明らかになります。それ以上に 2023年だけで330億件の記録がサイバー犯罪者に盗まれる、2018年から175％増加しています。は サイバー犯罪のコストは、2025年までに10.5兆ドルに達すると予測されていますそして、データ漏えいの平均コストは急上昇しました 424万米ドル （ただし、EquifaxやSolar Windsのようなインシデントを見るだけで、それが可能であることがわかります。 はるかに悪い)。

業界として、私たちはヒーローがやって来て、10年前でさえ、私たちが考えていた以上の力を握っているように見えるサイバーセキュリティの悪党から私たちを救ってくれるのを長い間待っていました。私たちは、より多くのサイバーセキュリティ専門家が参加して、より高い水準のセキュリティプログラムへと私たちを導いてくれるのを待っていますが、このギャップを埋めることはできません。私たちは、増大するリスクから私たちを自動化することを約束する特効薬ツールソリューションを待っていますが、それはなく、存在する可能性もほとんどありません。ダークサイドとの戦いに協力してくれるルーク・スカイウォーカーを待っています。

結局のところ、助け（そして希望）は、次のような形で進んでいます。 オープンソース・ソフトウェア・セキュリティ・モビリゼーション・プラン。しかし、私たち全員が、特に開発チームのサポートや実行を必要とする場合には、最新かつ最高の防御戦略を実装するために、組織内で十分に成熟しているかどうか、そして開発チームが適切なレベルのセキュリティ意識とスキルを持っているかどうかを正直に評価する必要があります。

オープンソース・ソフトウェア・セキュリティ・モビリゼーション・プランとは

この10項目の計画は、オープンソースソフトウェア財団（OpenSSF）とLinux財団が、ホワイトハウスの役人、最高CISO、および37の民間テクノロジー企業のその他の上級指導者と協力して主導しました。この活動と資金提供の両面で支援が組み合わさったことで、オープンソース・ソフトウェアのセキュリティ基準はより強固なものとなるでしょう。

特に興味深いのは、開発者レベルでの基本的な教育と認定に重点を置いていることと、社内のソフトウェア部品表（SBOM）活動を合理化するための対策です。これらはいずれも、組織のセキュリティ・プログラムにおける課題の増大と、開発コホートの間での全般的なセキュリティ成熟度の欠如が、長期的な影響をもたらす方法で実施するのが難しいことで有名です。その理由の1つは、組織のセキュリティ・プログラムにおける課題の増大と、開発コホートのセキュリティ成熟度が全般的に欠如していることです。彼らは、ますます不合理な期限が迫っている中で、大量のコードを高速に処理することが最優先されるプレッシャークッカー環境にあります。セキュリティタスクや SBOM メンテナンスという形で、利用できる時間を増やすことなくさらに多くのタスクを追加することは、開始する前から失敗に終わっていました。悲しいことに、予想以上によくあることです。

それでは、ボンネットの下を見てみましょう。

開発者向けセキュリティ認定:まだ取得できていますか?

私たちが確実に知っていることが1つあるとすれば、それはそれです。 セキュリティスキルのある開発者 まだ珍しい商品です。これが現実となっているのには、いくつかの理由があります。最近まで、組織内のソフトウェアセキュリティ戦略に関しては、開発者が考慮されていなかったからです。それに加えて、開発者がセキュリティを優先する理由があまりない（彼らのトレーニングが不十分または存在せず、時間がかかり、KPIの一部ではなく、彼らの主な関心事は、機能の構築という最も得意なことをすることです）、開発チームがコードレベルでセキュリティに対処する準備が整っておらず、最新のDevSecOps中心のソフトウェア開発ライフサイクル（SDLC）で役割を果たす準備が不十分な開発チームもあります。。

オープンソース・ソフトウェア・セキュリティ・モビリゼーション・プランを見てみると、この10項目計画の最初の流れは、開発チームのセキュリティ成熟度を高めるために不可欠な「ベースラインの安全なソフトウェア開発教育と認定をすべての人に提供する」という、開発者のセキュリティスキルに取り組むことです。彼らは、セキュア・コーディングが高等教育レベルのほとんどのソフトウェア・エンジニアリング・コースでMIAであるという事実を含め、私たちが以前から議論してきた問題を浮き彫りにしています。業界の現状を変えることができる個人や部署がこれを支えているのを見るのは、信じられないほど励みになります。 世界のソフトウェアの 99% に少なくとも以下が含まれている 一部 オープンソースコード、この開発分野は、セキュリティの開発者トレーニングに集中し始めるのに最適な場所です。

この計画では、次のような尊敬される資源を挙げています OpenSSF セキュアソフトウェアの基礎 コース、および長年にわたる豊富なリソース オワスプ財団。これらの情報ハブは非常に貴重です。これらの教材を開発者のスキルアップのために公開するために提案されている展開案では、教育機関と提携してオープンソースの安全な開発をカリキュラムの重要な特徴とすることを目指すことに加えて、公共部門と民間部門の両方の幅広いパートナーネットワークを結集することが含まれます。

その多くが自分の仕事でも優先事項でもないものとしてセキュリティ強化を受けてきた世界中のソフトウェアエンジニアの心をつかむ方法については、この計画では、オープンソースライブラリを管理する開発者と、セキュリティ認証の価値を理解する必要のある現役エンジニアの両方を対象とした、報酬と表彰の戦略を詳述しています。

経験から、開発者はインセンティブによく反応し、進捗状況やスキルを示す段階的なバッジシステムは、SteamやXboxのような学習環境でも同様に機能することがわかっています。

ただし、懸念されるのは、中核的な問題の1つに取り組んでいないということです。それは、組織のセキュリティプログラム内での学習モジュールの提供です。私のキャリアの大半にわたって開発者と緊密に仕事をしてきたので、彼らがツールやトレーニングにどれほど懐疑的であるかはわかっています。最優先事項である仕事を混乱させる可能性があることは言うまでもありません。デベロッパーが活躍するには、継続的にコース教材に取り組む必要があり、これを成功させるためには、日々の業務の文脈において意味が通じていなければなりません。

次のような確立された成熟度モデルを考えてみると ソフトウェアアシュアランス成熟度モデル （SAMM）によると、「教育とガイダンス」はガバナンスレイヤーの中核的な要素であり、開発者教育に重点が置かれています。このモデル全体は広大であり、より高いレベルの成熟度に達するには段階的な段階があります。ただし、初期段階では、開発者向けの正式なトレーニングを 1 ～ 2 日間だけ行うことを推奨していますが、これだけではセキュリティ意識の表面を触るには十分ではありません。その場合でも、 最近の報告 エンタープライズストラテジーグループ（ESG）によると、開発者に年に2回以上正式なセキュリティトレーニングを受けることを義務付けている組織は半数未満でした。私たちの 独自の研究 Evans Dataと併せて、コードを書くのが能動的に行われていることを信じている開発者はわずか 29% であることがわかりました。 脆弱性 優先すべきです。特に開発者が価値を見出していない場合、教育の提供方法や受け方と、セキュリティを成熟させる上で教育が実際にどれほど役立つかとの間には明らかな隔たりがあります。

ソフトウェア部品表:この計画は採用の障壁を打ち破るか?

この計画が対処しようとしているもう1つの分野は、ソフトウェア部品表（SBOM）の作成と保守に関連してしばしば発生する災害です。「SBOM Everywhere — SBOMのツールとトレーニングを改善して採用を促進する」という流れの中で、開発者とその組織がSBOMを簡単に作成、更新、使用してセキュリティを向上させる方法を模索しています。

現状では、SBOMはほとんどの業種で広く採用されていないため、セキュリティリスクの軽減におけるSBOMの可能性を実感することは困難です。この計画には、SBOM フォーミュレーションの主要標準を定義する素晴らしい戦略と、開発者の働き方に合った作成を容易にするツールが盛り込まれています。これらだけでも、需要のスピードに合わせてソフトウェアを作成するためにすでに多くの作業をこなしている開発者にとって、さらに別のSDLCタスクの負担を軽減するのに大いに役立ちます。

しかし、私が恐れているのは、平均的な組織では、セキュリティ責任は開発者にとって本当に灰色の領域である可能性があるということです。セキュリティの責任者は誰か?究極的にはセキュリティチームですが、開発者に助けてもらいたいのであれば、開発者を参加させる必要があります。タスクと期待事項を明確に定義する必要があります。また、開発者が成功に向けてこうした追加の対策を講じるには時間が必要です。

OSS から他のソフトウェア世界へ

オープンソース・ソフトウェア・セキュリティ・モビリゼーション・プランは野心的で大胆であり、まさに開発者のセキュリティに対する責任を高めるために必要なものです。有力なプレーヤーが集まった「反政府勢力同盟」が必要でしたが、これは私たちが正しい方向に向かっていることを証明するものであり、サイバーセキュリティのスキルギャップは魔法のように自然に解消されるという考えを置き去りにしています。

これが私たちの新しい希望であり、この構造をOSSを超えて推し進めるには私たち全員が必要です。しかし、セキュリティ専門家は自分の内側を見て、保護すべきコードに取り組んでいる開発チームを分析する必要があります。現在の能力を正直に評価し、ギャップがある部分を正直に評価し、開発チームに真のセキュリティスキルを身に付けるプログラムの完全かつ積極的で包括的な成熟した後期段階の構築に取り組む必要があります。これらが有意義に有効になるまでは、コードレベルの脆弱性に対する私たちのアプローチはまだ少し未熟かもしれません。

‍

>> ハンズオン形式のインタラクティブ機能でチームのセキュリティ成熟度をテスト XSS チャレンジ!