開発者の現場と向き合う 

より速く、より安全なリリースのために DevSecOps を検討している企業は、統合されたテクノロジースタックで開発者の生産性を最適化することの重要性を知っています。Secure Code WarriorGitHubやJiraなど、開発者が日常的に使用するツールに統合されたセキュアな開発リソースで、開発者を支援することができます。 

Secure Code Warrior は、セキュアコードプログラムをお客様の製品や開発者のワークフローに直接組み込むことで、ジャストインタイムの修正と、より強固な学習成果を可能にします。

迅速な対処で脆弱性を低減

脆弱性を発見し修正することは、ピースの一部や役立つ表紙絵のない大きなパズルを解くようなもので、堅牢な解決策を講じるには、時には数日、数週間、あるいは数カ月かかることもあるのです。特に開発者にとっては、問題に遭遇したことがないため、あるいはテストも検証もされていないソリューションを導入することにためらいがあるため、問題を修正する方法がわからない場合があり、大変な作業となります。

EdgeScan 2022 Vulnerability Statistic Reportによると、フルスタックに渡って位置する脆弱性の平均修復時間（MTTR）は57.5日でした（EdgeScan2022 Vulnerability Statistics Report）。

これは、貴重なデータが漏洩し、信頼が失われ、貴重な開発者の生産性が浪費される可能性のある重要な窓であり、コードのリリース速度を低下させ、最終的には、展開されたソリューションに対する知識や信頼性の欠如から、迅速な修正やずさんなパッチワークによる技術負債をさらに積み重ねます。

Secure Code Warriorの統合は、信頼できる修正アドバイスを提供し、開発者がフローにとどまりながら自信を持ってセキュリティバグを解決できるようにします。開発者が根本的な解決を行えるようにすることで、AppSecは組織のリスク監視とセキュリティ態勢の強化に集中できるようになります。 

ワークアイテムに組み込まれた文脈的なセキュアコーディングガイダンスにより、開発者は検出された脆弱性とその修正方法について学ぶための支援を即座に受けることができ、MTTRを短縮するだけでなく、ソース-コードで脆弱性を積極的に削減する貴重で粘り強い学習成果を提供します。

チーム全体の学習のスケールアップ 

SCORM LMSインテグレーション

SCORMとは、Sharable Content Object Reference Modelのことで、e-courses の国際規格です。あなたのコースがSCORMフォーマットで公開されていれば、ほとんどすべての学習管理システム（LMS）がそれを認識することを保証することができます。SCORMを使えば、セキュアなコードトレーニングプログラムを、他のトレーニングプラットフォームと一緒に一箇所で簡単に管理することができます。

出荷前に熟練度を確認するコード 

Secure Code Warrior Connector for Okta Workflowsは、フローに組み込むことができるセキュリティ熟練度チェックの力で、安全でないコードがコードベースに導入されるのを防ぐことができます。GitHubリポジトリなどのコードベースで作業する場合、ベースでのコーディングのための資格として、必須のレッスンと評価を設定することができます。これにより、リーダーは、各開発者が関連するコードベースで作業する準備ができていることを確認でき、組織全体のセキュリティ態勢をレベルアップすることができます。 

個々の開発者が、コードをコミットするためのリポジトリへのアクセス権を付与されるために必要なセキュアコーディングスキルを獲得していることを確認し、ソフトウェア開発ライフサイクル全体にセキュリティを導入する。この統合により、開発者はSCWの非常に魅力的なプラットフォームを通じて最新のセキュリティプラクティスを学び、手動コードレビューの負担の一部を軽減し、エンジニアリング時間を解放して、品質を犠牲にすることなくより多くの機能を出荷できるようになります。

Okta + SCWについての詳細、およびデモはこちらからご覧ください。 

コードコミット時のジャストインタイム対応

SCW for GitHubは、GitHubワークフロー内のSARIFファイル、または作業中の課題およびプルリクエスト内で直接、コンテキストに基づくトレーニングを可能にします。これにより、開発者は高品質なコードをより早く出荷するために、最も必要な時に知識にアクセスすることができます。この統合は、理解されずに適用されることが多いパッチを有効にするだけではありません。脆弱性のあるコードを素早く認識できるよう、安全で優れたコーディングパターンを継続的に強化します。 

SCW+GitHubの詳細と デモを見る

GitLab 内に統合された実用的なセキュアコーディングガイダンスでは 、脆弱性レポートの脆弱性詳細セクションに関連性の高いSecure Code Warrior トレーニングリンクが埋め込まれます。これは最終的に、この統合を可能にすることで、学習と知識の適用との間の時間差を縮め、将来の利用を確実なものにするのに役立ちます。例えば、脆弱性スキャナーがアプリケーションコードにクロスサイトリクエストフォージェリ（CSRF）を検出した場合、脆弱性の詳細が関連するトレーニングリンクで更新されます。

"Secure Code Warrior'のセキュアコーディングに関する広範なコンテキスト学習を我々のプラットフォームで提供することで、開発者が最初からセキュリティファーストを受け入れることができ、時間を節約するだけでなく、新しいスキルを身につけることができるようになります。"- GitLabのVP、Nima Badiey（ニマ・バディ）氏

SCW + GitLabについてもっと知る

シノプシスのSeeker統合により、Secure Code Warrior リソース、ビデオ、脆弱性の発見に対するトレーニング・リンクがSeeker内に埋め込まれます。これにより、Seeker内で簡単にアクセスできるトレーニング・ガイダンスで脆弱性を特定し解決するマイクロラーニングで、業界標準や規制への準拠を保証します。 

シノプシス＋SCWについてもっと知る

今すぐ必要なときに、チケット内をサポート 

Secure Code Warrior for Jira は、セキュリティ上の欠陥を見つけるだけでなく、その修正も支援します。Secure Code Warrior for Jira は問題の詳細を検出し、開発者が慣れ親しんだ環境内で特定のトレーニングビデオにアクセスすることによって、これらの問題を修正する方法を学ぶ機会を提供します。文脈に沿ったマイクロラーニングを通じて、開発チームはコードベース全体の脆弱性を減らし、Jiraを通じた追跡と報告により、常に最新の情報を入手することができます。

SCW + Jiraについてもっと知る

セキュアなコードを高速に書く

Secure Code Warriorの技術スタック統合により、マイクロラーニングと、業界で信頼されているガイダンスや一般的な脆弱性の解決策を用いた迅速な修正が可能になります。 

• トレーニングのリンクは、課題およびプルリクエストのコメントとして添付され、必要なときにガイダンスに簡単にアクセスできるようになっています。

• コンテンツは、Common Weakness Enumeration（CWE）やOpen Web Application Security Project（OWASP）のリファレンスに基づいて取得され、高い関連性を持っています。 

• 豊富な学習リソースは、世界有数のセキュア・コーディング・トレーニングのコレクションから提供されることを意味します。 

一般的な脆弱性、その多くは何十年も前から知られていますが、SDLC 内で持続し続けるのは、消極的な対策によるものです。スキャンツールとペンテストは、問題を発見するだけで、多くの場合、アプリケーションがすでに運用に移った後です。それらは悪名高く時間がかかるものです。複数の偽陽性や手動レビューを必要とする陰性が表面化し、問題の原因やそのソースに対処することはほとんどありません。

Secure Code Warrior の統合により、開発者が作業している場所で、脆弱性の発見と修正を迅速に行えるようになるだけでなく、信頼できるリソースと一口サイズのガイダンスから実践的に学習し、スキルを高め、ソフトウェア開発ライフサイクルの重要なコンポーネントとしてのセキュリティを強化することが可能になります。 

もっと詳しく知りたい方はこちら 

• SCWのエキサイティングな統合について学ぶために、プロダクトトークWebセミナーをご覧ください。
• Oktaのデモを見る 
• GitHubのデモを見る
• Secure Code Warrior 無料でお試しください。 

企業が業界の枠組みや政府の規制の範囲内にあることを確認するための最初の認証プロセスであれ、毎年の要件やレビューの一部であれ、最近ではほとんどすべての開発チームが何らかの形でコンプライアンス・トレーニングを採用しています。なぜなら、組織が基本的なコンプライアンス要件を満たすことができなければ、従業員は現実的に職務を遂行することができないからです。

コンプライアンスに関する規則が存在するのには理由があります。これらの規則が適用される分野で働く人は、関連するすべてのプロセスと手順、および適用されるすべての法律について、少なくとも基本的な理解を持っている必要があるからです。

コンプライアンスのトレーニングは重要ですが、義務付けられた最低限の要件を満たすだけでは、真のアプリケーションセキュリティを確保することはできません。これは、特に、セキュアなコーディングスキルを日々のワークフローに組み込もうとする開発者に当てはまります。ほぼすべての開発者が何らかの形でコンプライアンス・トレーニングを受けているにもかかわらず、67%の開発者が自分のコードに脆弱性を残すことが多いと認めています。

なぜ？

2年目となるSecure Code Warrior は、2021年12月にEvans Data Corpと共同で「開発者主導型セキュリティの現状調査、2022」を実施しました。グローバルで1,200人の開発者を対象に、セキュアコーディングの実践に関するスキル、認識、行動、およびソフトウェア開発ライフサイクル（SDLC）における影響と関連性の認識について調査しました。

コンプライアンス教育がなぜソフトウェアセキュリティの向上を達成できないかという点については、以前から言われている問題である。今回の調査は、この問題にスポットライトを当てたに過ぎない。

一方で、開発者は、アプリケーションやプログラムのコードを最初に書くときを含め、ソフトウェア開発プロセス全体にサイバーセキュリティを含めることで、新しい役割にステップアップすることを要求されています。しかし、安全なコードを書くこと、あるいはそれに影響を与える可能性のあるサイバーセキュリティの問題や脆弱性についてすべて学ぶことは、簡単なことではありません。この調査では、開発者の63％が安全なコードを書くことは難しいことだと回答しています。

安全なコードを書くことの難しさは、驚くべきことではありません。多くの高収入のサイバーセキュリティの仕事が実現されないのには理由があり、最後に数えたところでは、世界で350万人以上が募集されています。もしそれが簡単な仕事なら、誰もがその分野に飛び込んでいるはずです。脅威と戦い、コード内の脆弱性を排除する方法を学ぶことは困難であり、脅威の状況は常に変化しています。静的なコンプライアンス・トレーニングや1回限りの講習では、開発者が必要とする教育にはついていけませんし、提供することもできません。また、開発者が安全なコードを書くことや、コードの脆弱性を発見して修正するスキルを身につけることもできません。

コンプライアンスとセキュリティ教育は重要だが、異なるものである

組織は、コンプライアンス教育で何ができ、何ができないかを認識し、認識し始める必要があります。特に法律で義務付けられている場合は、コンプライアンス・トレーニングを放棄してはならない。また、特に（現在のトレーニング方法であっても）調査回答者の92%が、コンプライアンス関連の問題やセキュリティの枠組みについて少なくとも何らかのトレーニングが必要であると回答し、50%が重要なコンプライアンストレーニングの必要性を強調しているためです。

トレーニングに最も関心のあるコンプライアンス・フレームワークには、さまざまな業界に特化したものが含まれていますが、一般的なサイバーセキュリティ・フレームワークもいくつかリストアップされています。その中には、CIS Security Framework、PCI DSS、OWASP Top 10、MISRA C、ISO/IEC、HIPAA (Health Insurance Portability and Accountability Act) などのフレームワークが含まれています。

しかし、コンプライアンス研修でチェックボックスをチェックすることは、セキュアなコードを継続的に作成するための基盤を提供することと同じではないことを理解してください。

その代わり、コンプライアンス研修は、開発者のセキュアコーディングスキルを向上させる継続的な機会の一部として捉え、コンプライアンスサイクル以外でも繰り返し行うことで、開発者が日々安全なソフトウェアを作成し、リリースできるようにすることができます。優先順位をコンプライアンスの達成から、開発チームが継続的に学習してセキュアなコーディングを行えるようにすることにシフトする。開発者の能力開発に時間とリソースを投資することで、毎年行われるコンプライアンスに関するチェックボックス式の練習や試験を簡単にクリアできるようになり、全体的な生産性の向上にもつながります。

開発者主導のセキュリティに移行するにはどうすればよいのでしょうか。

開発者は、トレーニングは重要であると圧倒的に答えましたが、セキュアコーディングに関して長年受けてきたトレーニングのタイプに問題があるとしました。開発者は、自分の仕事に関連する実例を使った実践的なトレーニングにもっと重点を置いてほしいと述べています（30%）。また、回答者の26%は、よりインタラクティブなトレーニングが重要だと考えており、特に、トレーニングの一環としてセキュアコードを実際に書く練習ができることが重要だと回答しています。

調査対象の開発者の23%は、自分の業界や分野で遭遇する可能性の高い特定の脆弱性に焦点を当てたガイド付きトレーニングを受けることを望んでおり、22%は、トレーニングにおいて実際の脆弱性の例をもっと見ることを望んでいます。courses 。

静的で非インタラクティブなトレーニングを提供するだけでは（一般にコンプライアンス・トレーニングで経験すること）、開発者のセキュリティスキルを繰り返し向上させるという点ではほとんど価値がないことは明らかである。その代わりに、組織は、開発者が仕事をしながらセキュリティについて学ぶ、ジャストインタイム・トレーニングのようなものに焦点を当てるべきである。また、段階的な学習プログラムの導入も検討すべきです。

段階的アプローチでは、大きなトピックは通常、個別の学習体験やコンセプトに分割されます。開発者が進歩するにつれて、より高度なコンセプトがすでに習得したコンセプトの上に重ねられます。これは、ビルが高くなるにつれて物理的な足場が組まれるのと同じです。これは、サイバーセキュリティのような難解で常に進化するトピックを教えるための実証済みの方法であり、最初に小さく複雑でない塊に分解し、その基礎の上にさらに複雑なものを構築します。

開発者向けセキュリティ・スキル・プログラムのアプローチをどのように決定するにしても、コンプライアンス教育とは切り離して考えることが重要です。コンプライアンスとセキュリティトレーニングはどちらも重要であり、成功するためにはそれぞれ異なるアプローチが必要です。

参考資料

ホワイトペーパーソフトウェア・セキュリティ向上のための課題（および機会）。

ホワイトペーパーソフトウェア・セキュリティに対する予防的な開発者のアプローチ。

報告します。開発者主導のセキュリティのあり方。

この記事のバージョンは、Infoseurity Magazineに掲載されました。 Infosecurity Magazineに掲載されました。.この記事は更新され、ここにシンジケートされています。

‍

数年前、私たちは、サイバーセキュリティがいかに「ワイルド・ウエスト」であるか、そして、多くのサイバー攻撃がもたらす生命に対する非常に現実的なリスクは言うまでもなく、一般的に多くの人々が関心を持つことが切実に必要であることをよく話しました。 

2023年になると、特に多くの影響力のある国の政府レベルでは、ある程度の進展が見られるようになり、喜ばしいことです。しかし、私たちにとって、真に安全なコードとより安全なソフトウェアを目指す旅は、終わりのないものです。デジタル時代の寵児、メタバースの出現は、コードレベルの脆弱性とソーシャルエンジニアリングの両方にとって、膨大な新しい攻撃対象領域を追加することになります。

そして、私たちは、煙と鏡に支配されたこの新しい土俵での戦いに備えることができないのです。

複合現実感には、リスクの激化が伴う

今月は「Flavor of the Month（今月のフレーバー）」であるにもかかわらず、メタバースのコンセプトは長い間存在してきた。オンライン・プラットフォームのSecond Lifeは 2003 年から存在し、完全にカスタマイズ可能なオンライン宇宙で、ユーザーのアバターが音声やテキストチャットで対話し、ゲームをプレイし、Adidas などの企業が公式バーチャルストアを提供するなど、ニッチな分野でサービスを提供しています。純粋なゲームとしては、Fortnite や World of Warcraft のような多人数参加型オンライン（MMO）ゲームが広大な世界をプレイヤーに提供し、マイクロトランザクション、つまり仮想アイテムに実際のお金を支払うことにますます依存している。フォートナイト」だけでも、発売後2年間で43億ドルのマイクロトランザクションの売上がありました。 

メタバースのコンセプトは今後も続くというだけでなく、マーク・ザッカーバーグ級の勢いでメインストリームに押し上げられようとしていることは明らかです。これは、私たちが知っているインターネット、少なくともソーシャルメディアと一部のeコマースの刺激的な進化ですが、サイバー攻撃や有害な悪用が行われる機会は、気が遠くなるようなものです。 

メタバースの攻撃対象は、ウェブベースのソフトウェア、API、決済ゲートウェイにとどまらず、広範囲に及びます。VRヘッドセットやアクセサリの周辺機器も、コア・データへの脅威となります。これらの機器に搭載されたソフトウェアが脆弱であれば、土に還るための非常に便利なレッドカーペットになります。 

ラトガース大学のセキュリティ研究者が今年初めに発表した「Face-Mic」は、バーチャルリアリティヘッドセットの音声コマンド機能が、「盗聴攻撃」として知られる深刻なプライバシー侵害につながる可能性を検証した初めての研究成果です。この研究は魅力的で、脅威者がモーションセンサーを内蔵した一部のバーチャルリアリティ（AR/VR）ヘッドセットを使って、音声に関連した顔のジェスチャーを記録し、クレジットカード情報やパスワードなど、音声で操作することで通信される機密情報を盗み出す可能性があることを示しています。この問題の根本的な原因は、ユーザー認証の不備にあるようです。加速度センサーとジャイロスコープがアクセス許可を必要としないため、複雑な顔の動き、骨に伝わる振動、空気に伝わる振動を記録し、ユーザーのパターンによって、銀行の暗証番号から高度に制限された医療記録までを推測するために使用される可能性があります。 

メタバースでは、あなたのすべての動きがデータポイントであり、もしソフトウェアのセキュリティが甘くてもアクセスが可能であれば、攻撃者が運試しをするインセンティブは非常に大きくなるのです。 

スマートコントラクトは、スマートな敵に直面している

メタ経済では、分散化、非物質化、柔軟性、そしてもちろん妥協のないセキュリティが要求されます。今現在、柴犬のように様々な暗号通貨コミュニティでメタバースマイクロエコノミーが成長しています。仮想不動産やその他の無形商品を購入するために、ブロックチェーン上に保存されたスマートコントラクトが活用されています。

「ブロックチェーン」と言えば、（少し技術に詳しい）ほとんどの一般人は、未来のデジタル通貨と考えられている安全で匿名性の高いシステムとして理解しています。しかし、これにはちょっとした問題がある。オンライン上の要塞に侵入不可能なものはなく、スマートコントラクトも例外ではないのだ。スマートコントラクトも例外ではなく、本質的には小さなプログラムであり、ハッキングされる可能性がある。

スマートコントラクトには、整数のオーバーフローやアンダーフロー、リプレイ攻撃、リエントランシー攻撃につながるブロックチェーン中心のバグ（非常に有害）、後者は、ユーザーが保存した暗号の残高を引き出されることにつながるなど、かなり共通の脆弱性があるため悪用される可能性があるのだ。これらの攻撃はすべて、悪用可能な脆弱性につながる不適切なコーディングパターンと、安全でない設計の基本によって可能になります。

この技術はより広く使われるようになるでしょう。しかし、現状では、安全でフェイルセーフなメタバースを確保するために十分なセキュリティ意識のある開発者を見つけるのに苦労することになりそうです。特にデータや通貨が危機に瀕している場合、組織はメタバースへの参加の重大さを理解しなければなりません...そして、これが事実でないシナリオを想像することは困難です。

規制のない環境であり、あなたは（まだ）製品である

映画やテレビ、セカンドライフ、ビデオゲームで見てきたように、メタバース環境では、私たちが望む人物になることができます。仮想世界では、可能性はあなたの想像力によってのみ制限され、その柔軟性はユーザーにとって大きな魅力となります。しかし、Metaのような計画的な規模では、あまりにも広大で分散化されているため、セキュリティの観点から完璧に管理することはできません。詐欺は避けられないでしょうし、熟練した犯罪者はソーシャルエンジニアリングの観点からさらに仕事をすることができるようになるでしょう。 

機密性の高いユーザーデータは新しい金であり、メタバースは、採用が計画通りに進めば、これまで見た中で最も豊富で完全なデータソースとなる可能性を秘めています。メタバースに関連するソフトウェアの構築は、現行の規制基準やコンプライアンス対策を遵守することが前提ですが、急速に拡大するデジタル宇宙とその経済をサポートするのに適したアップデートが必要になるでしょう。その核となるのは、メタバースへの貢献のセキュリティに責任を持つ組織であり、ソフトウェアに携わるすべての人がプロセスのあらゆる段階でセキュリティを考え、実装することを保証する社内のセキュリティ成熟度、特に開発者集団の成熟度です。 

メタバースの成功にセキュアコーディングが欠かせない理由

現実の世界でこうありたいという願望をすべて詰め込んだアバターで表現された無法地帯のデジタル次元を飛び回るのは楽しいかもしれませんが、すべての「キャラクター」の背後に人間がいることを決して忘れてはいけません。そして、現実の人々のデータや金銭が危険にさらされているとしたら、それはゲームとはとてもかけ離れたものです。 

サイバーセキュリティの分野では、ミスが本当に破壊的な結果をもたらすことをよく理解しており、普及と消費者の信頼を実現するためには、メタバースのあらゆるコンポーネントの完全性を後回しにするわけにはいきません。 

組織は、自社のセキュリティ成熟度の現実的な評価（assessment ）を行い、ソフトウェアに積極的に取り組む開発者のセキュリティ・スキルを向上させることに重点を置いて、今すぐ計画を立て始めることができます。ラトガース大学の調査から分かるように、アクセス制御は広範なデータ漏洩につながる可能性のある脆弱性の一つに過ぎず、セキュリティ意識の高い開発者であれば、コードが書かれる段階で、そしてコミットされたコードに入る前に、これらの問題をうまく切り抜けることができるはずです。 

サイバーセキュリティのスキル不足という言い訳は、メタバースの大規模なデータ流出の後では通用しません。私たちの目の前には、できる限りのことをするだけでなく、ソフトウェアセキュリティの基準を積極的に向上させるためのツールが揃っています。今こそ、メタバースの設計者を育成するために投資し、私たちが知っているような製品やサービスを仮想的に再構築することで利益を得る時なのです。

この記事の一版は ダークリーディング.この記事はDark Readingに掲載されたものを更新し、ここにシンジケートされています。

‍

組織の中で誰が誰の部下かを示す業務報告図や階層図を、誰もが一度は目にしたことがあるのではないでしょうか。組織図と呼ばれることもありますが、誰が自分のために働き、誰が自分の上司であるかを知らせるのに便利なツールです。例えば、典型的な組織図では、コーディンググループの責任者は製品開発担当ディレクターに、そのディレクターはイノベーション担当バイスプレジデントにレポートします。そして、その権限線は、会社組織の上下に続いていきます。このような組織図を見て、どこかに自分だけの小さなブロックを見つけようとしたことがない人はいないでしょう。

人間が階層や構造に魅了されるのは不思議なことではありません。歴史的に見ても、非常に危険な世界に直面していた太古の時代から、私たちは長い間、種として生き続けてきたのです。私たちは決して最強でも最速でもありませんでしたが、家族、部族、グループをまとめ、生き、繁栄させるために、全員が自分の立場と責任を理解し、チームとしてうまく機能していました。現代の組織図は、そのような時代と古代の成功の延長線上にあるものなのです。

しかし、事業の規模などに関係なく、ほとんどすべての組織図に共通していることがあります。それは、組織図の構成要素がすべて人間、あるいは人間の集団であるということです。機械が人間を監督する時代ではないので、今のところ組織図は人間だけのものなのです。しかし、私たちのソフトウェアにも組織階層が必要なのでしょうか？

もちろん、会社の組織図にソフトを追加しろと言っているわけではありません。誰も上司にアプリを持たせようとは思いません。上司に昇給を求めるなんて、もってのほかでしょう？しかし、最近のアプリケーションやプログラムが直面している脅威の状況は、はるか昔、私たち人類の祖先が直面した危険な環境と同じではありません。アプリやソフトウェアの責任を厳格な階層構造の中で定義し、最小限の特権でポリシーを実施することで、アプリやソフトウェアが壊滅的に荒れた脅威の状況に直面しても、生き残り、繁栄することができるのです。

アプリやソフトウェアへの攻撃が過去最高を記録

ソフトウェアのためのより良い組織階層を作る必要性を理解するためには、まず脅威の状況を理解することが重要です。最近の攻撃者、そして攻撃者のために働くボットや自動化されたソフトウェアは、悪用するために防御の遅れを常にスキャンしています。人間に対するフィッシングなどの攻撃は依然として行われていますが、最も熟練したハッカーは、その取り組みの大半をソフトウェアへの攻撃にシフトしています。

そして、すべてのソフトウェアが狙われている一方で、最も成功している攻撃は、アプリケーション・プログラミング・インターフェース、またはAPIに対して行われています。APIとは、開発者がアプリやプログラムのために、小さくても重要なタスクを実行するために使用するソフトウェアの小さな断片のことです。APIは柔軟でユニークなものが多く、時には開発プロセスで必要に応じてその場で作成されることもあります。

APIは確かに柔軟ですが、その機能に対して過剰な権限を与えられていることも少なくありません。開発者は、例えば、APIが管理するプログラムが発展し変化し続けても機能し続けることができるように、APIに多くの権限を与える傾向があります。しかし、このことは、攻撃者がこの権限を侵害した場合、例えば、特定のデータベースの1つの塊にアクセスする権限だけでなく、もっと多くの権限を得ることになることを意味します。ネットワーク全体の管理者権限に近いものまで取得する可能性があるのです。

複数のセキュリティ調査会社が、今日のクレデンシャルを盗む攻撃の圧倒的多数はAPIのようなソフトウェアに対して行われていると述べているのも不思議ではありません。アカマイはその数を全体の75%としており、ガートナーもAPIに関わる脆弱性が最も頻繁に発生する攻撃ベクトルになっていると述べています。また、Salt Labsの最新のレポートでは、APIに対する攻撃は昨年と比較して約700%増加しています。

ソフトウェアの組織図を作成する

認証情報を盗む脅威に対して組織が対抗する方法の1つは、ネットワーク内で最小権限、あるいはゼロトラストを実施することです。これは、ユーザーが自分の仕事やタスクを達成するために必要な、ぎりぎりの権限を受け取ることを制限するものです。このアクセスは、時間や場所などの要素によってさらに制限されることが多い。これにより、たとえクレデンシャル・ステーリング攻撃が成功したとしても、攻撃者は短時間に限られた機能を実行する権限しか持たないため、あまり良いことはありません。

最小特権は良い防御策ですが、通常、人間のユーザーにのみ適用されます。しかし、APIにも高い特権があることを忘れがちであり、また、それほど規制されていないことが多い。サイバー攻撃のパターンを追跡しているOpen Web Application Security Project（OWASP）によると、アクセス制御の不備が公共の敵ナンバーワンになった理由の1つはこれです。 

この重大な問題を解決するには、単純にソフトウェアに最小権限を適用すればいいと言うのは簡単です。しかし、それを実行するのはもっと大変です。まず、開発者にその危険性を認識させる必要があります。そして、APIやその他のソフトウェアは、それが存在するコンピュータネットワーク内の組織図の一部として公式に配置されるか、少なくとも想定されるべきです。例えば、APIが予約アプリケーションの一部としてリアルタイムのフライトデータを取得することを想定しているのであれば、給与計算や財務システムとも接続できるようにしなければならない理由はないでしょう。ソフトウェアの組織図では、これらのシステムを直接結ぶ線はもちろん、点線で結ぶ線さえもない。

開発者が、組織内で運用されている何千、何百万ものAPIを示す組織図を実際に作成することは、おそらく非現実的なことでしょう。しかし、APIがもたらす危険性を認識し、APIのアクセス権を業務に必要なものだけに制限することは、昨今、誰もが直面しているクレデンシャルを盗む攻撃の横行を阻止する上で大きな意味を持ちます。それは意識することから始まり、APIやソフトウェアを人間のユーザーと同じように慎重に扱うことで終わります。
‍。

開発チームのレベルアップを図りたいですか？APIセキュリティの問題などをナビゲートする私たちの アジャイルlearning platform開発者ファーストのセキュリティツールで、APIセキュリティの問題などを解決しましょう。

デジタルビジネスを推進するソフトウェア、アプリケーション、プログラムを作成する開発者は、多くの企業にとって生命線となっています。現代のほとんどのビジネスは、競争力のあるアプリケーションやプログラムがなければ、あるいはウェブサイトやその他のインフラに24時間アクセスできなければ、（利益を生み出す）機能を発揮することはできないでしょう。

しかし、これらのタッチポイントは、ハッカーやその他の悪意のあるユーザーが情報を盗み、攻撃を仕掛け、詐欺やランサムウェアなどの犯罪行為を行うための入り口となることが多いのです。Verizon Data Breach Investigations Report の最新版では、企業や組織に対する脅威は、歴史上かつてないほど危険で高コストになっていることが強調されています。

ほとんどの組織でサイバーセキュリティに対する支出が大幅に増加しているにもかかわらず、また、DevSecOpsのような動きが今日のビジネスの生命線である開発者にセキュリティをシフトしているにもかかわらず、成功した攻撃は依然として広まっています。

開発者はセキュリティの重要性を理解し、安全で高品質なコードをデプロイすることを圧倒的に望んでいますが、ソフトウェアの脆弱性が悪用され続けています。

なぜ？

2年目となるSecure Code Warrior は、2021年12月にEvans Data Corpと共同でThe state of developer-driven security survey, 2022を実施しました。全世界の開発者1,200人を対象に、セキュアコーディングの実践に関するスキル、認識、行動、およびソフトウェア開発ライフサイクル（SDLC）における影響と関連性の認識について調査しました。

この調査では、何が安全なコードを構成するのかについて、明確な定義や理解がないことが確認されました。開発者が考えるセキュアなコードと、実際のセキュアなコードの間には大きな食い違いがあることが判明しました。

しかし、特にセキュアコードについて質問したところ、脆弱性のないコードを書くという積極的な実践が優先されると答えたのは、わずか29%でした。その代わりに、開発者は、安全なコードを作成するために、より安全で、はるかに信頼性の低い実践を連想しました。例えば、既存のコードを精査すること（37%）、安全なコードのために外部ソースのライブラリに依存すること（37%）が、開発者が安全なコーディングと関連付けるプラクティスの上位に挙げられています。また、すでに安全だと判断されたコードを再利用する（32%）もよく選ばれています。脆弱性のないコードを書くという積極的な実践は6位で、29%が安全なコードを作成するためのトッププラクティスであると回答しています。さらに質問すると、安全なコードを作成するための最大の障壁として、時間不足と経営陣のまとまったアプローチの欠如が挙げられた。

既存のコードへの依存は、悪用可能な脆弱性を持つソフトウェアが出荷されるリスクを高める要因の1つです。何が安全なコードを構成するのか、この断絶に対処することが、開発者が安全で質の高いコードを作成するために必要です。

開発者が考える安全なコードと、実際の安全なコードの間には大きな食い違いがあることが判明しました。

この状況を打開するために、組織は何をすればいいのでしょうか？

この調査から得られた最も重要なメッセージの1つは、開発者コミュニティは全体として、自分たちの仕事に関心を持つプロフェッショナルな人々で満たされているということです。最高品質のコードを書くことは、グループとして圧倒的に重要です。問題は、多くの場合、彼らが働く組織が、安全なコードを作成するために必要なベストプラクティスを特定しておらず、開発者がこれらの目標を達成するためのトレーニングや能力向上に十分なリソースを投入していないことです。

実際、ほとんどの開発者は、何が安全なコードであるかの明確な定義すら持っていないと回答しています。最も心配な例としては、調査回答者の28%が、アプリケーションやプログラムが本番環境に配備されたり、一般に公開された後、違反が報告されなければ、自分の組織はコードを安全だと考えていると回答していることが挙げられます。

言うまでもないことですが、今日の複雑な脅威の状況において、実際に努力することなく良い結果を望むだけでは、予想通りの結果、つまりさらなるセキュリティ侵害が発生する可能性が高いのです。

ありがたいことに、このような状況では、少なくとも問題の解決に着手することは比較的容易であり、その後、安全なコードの目標に向かって作業を開始することができます。最初の、そして間違いなく最も重要なステップは、組織が何を安全なコードと見なすかを定義することです。そして、その定義から外れたものはすべて、安全でないと判断する必要があります。

セキュアコーディングは、SDLC の開始時から、熟練した開発者が脆弱性のないコードを書く実践と定義されるべきです。この実践が定義されてはじめて、開発者コミュニティはその目標に向かって努力することができます。

安全なコードという目標を現実のものにするために

セキュアコードの定義が確立されたら、組織はその取り組みと、セキュアコードの完全な実践という目標を遂行する開発者を支援する準備を整える必要があります。このサポートは非常に重要です。このサポートがなければ、組織内のセキュアコードの定義は、重要ではあっても、紙虎に過ぎないでしょう。セキュアコーディングの実践を成功させるには、経営陣の支持を受け、適切な検討、権限、予算が与えられなければなりません。

このため、従来はコーディングのスピードが評価されてきた開発者にとっても、新たなベンチマーク目標が必要になるかもしれません。実際、調査に参加した開発者の37%は、既知の脆弱性を修正したり、最初から適切にコーディングするために必要な時間を、厳しい納期で確保できないため、コード内に放置していると報告しています。当初は、開発者が適切にコーディングする時間を確保するために納期を増やすことを意味するかもしれませんが、コーディングプロセスの最初の段階でかかる時間は、プログラムの修正、パッチ、導入後の作業が少なくなるので、おそらく後で埋め合わせることになるでしょう。しかし、コーディングの初期にかかる時間は、プログラムの修正、パッチ、デプロイ後の作業などの必要性が減るため、後で取り戻せる可能性が高くなります。

また、開発者は、特に遭遇する可能性の高い特定の脆弱性に関連した適切な実践的トレーニングや、コードの脆弱性を特定し修正する方法の習得を支援する必要があるでしょう。このことは、「コードから脆弱性を取り除きたいが、そのためのスキルや知識がない」と回答した調査回答者が36%に上ることを考えると、特に顕著です。

この調査では、37%の開発者が、既知の脆弱性を放置していると回答しています。これは、厳しい納期によって、脆弱性を修正したり、最初から適切にコーディングしたりする時間が取れないためです。

このトピックの詳細については、こちらをご覧ください。

ホワイトペーパー ソフトウェアセキュリティを向上させるための課題（および機会）。
報告書です。 開発者主導型セキュリティの現状調査、2022年。

最近、セキュリティ研究者のチームが、Pythonのtarファイル抽出機能における15年前のバグを発見したと発表しました。この脆弱性は2007年に初めて公開され、CVE-2007-4559として追跡されました。Pythonの公式ドキュメントに注意書きが追加されましたが、バグそのものは未パッチのままでした。

この脆弱性は、何千ものソフトウェアプロジェクトに影響を与える可能性がありますが、多くの人がこの状況や対処法についてよく知らないままです。そのため、このたび Secure Code Warriorこの脆弱性がどのような影響を及ぼすかを実際に体験し、この根強いバグのメカニズムを理解することで、あなたのアプリケーションをより良く保護することができます。

今すぐシミュレーションミッションを体験してください。

脆弱性：tarファイル抽出時のパストラバーサル

パスまたはディレクトリのトラバーサルは、未分析のユーザー入力がファイルパスの構築に使用された場合に発生し、攻撃者がファイルへのアクセスや上書き、さらには任意のコードを実行することを可能にします。 

この脆弱性は、Pythonのtarfileモジュールに存在します。tar（テープアーカイブ）ファイルは、アーカイブと呼ばれる1つのファイルです。これは、複数のファイルをそのメタデータとともにパッケージ化したもので、通常、.tar.gzまたは.tgzという拡張子を持っていることで認識されます。アーカイブ内の各メンバーはTarInfoオブジェクトで表すことができ、ファイル名、変更時間、所有者などのメタデータを含んでいます。

リスクは、アーカイブが再び取り出される可能性があることに起因する。

展開する際、各メンバーには書き込むためのパスが必要です。この場所は、ベースパスとファイル名を結合することで作成される。 

このパスが作成されると、そのパスは tarfile.extractまたは tarfile.extractall関数に渡され，抽出が行われます。 

ここで問題となるのは、ファイル名のサニタイズが行われていないことです。攻撃者は、ドット・スラッシュ（../）のようなパス・トラバーサル文字を含むようにファイル名を変更し、ファイルが意図したディレクトリの外にトラバースして、任意のファイルを上書きすることができます。これは最終的にリモートでのコード実行につながり、悪用される可能性があります。 

この脆弱性は、特定する方法を知っていれば、他のシナリオでも出現します。Python の tar ファイルの取り扱いに加えて、zip ファイルの抽出にも脆弱性が存在します。これは、Python 以外の言語でも顕在化しているzip slip 脆弱性のような別の名前で知られているかもしれません!

ミッションへのリンク 

リスクを軽減する方法は？

この脆弱性は何年も前から知られていたにもかかわらず、Pythonのメンテナは、抽出機能が想定通りに動作していると考えています。この場合、"バグではなく、機能だ "と言う人もいるかもしれません。残念ながら、開発者は未知のソースからtarやzipファイルを展開することを常に避けることはできません。安全な開発手法の一部として、パストラバーサル脆弱性を防ぐために信頼できない入力をサニタイズすることは、開発者次第です。

Pythonで安全なコードを書き、リスクを軽減する方法についてもっと知りたいですか？

Pythonの課題を無料でお試しいただけます。

コーディングガイドラインを無料で入手したい場合は、Secure Code Coachをチェックして、セキュアコーディングの実践に役立ててください。

‍

‍

Secure Code Warrior は、セキュリティや開発者コミュニティに対して、安全なコードの書き方や、安全でないコードによってもたらされる脆弱性のリスクの軽減に関する教育を支援することに深くコミットしています。この目標の一環として、私たちは、Uberの最近のセキュリティインシデントという 発展途上のストーリーを、開発者主導のセキュリティと左遷の重要性を議論する機会として活用する予定です。

Uberのセキュリティ事故について

Uberは、9月16日にサイバーセキュリティ事件に関する声明を発表し、現在も更新を続けています。読者は、これが現在進行中の話であることを心に留めておく必要があります。これまでのUberの発表や、セキュリティコミュニティでの評判の良い投稿を通じて分かったことをまとめてみよう。 

このハッカーは、Uberの従業員のWhat'sAppの番号を見つけ、ソーシャルエンジニアリングを行うことから始めました。攻撃者は従業員に連絡を取り、無防備な従業員に偽のUberサイトにログインさせ、ユーザー名とパスワードを取得することで認証情報のフィッシングを開始しました。 

Uberのアカウントは多要素認証（MFA）で保護されています。つまり、ユーザーはパスワードを提出する以外に、本人であることを確認するための第2の証拠を提示する必要があります。ほとんどの場合、これはモバイルデバイスに送信されるプロンプトです。 

認証情報を入手した後、攻撃者はUberの純正サイトへのログインを継続的に試み、従業員のデバイスに多数のプッシュ通知を流して圧倒し、MFA疲労攻撃を開始しました。再び、攻撃者はWhatsApp経由で被害者に連絡しました。今回はITサポートのふりをし、承諾するよう説得することに成功したとされています。

ハードコードされたクレデンシャル

Uberのセキュリティ侵害の根底には、フィッシング攻撃の成功がありました。侵入者は、PowerShellスクリプトを含むネットワーク共有を発見しました。これらのスクリプトの1つには、管理者ユーザーのハードコードされた認証情報が含まれており、AWS、G-Suite、コードリポジトリなど、Uberの内部サービスの侵害につながったのです。また、ハッカーはUberのHackerOneアカウントにアクセスすることができました。ただし、Uberによると、"攻撃者がアクセスできたバグレポートはすべて改善された "という。

この脆弱性がコードでどのように見えるか興味がありますか？PowerShellのチャレンジを無料でお試しください。

このような攻撃はどの程度あるのでしょうか？

ソーシャルエンジニアリングは、サイバーセキュリティの最も弱い部分と考えられてきたため、攻撃のベクトルとして防御することが困難です。Uberのハッキング事件は、MFAの実装が簡単に回避されることを明確に示しています。これを防ぐには、フィッシング攻撃の仕組みについて従業員の意識を高めることが重要です。 

しかし、Uberの内部サービスが暴露された原因は、PowerShellスクリプトに含まれていた管理者のユーザー名とパスワードです。認証情報をハードコードすることは、開発者やコードにアクセスできる人なら基本的に誰でも読めるようになるため、決して良いことではありません。 

しかし、繰り返しになりますが、意識が重要なのですセキュリティ中心の考え方を持つ開発者は、脆弱性を発見する可能性が高く、脆弱性を書く可能性も低くなります。

ソーシャルエンジニアリングに関する一般的な教育と、より具体的にはプロアクティブなセキュアコーディングのトレーニングという2つのアプローチにより、コードベースの脆弱性の数を減らし、セキュリティ脅威との戦いにおいて重要であることが証明されます。

セキュアコーディングのベストプラクティスの最新情報についてもっと知りたいですか？セキュア・コード・コーチをご覧ください。ここでは、セキュアコーディングのガイドラインを学んだり、トレーニングの練習を無料で試したりすることができます。  

世界は急速に変化しており、企業や製品に関係なく、物事はますますデジタル化し、ソフトウェアに依存するようになっています。開発者はかつてないほど速くコードを出荷していますが、コードの75%はまだ、一般的で簡単に防止できる脆弱性についてAppSecチームがチェックし、フラグを立てています。 

ソフトウェア開発プロセスの重要な部分であるセキュアコードとセキュリティを優先しないことには、莫大なリスクがあります。実際、データ侵害の世界平均コストは、この1年で435万ドルに増加しています（IBM Cost of a Data Breach Report 2022）。 開発者には、新たな脅威に対応するための魅力的で革新的なトレーニングと、セキュリティチームと連携してセキュリティ主導の考え方を残すための文化改革が必要です。

Secure Code Warrior では、開発者と組織が今日の変化し続けるセキュリティの課題に取り組むための適切なスキルを身につけることができるよう、常に革新を続けています。私たちは、非常に魅力的で、柔軟性があり、管理しやすいトレーニングプログラムを通じて、これを実現します。 

この四半期は、Coding Labs（新たにPreviewで利用可能になりました）で新しい学習方法を構築し、LMS SCORM統合を可能にし、よりアクセスしやすく包括的なユーザー体験を創造することに集中しました。 

もっと詳しく知りたい方は、こちらからどうぞ

コーディング・ラボを発表 - 次世代の学習法

最近の業界調査（The State of Developer-Driven Security Report 2022）では、開発者の40%がトレーニングが十分に実践的でないと回答しています。Coding Labsは、開発者が実際のコーディングと直感的なフィードバックによるハンズオントレーニングを通じてセキュアコーディングスキルを向上できるよう支援し、すべては親しみやすく強力なインブラウザIDEの中で、これまで以上に簡単に学習から実行に移すことができます。

開発者は、不明瞭でフラストレーションのたまる「正しいか正しくないか」のガイダンスではなく、正しい方法で学習していることに自信を持ち、リアルタイムかつインコンテクストなフィードバックによって理解力を向上させることができます。Coding Labsは、セキュリティの脆弱性を防ぎ、組織のセキュリティ体制を向上させるという開発者の目標をサポートします。

SCWプラットフォームの一部として、この新しい体験は、開発者の能力開発に新しい視点をもたらします。リーダーは、開発者が成功するためのトレーニングプログラムを、開発者の現状に合わせて、親しみやすく、一口サイズの学習で構築することができます。コーディングラボのような、よりチャレンジングで実践的な体験に至るまで、親しみやすいガイド付きトレーニングで、新しい脆弱性を克服するよう人々を指導します。リーダーは、開発者がトレーニングをより魅力的で定着しやすいと感じ、最終的にコードベースに適用して脆弱性や手戻りを減らすことができると確信することができるのです。 

Coding Labsは現在プレビュー版としてご利用いただけます。

SCWのお客様ではありませんが、Coding Labsの最新情報をお知りになりたいですか？こちらのフォームにご記入ください。

SCWの製品イノベーションについて学び、Coding Labsのデモをご覧ください。ウェビナーへの登録はこちらから。

セキュアコードトレーニングをご希望のSCORM LMSに統合します。 

SCWの管理者は、セキュアコードトレーニングプログラムを、他のトレーニングプラットフォームと一緒に、手作業で開発することなく、より簡単に管理できるようになります。これにより、管理者は時間を節約し、トレーニングプログラムを改善するためのより効果的な方法に集中できるようになります。 

SCORMとは、Sharable Content Object Reference Model（共有コンテンツオブジェクトリファレンスモデル） という意味で、e-courses のための国際標準です。あなたのコースがSCORMフォーマットで公開されていれば、ほとんどすべての学習管理システム（LMS）がそれを認識できることは間違いありません。

新しいSCORM LMSとの連携で、できること。

• セキュアコードトレーニングを直接LMSに組み込んで、参加者と課題を一箇所で管理することができます。
• 組織の進捗と完了を追跡する

‍

SCWプログラムを開発者のワークフローに直接組み込んで、ユーザーエクスペリエンスを向上させましょう。SCORMパッケージは、Courses とAssessmentsのためにダウンロードすることができ、SAP SuccessFactors、Workday、Cornerstoneなどの人気のあるプラットフォームとシームレスにLMS統合を提供します。

LMS SCORM統合は、10月にプレビューとしてお客様に提供される予定です。詳細については、アカウントマネージャーにお問い合わせください。 

SCWプラットフォームの幅と奥行きの拡大 

Secure Code Warriorの新しいコンテンツへの継続的な拡張は、当社のモジュールが常に適切で、タイムリーで、今日のサイバーセキュリティの状況で知る必要のあることに合わせて調整されるのに役立ちます。業界をリードする55以上の言語の広さと深さにより、多数の言語とフレームワークの開発者を養成するプログラムを簡単に構築し、拡張することができます。 

新しくリリースされたトレーニングコンテンツでABAPアプリケーションを安全に

春のリリースに続き、ABAPでコーディングする開発者のための新しいトレーニング方法として、6つの新しいウォークスルーと14のmissions を発表します。

新しいチャレンジとコンテンツで、柔軟で多様な教育を受けることができる 

Secure Code Warrior SCW は、多様なスキルレベルに対応できるようなコンテンツを継続的にリリースし、トレーニングモジュールに関連性とやりがいを持たせるよう努めています。今期、SCWは、以下のような人気のあるコーディング言語へのコンテンツをより多くリリースしています。

• お客様からの要望が最も多かった33のエクストラRPGのチャレンジ
• RPGでtournaments を作成する機能  
• Python Djangoの10の追加課題

プラットフォームでプレイできるチャレンジプールに、すべての新コンテンツが登場しました。

管理者とユーザーエクスペリエンスの簡素化

拡張性があり、魅力的なセキュアコードトレーニングプログラムの構成は、プラットフォームの主要なユーザビリティの改善により、これまで以上に容易になりました。

公開されたコースを簡単に編集することができます 

既存のプログラムを編集する新しい方法で、常に変化する組織やトレーニングプログラムのニーズに対応します。コースのバージョニングにより、管理者は全く新しいコースを作成することなく、既存のcourses を編集することができます。これは、お客様から最も要望の多かった機能の1つです。

更新内容は以下の通りです。

• 公開されたコースに新しい言語を追加する
• コース内のモジュールおよびアクティビティコンテンツの追加/更新/削除 
• エンドオブコースの活動の追加・更新・削除 
• プラットフォームは、コースのメジャーバージョンを保存し、基本的なバージョニングを作成します。 

ホーム画面からCourses にアクセス

新しいホームページには「続ける」ボタンが追加され、アクティビティカードのリストが表示され、ユーザーが以前に開始したモジュールを素早く再開できるようになりました。また、ホーム画面に未完了のモジュールを表示するウィンドウが表示されるようになりました。

これにより、ユーザーは、コースを一時停止したり、assessment 、進捗状況を失うことなく、効率的に中断したところから再開することができます。

‍

どちらの機能も、プラットフォーム上で早期アクセスを有効にしているアカウントで利用できます。アクセスに関するご質問は、担当のアカウントマネージャーまでお問い合わせください。

インクルーシブ・アクセシブルデザイン 

ここSecure Code Warrior では、言語とデザインには橋を架け、理解を深める力があると信じており、安全なコーディングを支持するという使命のもと、多様なユーザーグループを結びつけています。私たちの目標は、包括的でアクセシブルな体験を創造し提供することであり、アクセシブルデザインについて継続的な進歩を遂げることに興奮しています。

繁体字中国語を公開しました 

プラットフォーム上の言語に繁体字中国語が加わったことで、セキュリティチャンピオンになるために必要なツールにアクセスできる開発者の真のグローバルコミュニティを構築し続けています。 

設定のドロップダウンメニューから言語にアクセスすることができます。繁体字中国語は、リソースセクションのビデオ字幕でもご覧いただけます。

2022年10月5日に開催されるProductTalkのウェビナーにご参加ください。 

もっと詳しく知りたいですか？2022年10月5日に開催されるProductTalk Webinarに参加して、製品チームのメンバーからエキサイティングなアップデートや新機能について話を聞き、開発者主導のセキュリティ状況の変化について学んでください。 

ウェビナーへの登録はこちら こちら.

Secure Code Warrior を試してみたいけど、まだアカウントを持っていない？今すぐサインアップして無料お試しアカウント 今すぐ登録してください。

今期の新機能は 以上です。 TwitterでSecure Code Warrior をフォローすると、最新のリリースや改善に関する最新情報を入手できます。

現在の経済情勢と脅威の状況において、私は平均的なCISOがうらやましいとは思わない。彼らは、安全性、コンプライアンス、イノベーション、そしてビジネス価値を提供することを使命としていますが、一方で、予算の縮小と監視の強化という困難な戦いに直面しています。さらに深刻なのは、すべての組織（とその開発チーム）がさまざまなセキュリティの成熟段階にあり、すべての組織がサイバー防衛の面で最善を尽くすための体制を整えているわけではない、という事実です。 

ここ数年、サイバーセキュリティの問題が深刻化し、セキュリティ担当者が一歩先を行くことは非常に困難になっています。2023年だけでも、サイバー犯罪者によって330億件以上の記録が盗まれると予想されており、これは2018年から175%も増加しています。サイバー犯罪のコストは2025年までに10.5兆ドルに達すると予測され、データ侵害の平均コストは424万ドルにまで急騰しています（ただし、エキファックスやソーラーウィンズなどの事件を見れば、もっとひどい状況になる可能性があることが分かります）。 

業界として、私たちは長い間、10年前ですら想像もつかなかったような力を持つサイバーセキュリティの悪者から私たちを救ってくれるヒーローが現れるのを待ち続けてきました。私たちは、より多くのサイバーセキュリティの専門家が参加して、私たちをより高い水準のセキュリティ・プログラムに引き上げてくれるのを待っているのですが、そのギャップは埋められないのです。私たちは、増大するリスクから自動で解放してくれる銀の弾丸のようなツールソリューションを待っていますが、それは存在しませんし、存在する可能性も極めて低いのです。私たちは、ダークサイドと戦うのを助けてくれるルーク・スカイウォーカーを待っているのです。

その結果、オープンソースソフトウェアセキュリティ動員計画という形で、支援（と希望）がもたらされることになったのです。しかし、私たちは皆、自分の組織が十分に成熟しているかどうか、そして、開発チームが適切なレベルのセキュリティ意識とスキルを持っているかどうかを正直に評価し、最新かつ最高の防御戦略を実装する必要があります。

オープンソースソフトウェアセキュリティ動員計画とは？

この 10 項目の計画は、The Open Source Software Foundation (OpenSSF) と Linux Foundation が主導し、ホワイトハウス当局者、トップ CISO、および 37 社の民間テクノロジー企業のシニア リーダーが参加しています。このように行動と資金の両面から支援を受けることで、オープンソースソフトウェアのセキュリティ基準はより強固なものになることが予想されます。 

特に興味深いのは、開発者レベルでの基本的な教育と認証に重点を置いていることと、社内のソフトウェア部品表（SBOM）活動を合理化するための対策に重点を置いていることである。これは、組織のセキュリティプログラムにおける成長痛と、開発者集団のセキュリティ成熟度の一般的な不足に起因するものであり、彼ら自身のせいではありません。彼らは、これまで以上に不合理な納期に直面し、スピード重視のコードボリュームが支配するプレッシャーのかかる環境に置かれています。セキュリティの要求やSBOMのメンテナンスに使える時間を増やさずに、さらにタスクを追加することは、始める前から失敗しているレシピです。

では、ボンネットの中を覗いてみましょう。

開発者のためのセキュリティ認証。まだか、まだか？

私たちが確実に知っていることが一つあるとすれば、それは、セキュリティに精通した開発者はまだ希少な存在であるということです。このような現実があるのは、いくつかの理由があります。つまり、最近まで、組織内のソフトウェア・セキュリティ戦略に関して、開発者は方程式の一部ではありませんでした。さらに、開発者がセキュリティを優先する理由があまりないこと（トレーニングが不十分または存在しない、時間がかかる、KPIに含まれていない、自分の得意なこと（機能構築）に最大の関心がある）も相まって、開発チームは、コードレベルで本当にセキュリティに対処する準備ができておらず、最新のDevSecOps中心のソフトウェア開発ライフサイクル（SDLC）でその役割を果たすこともできないのです。 

オープンソースソフトウェアセキュリティ動員計画」を見てみると、10項目の計画の最初の流れは、開発者のセキュリティスキルに対処し、開発チームのセキュリティ成熟度を高めるために不可欠な「基本的な安全ソフトウェア開発教育と認定をすべての人に提供する」ことである。この計画は、私たちが以前から議論してきた問題、例えば、ほとんどのソフトウェア工学（courses ）の高等教育レベルでは、セキュアコーディングはほとんど行われていないという事実を強調しています。また、世界のソフトウェアの99%は少なくともいくつかのオープンソースコードを含んでおり、この開発領域はセキュリティの開発者トレーニングに焦点を当て始めるには絶好の場所です。

この計画では、OpenSSF Secure Software Fundamentals courses や、OWASP Foundation の広範かつ長年のリソースなど、尊敬に値するリソースを引用しています。これらの情報ハブは非常に貴重です。開発者のスキルアップのためにこれらの資料を提供するために提案された展開では、オープンソースの安全な開発をカリキュラムの主要な特徴とするために教育機関と提携することに加えて、官民両セクターのパートナーの幅広いネットワークを結集させることが必要です。 

また、セキュリティは自分たちの仕事ではない、優先順位が低いと強化されてきた世界中のソフトウェア技術者の心をつかむ方法として、オープンソースライブラリを保守する開発者と、セキュリティ認証の価値を理解する必要がある現役の技術者の両方を対象とした報酬・評価戦略を詳述しています。 

開発者はインセンティブに敏感で、SteamやXboxのような学習環境と同様に、進歩やスキルを示す段階的なバッジシステムが有効であることを、私たちは経験から知っています。

しかし、懸念されるのは、核心的な問題の1つに対処できていないことです。それは、組織のセキュリティ・プログラムにおける学習モジュールの提供についてです。私は、キャリアの大半を開発者とともに歩んできたので、開発者がツールやトレーニングに対してどれほど懐疑的であるか、そしてもちろん、優先順位ナンバーワンの仕事を中断させそうなものに対しては、何も言わないことを知っています。開発者の能力開発には、コース教材に継続的に取り組むことが必要であり、これを成功させるには、彼らの日々の仕事の文脈の中で意味を成すものでなければならないのです。

ソフトウェア保証成熟度モデル（SAMM）のような確立された成熟度モデルを考えてみると、「教育とガイダンス」はガバナンス層の中核をなす要素であり、開発者の教育に重点が置かれている。このモデル全体は広大であり、より高い成熟度に到達するための段階が設けられています。しかし、初期段階では、開発者向けにわずか1〜2日の公式トレーニングを推奨しており、これではセキュリティ意識の表面を引っ掻くには到底足りません。それでも、Enterprise Strategy Group（ESG）が最近発表したレポートによると、開発者に年に1回以上の正式なセキュリティトレーニングを要求している組織は半数以下であることが明らかになりました。また、Evans Data社と共同で行った調査では、脆弱性のないコードを書くことを積極的に実践することを優先すべきと考えている開発者は、わずか29%であることが明らかになりました。特に、開発者がその価値を認識していない場合、教育の実施方法とその受け取り方の間には、セキュリティの成熟をもたらす上で本当に役に立つかどうかという明らかな断絶があります。

ソフトウェアの部品表。この計画は、採用の障壁を打破しているか？

SBOM Everywhere - Improve SBOM Tooling and Training to Drive Adoption」では、開発者とその組織がSBOMを簡単に作成、更新、使用し、より良いセキュリティ成果を上げる方法を検討します。

現状では、SBOMはほとんどのバーティカルで広く採用されていないため、セキュリティリスクを低減する上でその潜在能力を発揮することは困難です。この計画には、SBOM 策定のための主要な標準を定義し、開発者の作業方法に適合した作成を容易にするツールを提供するという、すばらしい戦略があります。これらだけでも、要求されるスピードでソフトウェアを作成するためにすでに多くのプレートを回転させている開発者にとって、さらに別のSDLCタスクの負担を減らすのに大いに役立つだろう。 

しかし、私が恐れているのは、一般的な組織では、セキュリティの責任は、開発者にとって本当にグレーゾーンになり得るということです。セキュリティの責任は誰が負うのでしょうか？最終的にはセキュリティチームですが、開発者の力を借りたいのであれば、開発者にも参加してもらう必要があります。タスクと期待は明確に定義される必要があり、彼らは、成功のためにこれらの余分な手段を取るための時間が必要です。 

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

オープンソースソフトウェアのセキュリティ動員計画は、野心的で大胆であり、セキュリティに対する開発者の責任を推進するためにまさに必要なものです。しかし、これは、私たちが正しい方向に向かっており、サイバーセキュリティのスキルギャップが魔法のように解決されるという考えを捨てていることを証明するものです。 

これは私たちの新しい希望であり、OSSを超えてこの構造を推し進めるには、私たち全員の力が必要です。しかし、セキュリティ専門家は、自分たちの内面を見つめ、自分たちが保護すべきコードに取り組んでいる開発チームを分析しなければなりません。彼らは、自分たちの現在の能力と、どこにギャップがあるのかを正直にassessment 。そして、気密性が高く、プロアクティブで、真のセキュリティスキルを開発者集団に与えるプログラムを含む、成熟した後期段階の状態を作り出すために努力しなければなりません。それらが有意義に有効になるまで、コードレベルの脆弱性へのアプローチは、まだ少し未熟かもしれません。

‍

>>XSSに挑戦して、チームのセキュリティ成熟度をテストしよう