セキュアコードの定義

デジタルビジネスを推進するソフトウェア、アプリケーション、プログラムを生み出す開発者は、今や多くの組織にとって生命線となっています。現代のビジネスのほとんどは、競争力のあるアプリケーションやプログラムなしでは、また、Webサイトやその他のインフラへの24時間体制のアクセスなしでは、（収益を上げながら）機能することはできないでしょう。

しかし、こうした接点こそが、ハッカーや悪意のあるユーザーにとって、情報の窃取、攻撃の開始、さらには詐欺やランサムウェアといった犯罪活動への足がかりとなる入り口でもあります。Verizonの最新のデータ漏洩調査報告書（DBIR）は、企業や組織が直面する脅威が、かつてないほど危険かつ高コストになっていることを浮き彫りにしています。

多くの組織でサイバーセキュリティへの支出が大幅に増加し、DevSecOpsのような動きによって、ビジネスの生命線である開発者にセキュリティの責任がシフトしているにもかかわらず、攻撃の成功は依然として後を絶ちません。

開発者はセキュリティの重要性を理解しており、安全で高品質なコードを実装したいと強く願っていますが、ソフトウェアの脆弱性は依然として悪用され続けています。

なぜでしょうか。

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

調査の結果、セキュアコードを構成する要素についての明確な定義や理解が欠如していることが判明しました。開発者が考えるセキュアコードと、実際のセキュアコードとの間には大きな乖離があることがわかったのです。

開発コミュニティにおいて、高品質なコードを書くことが最優先事項であることは驚くべきことではありません。しかし、セキュアコードについて具体的に尋ねたところ、脆弱性のないコードを書くという実践を優先していると回答したのはわずか29%でした。その代わり、開発者は安全性が低く、信頼性もはるかに低い手法をセキュアコードの作成と結びつけていました。例えば、既存のコードを精査すること（37%）や、安全なコードのために外部のライブラリに頼ること（37%）が、開発者がセキュアコーディングと関連付ける上位の手法でした。すでに安全とみなされたコードを再利用すること（32%）も人気のある選択肢でした。脆弱性のないコードを書くという能動的な実践は、セキュアコード作成における主要な手法として29%が挙げ、6位にとどまりました。さらに詳しく尋ねたところ、時間の不足と、経営陣からの統一されたアプローチの欠如が、セキュアコードを作成する上での最大の障壁として挙げられました。

既存のコードへの依存は、悪用可能な脆弱性を含むソフトウェアが出荷されるリスクを高める要因の一つです。セキュアコードとは何かという認識のズレを解消することは、開発者が安全かつ高品質なコードを作成するために不可欠です。

開発者が考えるセキュアコードと、実際のセキュアコードとの間には大きな乖離があることがわかったのです。

この状況を改善するために、組織は何ができるのでしょうか。

この調査から得られた最も重要なメッセージの一つは、開発者コミュニティ全体が、自分の仕事に誇りを持つプロフェッショナルな人々で構成されているということです。彼らにとって、最高品質のコードを書くことはグループとして圧倒的に重要でした。問題は、多くの場合、彼らが所属する組織がセキュアコードを作成するために必要なベストプラクティスを定義しておらず、トレーニングに十分なリソースを割いたり、開発者がその目標を達成できるような環境を整えたりしていないことにあります。

実際、ほとんどの開発者が、所属する組織にはセキュアコードを構成する要素についての明確な定義さえないと回答しました。最も懸念される例として、回答者の28%が、アプリケーションやプログラムが本番環境にデプロイされた後、あるいは一般公開された後に侵害が報告されなければ、そのコードは安全であると組織がみなしていると答えました。

言うまでもないことですが、今日の複雑な脅威環境において、具体的な対策を講じることなく良い結果を期待するだけでは、予測可能な結果、つまりさらなるセキュリティ侵害を招く可能性が高いでしょう。

幸いなことに、この問題は比較的容易に着手でき、セキュアコードという目標に向けて取り組み始めることができます。最初にして最も重要なステップは、組織として何をセキュアコードとみなすかを定義することです。そして、その定義から外れるものはすべて「安全ではない」とみなす必要があります。

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

セキュアコーディングを現実のものに

セキュアコードの定義が定まったら、組織はそれを支える体制を整え、目標達成に向けて取り組む開発者を支援しなければなりません。このサポートは不可欠です。それがなければ、組織内で定義されたセキュアコードは、どれほど重要であっても絵に描いた餅に過ぎません。セキュアコーディングの実践を成功させるには、経営陣がそれを承認し、適切な配慮、権限、予算を与える必要があります。

そのためには、これまでコーディングのスピードで評価されてきた開発者に対し、新たなベンチマーク目標を設定する必要があるかもしれません。実際、調査対象の開発者の37%が、厳しい納期のために修正や適切なコーディングを行う時間がなく、既知の脆弱性をコードに残したままにしていると回答しています。当初は納期を延長し、開発者が適切にコーディングできる時間を確保する必要があるかもしれませんが、開発初期に時間をかけることで、後の修正やパッチ適用、デプロイ後の作業が減り、結果として時間の節約につながります。さらに、デプロイ後の侵害リスクを排除できれば、何百時間もの工数削減に加え、収益の損失、罰金、復旧コストといった数百万ドル規模の損害を防ぐことにもつながります。

また、開発者には、直面する可能性の高い脆弱性に特化した、実践的で関連性の高いトレーニングが必要です。コードの脆弱性を特定し、修正する方法を学ぶための支援も欠かせません。調査回答者の36%が、コードから脆弱性を排除したいと考えていながら、そのためのスキルや知識が不足していると答えていることからも、この重要性は明らかです。

調査対象の開発者の37%が、厳しい納期のために修正や適切なコーディングを行う時間がなく、既知の脆弱性をコードに残したままにしていると回答しています。

このトピックについてさらに詳しく知りたいですか？

ホワイトペーパー： ソフトウェアセキュリティ向上のための課題（と機会）
レポート： 2022年版 開発者主導のセキュリティに関する調査