開発者は「セキュアコーディング」をどのように定義していますか?

この記事のバージョンが掲載されました テックリパブリック。ここで更新され、シンジケートされました。

‍

セキュリティチームと開発者の目標が一致した環境を作るには、困難でありながら不可欠な戦いでした。まだ長い道のりがありますが、ソフトウェア・セキュリティに対する責任の共有への扉を開くために必要な相乗効果を妨げる障害は、次第に明らかになってきています。賢い企業は、こうした落とし穴を避け、生産的な方法を見つけ、DevSecOpsを最大限に活用するために戦略を進化させたいと考えています。

私が予想していなかったのは、セキュアコーディングの行為とは何かという認識が議論の余地があるということです。Evans Dataと共同で行ったまったく新しい調査によると、この感情は白黒で明らかになったのです。は 開発者主導型セキュリティの現状調査 2022 1,200人の現役開発者の重要な洞察と経験を掘り下げ、セキュリティ分野における彼らの態度と課題を明らかにしています。

見出しの調査結果の1つは コーディング時にセキュリティを優先事項と考えている開発者はわずか 14%。これは改善の余地が非常に大きいことを示していますが、すでにわかっていることを裏付けています。開発者の世界では機能構築が主流であり、セキュリティをDNAに組み込むための準備はまだ整っていません。しかし、開発者にとってセキュアコーディングが何を意味するのかという定義に関するデータと組み合わせると、懸念の原因となります。

こうした認識は、開発者の日常業務における経験に基づくものであり、一般的な脆弱性との闘いにおいて開発者が中心的な存在ではないという多くの組織の環境を物語っています。その実現は重要ですが、それまでの間、「セキュアコーディング」の範囲と、セキュリティスキルのある開発者に期待すべきことについて、すぐに同じ認識を持つ必要があります。

開発者の世界のセキュリティをわかりやすく説明する必要があります。

サイバーセキュリティは多面的で扱いにくい存在であり、安全なコーディングは全体像のほんの一部に過ぎませんが、専門家の注意を必要とするシステム内の複雑な歯車です。

調査の結果、安全なコードを扱うという概念は、平均的な開発者にとってはかなりサイロ化されており、その範囲は基本やそれ以降の全体像とは対照的に、1つのカテゴリに限定されることが多いことが明らかになりました。開発者は、脆弱性のない新しいコードを書く習慣よりも、既存の (または事前に承認された) コードを使用することに頼っていると回答しました。サードパーティーのコンポーネント (特にパッチ適用) とLog4Shellの大失敗に関するセキュリティ意識が良い例ですが、 12月以降、30% のインスタンスがパッチ未適用のまま）は非常に重要です。既存のコードのテストと同様に、これらだけでは機能レベルの安全なコーディング能力を満たすことはできません。

コードレベルの脆弱性は、貧弱なコーディングパターンを学んだ開発者によって導入されます。KPIで安全なコードを書くことに重点が置かれていない（セキュリティ文化が乏しいことと相まって）ことは、これを許容できる標準として裏付けるだけです。

セキュリティリーダーは、最初に開発コホートにセキュアコーディングの全体像を示してもらうことで、初期の認識を高め、最も差し迫った知識のギャップがある領域を特定するのに大いに役立ちます。事前に承認されたコードのテストとスキャンは1つの機能ですが、脆弱性を減らすには、積極的に使用されている言語とフレームワークによる、適切で安全なコーディングパターンに関する実践的なトレーニングが必要です。

開発者のスキルアップにはコンテキストが不可欠であり、ビジネスのセキュリティ目標に関しては開発者に理解してもらう必要があります。

多くの組織は、セキュリティプログラムをアップグレードする必要があります。

過去10年間、ソフトウェア主導のテクノロジーが爆発的に増加し、サイバーセキュリティインシデントの急増に道を譲る中、私たちは皆、貴重なシステムのエクスプロイトを発見するために24時間体制で取り組んでいる脅威アクターに遅れずについていこうと奮闘しています。

DevSecOpsの方法論は、開発者も含めて全員がセキュリティに対する責任を共有するという考えに基づいて構築されており、SDLCの当初から検討してきた主な考慮事項です。問題は、特に大企業ではそうなる可能性があるということです。 非常に DevSecOpsを標準として実装することにはほど遠いです。2017 年には、 プロジェクト・マネジメント・インスティテュートによる研究 51% の組織が未だにWaterfallをソフトウェア開発に使用していることがわかりました。この調査は 5 年前のものですが、大企業でいかに段階的な変化が起こり得るかを知っていれば、最新のセキュリティ指向の方法論への急激な移行はありそうもないでしょう。これらのレガシープロセスは、サイバー脅威から身を守るための包括的な戦略であらゆる基盤をカバーしようとするセキュリティ専門家にとって困難な戦いを招く可能性があり、開発者とそのニーズをこの状況に適応させることは困難です。

しかし、これを言い訳にすることはできません。ビジネスのセキュリティ担当者は、高揚した戦略で開発者を活用できます。必要なのは、開発者を自社のニーズに精通し、防御活動の一環として考えることだけです。彼らには包括的なトレーニングが必要であり、セキュリティに関するあらゆる責任は、技術スタックとワークフローを考慮して遂行する必要があります。

安全なコーディング =「難しすぎる」バスケット？

Evans Data の調査では、開発者の 86% がセキュアコーディングを実践するのが難しいと感じていることが明らかになりました。また、開発マネージャーの 92% が、チームがセキュリティフレームワークのトレーニングをさらに必要としていると回答しています。心配なことに、回答者の 48% が、自分のコードに故意に脆弱性を残していると認めています。

これは非常に心配な状況を描いています。一般的に、開発者は頻繁かつ適切なトレーニングを受けておらず、適切なセキュリティ慣行や衛生状態に十分触れていないようです。行間を読むと、問題の核心がより明確になります。開発者が仕事においてセキュリティを考慮することは優先事項ではないということです。それと、彼らが受けるトレーニングは自信や実践的なスキルを身につけることにはならず、脆弱なコードをリリースするという決定の影響を理解するのにも役立ちません。

コロニアルパイプラインのランサムウェア攻撃は、過去1年間で最も混乱を招いたサプライチェーンのセキュリティインシデントの1つであり、米国東海岸のガス供給の半分が不定期間遮断されるのではないかという懸念を引き起こしました。ありがたいことに、攻撃はすぐに復旧して稼働しましたが、コミュニティの大きな懸念がなかったわけではありません。これは、必ずしもソフトウェア主導型とは考えられていない現実世界の要素に深刻な影響を及ぼすサイバーインシデント、またはサイバー攻撃のリスクという可能性に一般市民が直面した決定的な瞬間の1つでした。そして、その混乱はすべて、パッチが適用されていない古い 2 つの脆弱性によって可能になりました。その 1 つは、陰湿でありながら広く知られている SQL インジェクションでした。開発者が脆弱なコードをリリースする際に何が本当に問題になっているのかを知っていれば、それが許容できるビジネスリスクとなるシナリオは存在しないことがすぐにわかるでしょう。

機能的な「P-P-T」は開発者次第ではありません。

人、プロセス、ツールという有名な「ゴールデントライアングル」は、慎重に検討された戦略なしには達成できません。また、開発者はニーズや課題を考慮せずに実用的なセキュリティプロセスに同化することはできません。

開発者が主導するセキュリティを強化するには、大きなカルチャーシフトが必要です。そのためには、まずエンジニアとセキュリティチームの両方がより明確になるような教育経路が必要です。