この記事のバージョンは、以下のサイトに掲載されています。 TechRepublic.この記事は更新され、ここにシンジケートされています。

‍

セキュリティチームと開発者の目標が一致するような環境を作ることは、困難でありながら不可欠な戦いでした。しかし、ソフトウェアセキュリティの責任分担の扉を開くために必要な相乗効果を阻む障害物は、明らかになりつつある。賢明な企業は、これらの落とし穴を避けるために戦略を進化させ、生産的な前進の道を見つけ、DevSecOpsを人の力で最大限に活用したいと考えています。

予想外だったのは、何がセキュアコーディングを構成する行為なのか、その認識が議論されていることです。Evans Dataと共同で行った新しい調査によると、このような感情が白黒はっきりしました。TheState of Developer-Driven Security 2022」調査は、1200人の現役開発者の主要な洞察と経験を掘り下げ、セキュリティ領域における彼らの態度と課題を明らかにするものである。

その結果、開発者のわずか14％がセキュリティを優先してコーディングしていることが判明しました。これは、改善の余地が非常に大きいことを示していますが、私たちがすでに知っていたことを裏付けるものです。つまり、開発者の世界では機能を構築することが王道であり、セキュリティをDNAの一部として組み込むにはまだ不十分なのです。しかし、開発者が自分にとって安全なコーディングとは何かを定義しているデータと合わせると、これは懸念材料となります。

このような認識は、開発者が日常的に経験していることであり、一般的な脆弱性との戦いにおいて開発者が中心的な役割を担っていないという多くの組織の環境を物語っているのです。開発者の能力向上は非常に重要ですが、その一方で、「セキュアコーディング」の範囲と、セキュリティに精通した開発者に期待すべきことについて、早く同じ見解を持つ必要があります。 

開発者の世界では、セキュリティを非神秘化する必要があるのです。

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

この調査では、平均的な開発者にとって、安全なコードを扱うというコンセプトは極めて孤立したものであり、その範囲は、基本的なものからそれ以上のものまでの全体的な見方とは対照的に、しばしば単一のカテゴリに限定されていることが明らかになりました。開発者は、脆弱性のない新しいコードを書くことよりも、既存の（または事前に承認された）コードを使用することに依存していることが示されました。サードパーティコンポーネントに関するセキュリティ意識（特にパッチ適用、Log4Shellの騒動が良い例。12月以降、30%のインスタンスにパッチが適用されないままになっています）、既存のコードのテストは非常に重要ですが、これらだけでは、セキュアコーディング能力の機能レベルを満たすことはできません。 

コードレベルの脆弱性は、貧弱なコーディングパターンを学んだ開発者によってもたらされます。KPIで安全なコードを書くことを強調しないことは（セキュリティ文化の欠如と相まって）、これを許容範囲内の標準として強化するだけです。 

セキュリティリーダーは、最初の意識を向上させ、最も差し迫った知識不足の分野を特定するために、まず、開発要員に安全なコーディングの全体像を示すようにすることで大きな成果を上げることができる。事前に承認されたコードのテストとスキャンは 1 つの機能ですが、脆弱性を減らすには、実際に使用されている言語とフレームワークで、安全で優れたコーディングパターンを実践的にトレーニングする必要があります。

開発者のスキルアップにはコンテキストが重要であり、ビジネスのセキュリティ目標に関しても、開発者を旅に連れ出す必要があります。

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

ソフトウェア技術の爆発的な発展により、過去10年間にサイバーセキュリティ関連の事件は急速に増加しており、私たちは、貴重なシステムを悪用しようと24時間体制で活動する脅威者に追いつくために必死になっているのです。 

DevSecOpsの方法論は、開発者も含めて、全員がセキュリティに対する責任を共有するという考えに基づいており、SDLCの最初の段階から、セキュリティに対する主要な考慮事項となっています。問題は、特に大企業では、DevSecOpsを標準として導入するには非常に遠いということでしょう。2017年、Project Management Instituteによる調査では、51%の組織がソフトウェア開発にまだWaterfallを使用していることが明らかになりました。この調査はもう5年前のものですが、大企業では変化が緩やかであることを考えると、最新のセキュリティ指向の方法論に急激に移行したとは考えにくいでしょう。このようなレガシーなプロセスは、サイバー脅威から保護するための包括的な戦略ですべての基盤をカバーしようとするセキュリティ専門家にとって苦しい戦いを強いることになり、開発者とそのニーズをこのような状況に適合させることは困難なことなのです。 

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

セキュアコーディング＝「難しすぎる」カゴ？

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

このことは、非常に懸念すべき事態を表しています。一般に、開発者は頻繁かつ適切なトレーニングを受けておらず、優れたセキュリティの実践や衛生に触れる機会も十分でないように思われます。この行間を読むと、問題の核心がより明確になります。つまり、開発者が自分の仕事でセキュリティを考慮することは、単に優先順位が低いということです。そして、彼らが受けるトレーニングは、彼らの自信や実践的なスキルを高めるものではなく、また、脆弱なコードを出荷するという決断がもたらす影響を理解する助けにもならないのです。 

コロニアルパイプラインのランサムウェア攻撃は、過去1年間で最も破壊的なサプライチェーンのセキュリティ事件の1つで、米国東海岸のガス供給の半分が不確定な期間にわたって遮断されるのではないかという恐怖を呼び起こしました。幸いにも、すぐに復旧しましたが、地域社会には大きな不安が残りました。これは、一般市民が、必ずしもソフトウェア駆動型とは考えられていない物理世界の要素にサイバーインシデントが深刻な影響を与え、サイバー攻撃のリスクになるという見通しに直面した、試練の瞬間の一つでした。そして、このような混乱は、パッチを適用していない2つの古い脆弱性によってもたらされました。そのうちの1つは、陰湿でありながら広く知られているSQLインジェクションでした。もし開発者が、脆弱なコードを出荷することを選択したときに何が本当に危険なのかを知れば、それがビジネスリスクとして許容されるシナリオはないことをすぐに理解することでしょう。

機能的な "P-P-T "は開発者に任されているわけではありません。

人、プロセス、ツールの有名な「黄金の三角形」は、慎重に検討された戦略なしには達成できません。また、開発者は、そのニーズと課題を考慮することなく、作業中のセキュリティプロセスに同化できる立場にはありません。

開発者主導のセキュリティを向上させるには、相当な文化の変化が必要であり、エンジニアとセキュリティ・チームの双方がより明確になるような教育経路から始める必要があるのです。