セキュアコードの定義

デジタルビジネスを推進するソフトウェア、アプリケーション、プログラムを作成する開発者は、多くの企業にとって生命線となっています。現代のほとんどのビジネスは、競争力のあるアプリケーションやプログラムがなければ、あるいはウェブサイトやその他のインフラに24時間アクセスできなければ、（利益を生み出す）機能を発揮することはできないでしょう。

しかし、これらのタッチポイントは、ハッカーやその他の悪意のあるユーザーが情報を盗み、攻撃を仕掛け、詐欺やランサムウェアなどの犯罪行為を行うための入り口となることが多いのです。Verizon Data Breach Investigations Report の最新版では、企業や組織に対する脅威は、歴史上かつてないほど危険で高コストになっていることが強調されています。

ほとんどの組織でサイバーセキュリティに対する支出が大幅に増加しているにもかかわらず、また、DevSecOpsのような動きが今日のビジネスの生命線である開発者にセキュリティをシフトしているにもかかわらず、成功した攻撃は依然として広まっています。

開発者はセキュリティの重要性を理解し、安全で高品質なコードをデプロイすることを圧倒的に望んでいますが、ソフトウェアの脆弱性が悪用され続けています。

なぜ？

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

この調査では、何が安全なコードを構成するのかについて、明確な定義や理解がないことが確認されました。開発者が考えるセキュアなコードと、実際のセキュアなコードの間には大きな食い違いがあることが判明しました。

しかし、特にセキュアコードについて質問したところ、脆弱性のないコードを書くという積極的な実践が優先されると答えたのは、わずか29%でした。その代わりに、開発者は、安全なコードを作成するために、より安全で、はるかに信頼性の低い実践を連想しました。例えば、既存のコードを精査すること（37%）、安全なコードのために外部ソースのライブラリに依存すること（37%）が、開発者が安全なコーディングと関連付けるプラクティスの上位に挙げられています。また、すでに安全だと判断されたコードを再利用する（32%）もよく選ばれています。脆弱性のないコードを書くという積極的な実践は6位で、29%が安全なコードを作成するためのトッププラクティスであると回答しています。さらに質問すると、安全なコードを作成するための最大の障壁として、時間不足と経営陣のまとまったアプローチの欠如が挙げられた。

既存のコードへの依存は、悪用可能な脆弱性を持つソフトウェアが出荷されるリスクを高める要因の1つです。何が安全なコードを構成するのか、この断絶に対処することが、開発者が安全で質の高いコードを作成するために必要です。

開発者が考える安全なコードと、実際の安全なコードの間には大きな食い違いがあることが判明しました。

この状況を打開するために、組織は何をすればいいのでしょうか？

この調査から得られた最も重要なメッセージの1つは、開発者コミュニティは全体として、自分たちの仕事に関心を持つプロフェッショナルな人々で満たされているということです。最高品質のコードを書くことは、グループとして圧倒的に重要です。問題は、多くの場合、彼らが働く組織が、安全なコードを作成するために必要なベストプラクティスを特定しておらず、開発者がこれらの目標を達成するためのトレーニングや能力向上に十分なリソースを投入していないことです。

実際、ほとんどの開発者は、何が安全なコードであるかの明確な定義すら持っていないと回答しています。最も心配な例としては、調査回答者の28%が、アプリケーションやプログラムが本番環境に配備されたり、一般に公開された後、違反が報告されなければ、自分の組織はコードを安全だと考えていると回答していることが挙げられます。

言うまでもないことですが、今日の複雑な脅威の状況において、実際に努力することなく良い結果を望むだけでは、予想通りの結果、つまりさらなるセキュリティ侵害が発生する可能性が高いのです。

ありがたいことに、このような状況では、少なくとも問題の解決に着手することは比較的容易であり、その後、安全なコードの目標に向かって作業を開始することができます。最初の、そして間違いなく最も重要なステップは、組織が何を安全なコードと見なすかを定義することです。そして、その定義から外れたものはすべて、安全でないと判断する必要があります。

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

安全なコードという目標を現実のものにするために

セキュアコードの定義が確立されたら、組織はその取り組みと、セキュアコードの完全な実践という目標を遂行する開発者を支援する準備を整える必要があります。このサポートは非常に重要です。このサポートがなければ、組織内のセキュアコードの定義は、重要ではあっても、紙虎に過ぎないでしょう。セキュアコーディングの実践を成功させるには、経営陣の支持を受け、適切な検討、権限、予算が与えられなければなりません。

このため、従来はコーディングのスピードが評価されてきた開発者にとっても、新たなベンチマーク目標が必要になるかもしれません。実際、調査に参加した開発者の37%は、既知の脆弱性を修正したり、最初から適切にコーディングするために必要な時間を、厳しい納期で確保できないため、コード内に放置していると報告しています。当初は、開発者が適切にコーディングする時間を確保するために納期を増やすことを意味するかもしれませんが、コーディングプロセスの最初の段階でかかる時間は、プログラムの修正、パッチ、導入後の作業が少なくなるので、おそらく後で埋め合わせることになるでしょう。しかし、コーディングの初期にかかる時間は、プログラムの修正、パッチ、デプロイ後の作業などの必要性が減るため、後で取り戻せる可能性が高くなります。

また、開発者は、特に遭遇する可能性の高い特定の脆弱性に関連した適切な実践的トレーニングや、コードの脆弱性を特定し修正する方法の習得を支援する必要があるでしょう。このことは、「コードから脆弱性を取り除きたいが、そのためのスキルや知識がない」と回答した調査回答者が36%に上ることを考えると、特に顕著です。

この調査では、37%の開発者が、既知の脆弱性を放置していると回答しています。これは、厳しい納期によって、脆弱性を修正したり、最初から適切にコーディングしたりする時間が取れないためです。

このトピックの詳細については、こちらをご覧ください。

ホワイトペーパー ソフトウェアセキュリティを向上させるための課題（および機会）。
報告書です。 開発者主導型セキュリティの現状調査、2022年。