道のりは長いものの、ソフトウェアセキュリティの責任共有への扉を開くために必要な相乗効果を阻む障害は、ますます明らかになりつつあります。賢明な企業は、こうした落とし穴を回避し、生産的な前進の道筋を見つけ、DevSecOpsの持つ人的資源を最大限に活用するために、戦略を進化させたいと考えています。
予想外だったのは、セキュアコーディングとは何かという認識が議論の的になっていることです。Evans Dataとの共同研究による最新の調査によると、この認識は白黒はっきりしています。「開発者主導のセキュリティの現状 2022」調査では、1,200人の現役開発者の重要な洞察と経験を掘り下げ、セキュリティ分野における彼らの姿勢と課題を明らかにしています。
注目すべき調査結果の一つは、コーディング時にセキュリティを優先事項と考えている開発者がわずか14%にとどまっているという点です。これは改善の余地が非常に大きいことを示していますが、同時に、私たちが既に認識していた事実を裏付けるものでもあります。開発者の世界では機能構築が最重要課題であり、セキュリティを自らのDNAに組み込むための準備がまだ整っていないのです。しかし、開発者がセキュアコーディングをどのように定義しているかというデータと合わせると、懸念すべき事態が浮かび上がります。
こうした認識は、開発者の日々の業務経験に起因しており、多くの組織の環境にも当てはまります。つまり、開発者は一般的な脆弱性対策の中心的存在ではないということです。開発者の能力開発は不可欠ですが、同時に、「セキュアコーディング」の範囲、そしてセキュリティスキルを持つ開発者に何を期待すべきかについて、早急に認識を一致させる必要があります。
開発者の世界では、セキュリティの神秘性を解明する必要があります。
サイバーセキュリティは、どんなにうまくいっても多面的で扱いにくいものです。セキュアコーディングは全体の一部に過ぎず、専門家の注意を必要とするシステム内の複雑な歯車です。
調査の結果、平均的な開発者にとってセキュアコードの使用という概念は非常にサイロ化されており、その範囲は多くの場合、基礎からその先までを包括的に捉えるのではなく、単一のカテゴリに限定されていることが明らかになりました。開発者は、脆弱性のない新しいコードを書くという実践よりも、既存の（または事前承認済みの）コードの使用に依存していることが示されています。サードパーティ製コンポーネントに関するセキュリティ意識（特にパッチ適用、そしてLog4Shellの失敗はその好例です。12月以降、インスタンスの30%がパッチ適用されていない状態です）は非常に重要ですが、既存コードのテストも重要です。しかし、それだけではセキュアコーディング能力の機能レベルを満たすことはできません。
コードレベルの脆弱性は、不適切なコーディング パターンを学習した開発者によってもたらされます。また、KPI で安全なコードを書くことに重点が置かれていないこと (セキュリティ文化の低迷と相まって) により、これが許容可能な標準として強化されるだけです。
セキュリティリーダーは、まず開発チームにセキュアコーディングの全体像を示すことで、初期の認識を向上させ、最も深刻な知識ギャップのある領域を特定することに大きく貢献できます。承認済みのコードのテストとスキャンは一つの役割ですが、脆弱性の削減には、現在広く使用されている言語やフレームワークにおいて、適切で安全なコーディングパターンに関する実践的なトレーニングが必要です。
開発者のスキルアップにはコンテキストが不可欠であり、ビジネスのセキュリティ目標に関しては開発者をそのプロセスに巻き込む必要があります。
多くの組織はセキュリティ プログラムをアップグレードする必要があります。
過去 10 年間でソフトウェア主導のテクノロジーが爆発的に増加し、サイバーセキュリティ インシデントが急増したため、私たちは皆、貴重なシステムの脆弱性を発見するために 24 時間体制で活動する脅威アクターに追いつくために奮闘しています。
DevSecOps手法は、開発者を含め全員がセキュリティの責任を共有するという考えに基づいており、SDLCの初期段階から重要な考慮事項となります。問題は、特に大企業では、DevSecOpsを標準として導入するまでにまだ長い道のりがあるということです。2017年にProject Management Instituteが実施した調査によると、組織の51%が依然としてソフトウェア開発にウォーターフォール方式を採用していました。この調査は5年前のものですが、大企業における変化の緩やかな流れを考えると、最新のセキュリティ重視の手法への急激な移行は考えにくいでしょう。こうしたレガシープロセスは、サイバー脅威から身を守るための包括的な戦略を策定し、あらゆる面をカバーしようとするセキュリティ専門家にとって困難な課題となる可能性があり、開発者とそのニーズをこの環境に適応させることは容易ではありません。
しかし、これを言い訳にすることはできません。業界のセキュリティ専門家は、開発者を高度な戦略に活用することができます。開発者のニーズを理解し、それを防御策の一部として考慮する必要があるだけです。開発者には包括的なトレーニングが必要であり、セキュリティに関する責任は、技術スタックとワークフローを考慮して実装される必要があります。
セキュアコーディング = 「難しすぎる」バスケット?
エバンス・データの調査によると、開発者の86%がセキュアコーディングの実践に困難を感じており、開発マネージャーの92%もチームにセキュリティフレームワークのトレーニングを強化する必要があると認めていることが明らかになりました。さらに懸念されるのは、回答者の48%が、コードに脆弱性を故意に残していると認めたことです。
これは非常に憂慮すべき事態を浮き彫りにしています。開発者は一般的に、十分なトレーニングを頻繁に受けておらず、適切なセキュリティ対策や衛生管理についても十分な知識を身につけていないようです。行間を読むと、問題の核心が浮き彫りになります。開発者にとって、仕事においてセキュリティを考慮することは優先事項ではないのです。さらに、彼らが受けているトレーニングは、自信や実践的なスキルを育むものではなく、脆弱なコードをリリースするという決断が及ぼす影響を理解する助けにもなりません。
コロニアル・パイプラインへのランサムウェア攻撃は、過去1年間で最も深刻なサプライチェーン・セキュリティ・インシデントの一つであり、米国東海岸のガス供給の半分が無期限に停止されるのではないかという懸念を引き起こしました。幸いなことにパイプラインはすぐに復旧しましたが、コミュニティに大きな不安が残されました。これは、サイバーインシデントが、必ずしもソフトウェア主導、あるいはサイバー攻撃のリスクとは考えられていない物理世界の要素に深刻な影響を及ぼす可能性に、一般の人々が直面した試練の瞬間の一つでした。そして、この混乱の全ては、2つの古くから修正されていない脆弱性によって引き起こされました。その一つは、陰険でありながら広く知られているSQLインジェクションでした。開発者が脆弱なコードを出荷することを選択する際に、何が本当に危険にさらされているかを理解していたら、それが許容できるビジネスリスクとなるシナリオは存在しないことにすぐに気付いたでしょう。
機能的な「PPT」は開発者次第ではありません。
人、プロセス、ツールの有名な「黄金の三角形」は、慎重に検討された戦略がなければ達成できません。また、開発者は、自分のニーズと課題を考慮せずに、機能するセキュリティ プロセスに同化できる立場にありません。
開発者主導のセキュリティを向上させるには、文化の大幅な変化が必要です。それは、エンジニアとセキュリティ チームの両方をより明確な方向に導く教育経路から始まります。
このコンテンツはSecure Code Warriorのチームによって提供されました。詳細はこちらをクリックしてください。
