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

本記事の一部は TechRepublic に掲載されたものです。内容を更新し、転載しています。

‍

セキュリティチームと開発チームの目標を一致させる環境作りは、困難ではあるものの不可欠な戦いです。道のりはまだ長いですが、ソフトウェアセキュリティに対する共通責任への扉を開くために必要な相乗効果を阻む障害は、極めて明白になりつつあります。賢明な企業は、そうした落とし穴を回避し、生産的な前進の道を見つけ、DevSecOpsの持つ人材主導の可能性を最大限に引き出すために戦略を進化させたいと考えています。

予想外だったのは、「セキュアコーディング」とは何かという認識自体が議論の対象になっているという点です。Evans Dataとの共同による最新の調査で、この考え方が明確に示されました。「State of Developer-Driven Security 2022」調査では、1200人の現役開発者の洞察と経験を掘り下げ、セキュリティ領域における彼らの姿勢や課題を明らかにしています。

主要な調査結果の一つとして、コーディング時にセキュリティを優先事項と考える開発者はわずか14%であることが挙げられます。これは改善の余地が非常に大きいことを示していますが、同時に私たちが以前から知っていた事実、つまり開発者の世界では機能開発が最優先であり、彼らはセキュリティを自身のDNAの一部にするための備えができていないという現状を裏付けています。しかし、開発者がセキュアコーディングをどう定義しているかというデータと組み合わせると、懸念を抱かざるを得ません。

こうした認識は、開発者の日々の業務経験から生じており、多くの組織の環境を物語っています。つまり、一般的な脆弱性との戦いにおいて、開発者が単に焦点となっていないのです。彼らの能力向上は不可欠ですが、それまでの間、私たちは「セキュアコーディング」の範囲と、セキュリティスキルを持つ開発者に何を期待すべきかについて、早急に認識を合わせる必要があります。

開発者の世界におけるセキュリティの不可解さを解き明かす必要があります。

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

調査によると、平均的な開発者にとってセキュアコードを扱うという概念は非常に分断されており、その範囲は全体的な基礎やそれ以上の視点ではなく、単一のカテゴリーに限定されていることが多いことが明らかになりました。開発者は、脆弱性のない新しいコードを書くという実践よりも、既存の（または承認済みの）コードを使用することに依存していると回答しています。サードパーティ製コンポーネントに関するセキュリティ意識（特にパッチ適用。Log4Shellの混乱が良い例です：12月以降、30%のインスタンスが未パッチのままです）や、既存コードのテストは非常に重要ですが、これらだけではセキュアコーディング能力として機能的なレベルには達しません。

コードレベルの脆弱性は、不適切なコーディングパターンを学んだ開発者によって持ち込まれます。また、KPIにおいてセキュアなコードを書くことが重視されず（さらにセキュリティ文化の欠如が重なり）、これが許容される基準として定着してしまっています。

セキュリティリーダーは、まず開発チームに対してセキュアコーディングが何を意味するのかという全体像を示すことで、初期の意識向上と最も差し迫った知識ギャップの特定に大きく貢献できます。承認済みコードのテストやスキャンも一つの機能ですが、脆弱性を削減するには、実際に使用されている言語やフレームワークにおいて、優れた安全なコーディングパターンを学ぶ実践的なトレーニングが必要です。

開発者のスキルアップには文脈が不可欠であり、ビジネスのセキュリティ目標を達成する過程に彼らを巻き込む必要があります。

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

ソフトウェア主導の技術が爆発的に普及し、過去10年間でサイバーセキュリティインシデントが急増する中、私たちは皆、貴重なシステムの脆弱性を発見しようと24時間体制で動く脅威アクターに追いつこうと必死になっています。

DevSecOpsの手法は、開発者を含む全員がセキュリティの責任を共有するという考えに基づいており、SDLC（ソフトウェア開発ライフサイクル）の最初から考慮すべき主要な要素です。問題は、特に大企業において、DevSecOpsを標準として導入するにはまだ遠い道のりである可能性があることです。2017年のプロジェクトマネジメント協会による調査では、51%の組織が依然としてソフトウェア開発にウォーターフォールモデルを使用していることが示されました。その調査から5年が経過しましたが、大企業における変化の緩やかさを考えると、最新のセキュリティ指向の手法へ急激に移行したとは考えにくいでしょう。こうしたレガシープロセスは、サイバー脅威から保護するための包括的な戦略で全方位をカバーしようとするセキュリティ専門家にとって困難な戦いを生み出し、この状況に開発者とそのニーズを適合させることは大きな課題です。

しかし、これを言い訳にすることはできません。ビジネスにおけるセキュリティ専門家は、強化された戦略の中で開発者を活用できます。彼らは単に開発者のニーズを把握し、防御策の一部として彼らを考慮に入れる必要があるだけです。開発者には包括的なトレーニングが必要であり、セキュリティに関するあらゆる責任は、彼らの技術スタックとワークフローを尊重した形で実装される必要があります。

セキュアコーディング＝「難しすぎる」という先入観？

Evans Dataの調査によると、驚くべきことに86%の開発者がセキュアコーディングの実践に困難を感じており、92%の開発マネージャーもチームにはセキュリティフレームワークに関するさらなるトレーニングが必要であると認めています。さらに懸念すべきことに、回答者の48%が脆弱性を抱えたままコードをリリースしたことがあると回答しました。

これは非常に憂慮すべき状況を示しています。全体として、開発者は十分かつ頻繁なトレーニングを受けておらず、優れたセキュリティプラクティスや衛生管理に触れる機会も不足しているようです。この状況から読み取れる核心的な問題は、開発者にとってセキュリティを考慮することが優先事項になっていないという点です。また、提供されるトレーニングも、自信や実践的なスキルを養うものになっておらず、脆弱なコードをリリースすることの影響を理解させる助けにもなっていません。

コロニアル・パイプラインへのランサムウェア攻撃は、昨年発生したサプライチェーンセキュリティインシデントの中で最も混乱を招いたものの一つであり、米国東海岸のガソリン供給の半分が長期間停止するのではないかという恐怖を煽りました。幸いにも早期に復旧しましたが、コミュニティには大きな不安が残りました。これは、ソフトウェア主導とは考えられていない、あるいはサイバー攻撃のリスクがあるとは思われていない物理的なインフラが、サイバーインシデントによって深刻な影響を受ける可能性があることを一般の人々が突きつけられた、試練の瞬間でした。そして、その混乱のすべては、古く修正されていない2つの脆弱性によって引き起こされました。その一つが、巧妙でありながら広く知られているSQLインジェクションです。もし開発者が、脆弱なコードをリリースすることが何を意味するのかを真に理解していれば、それが許容できるビジネスリスクなどではないとすぐに気づくはずです。

機能的な「P-P-T」は、開発者個人の責任ではありません。

「人、プロセス、ツール」という有名な「黄金の三角形」は、慎重に検討された戦略なしには実現できません。開発者のニーズや課題を考慮することなく、彼らをセキュリティプロセスに組み込むことは不可能です。

開発者主導のセキュリティを向上させるには大きな文化の変革が必要であり、それはエンジニアとセキュリティチームの双方にさらなる明確さをもたらす教育の道筋から始まります。