「レフト・オブ・レフト」から始める：セキュアなコードは常に高品質なコードか？

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

開発者にセキュリティについて話す際、私が常に伝えているのは「品質の良いコードとは、セキュアなコードのことである」という考え方です。これは今でも真実です。90年代には脆弱なソフトウェアが世に出回っていても大惨事を免れていたかもしれませんが、今日ではそのようなリスクを冒す価値はありません。長年にわたり、多くの人々が開発者にセキュリティ意識を植え付けるために懸命に取り組んできました。その結果、開発者が自身のコードを評価する際に、セキュリティが品質と同義のものとして認識されるようになったことを願っています。

しかし、振り返ってみると（そして同僚との議論を経て）、その考え方は少し単純化しすぎているかもしれません。確かにセキュアではあるものの、初心者のような技術が使われていたり、理想的とは言えない問題点が残っていたりするコードを作成することは十分に可能です。

業界では「シフトレフト」という概念が盛んに議論されています。私の考えでは、重要なのは「左から始める」ことです。エンジニアチームがセキュリティ（品質の一側面）に対する責任を共有できるようにし、一般的な脆弱性を（文字通り）指先一つで排除できる力を与えることが大切です。しかし、現在の難題を考えると、その枠組みをもう少し押し広げる必要があるようです。

ある程度の品質を備えたコードは、定義上セキュアであると言えます。しかし、セキュアなコードが必ずしも高品質であるとは限りません。「左のさらに左」から始めることは、純粋なセキュアコーディングの基準を確保するための公式となるのでしょうか。

「品質の低い」セキュアなコードとはどのようなものでしょうか？

このコードスニペットを詳しく見てみましょう。

セキュリティの観点からこのコードを分析すると、確かにセキュアであり、攻撃者がSQLインジェクションの脆弱性を突くための入り口にはなっていません。

では、これは高品質なコードの例と言えるでしょうか？残念ながら、そうとは言えません。引数をint(整数)からString(文字列)に変更するだけで、数値とは異なり、自由形式のユーザー入力によってクエリが操作可能になってしまいます。その変更、あるいは他の場所からString sqlを安易にコピー＆ペーストしただけで、SQLインジェクションの脆弱性が生じる環境が即座に作り出され、それに伴うあらゆるリスクが発生します。

ここでのセキュリティ対策は非常に限定的な範囲にとどまっていました。より徹底した（あるいは経験豊富な）開発者であれば、異なるアプローチをとり、非効率な引数構造がもたらす影響を考慮したはずです。このようなコードをリリースすることは、悪い習慣であるだけでなく、開発チームの他のメンバーに悪しき前例を作ることになります。

ソフトウェアの「三冠王」：形式、機能、そして要塞のような堅牢さ？

エンターテインメント業界における「三冠王（トリプルスレット）」とは、演技、ダンス、歌を同等の高いレベルでこなせる個人のことを指します。彼らはあらゆるオーディションで恐れられ、羨望の的となる、競争の激しい世界におけるユニコーンのような存在です。どの業界にも、その製品やサービスの最高峰を示す独自の例が存在しますが、ソフトウェアも例外ではありません。

アプリケーションにおいて、同等の（高い）品質でバランスを取るのが難しい3つの重要な要素を挙げるとすれば、それは機能性／エレガンス、鉄壁のセキュリティ、そして求められる提供スピードを考慮した費用対効果でしょう。最後の要素は、他の2つの選択肢がどれだけうまく適用されるかを決定づける紛れもない要因であり、時間の経過とともに全体的な品質が低下する引き金にもなり得ます。

しかし、すべてのソフトウェアがヒュー・ジャックマンのようなパフォーマンスを発揮する必要があるのでしょうか？それともニコラス・ケイジのような存在でも許されるのでしょうか？こう考えてみてください。もしチームにウルヴァリンを迎え入れられるなら、全力を尽くすべきだということです。

マーティン・ファウラーは、ソフトウェア開発において「高品質にはコスト をかける価値があるか？」という問いを投げかけ、それが「価値がある」だけでなく、長期的には実際には安上がりであると結論づけました。ほとんどのユーザーは、コードが乱雑かどうか、あるいはセキュリティが他のすべてと同じくらい重要視されているかどうかを内部まで確認することはありません。しかし、実際にツールを扱う開発者は、ずさんなコードをやり直して新しい機能を追加したり、何が起きているのかを理解するためにプロジェクトの主要部分を調べ回ったり、最悪の場合、AppSecチームから突き返された脆弱性を修正して本番環境へのリリースを遅らせたりすることに貴重な時間を浪費することになります。コードをセキュアかつ高品質にするために今時間を費やすことは、将来の多くの心痛を救い、不適切な作業をやり直すコストを省くことにつながります。

スキルがありセキュリティを意識した開発者は、機能提供における創造的で問題解決的なビジョンを維持しつつ、エンジニアがプロセスの段階で制御できる一般的なセキュリティの落とし穴を排除することを考慮したコードを書きます。セキュアなコードは単体ではそれほど効果的ではありません。だからこそ、「左のさらに左」から始めるという考え方が、開発者にとってセキュリティを当たり前のものとする文化を支え、リスクを抑えながら素晴らしい機能を提供する能力を構築する助けとなるのです。

「左のさらに左」から始めることは、セキュアなユーザー体験にとって不可欠です。

セキュリティは長い間、ソフトウェアのユーザー体験において考慮されてきましたが、その成功はまちまちでした。セキュリティの設定ミスは、過去1年間のクラウドベースのデータ侵害の21%を占めており、パスワードを平文で保存するといった初歩的なミスが、影響を受けた企業に生産性、収益、そして顧客の信頼という面で深刻な損失をもたらしています。

それに、ユーザー自身が自分のデータを守る上で最大の敵になってしまうこともあります。非常に多くの人が、いまだにパスワードとして「password」を使っていたり、複数の重要なアカウントで同じ組み合わせを使い回していたりします。

ログイン画面の作成を任されてガッツポーズをする開発者なんて聞いたことがありません。それもそのはず、堅牢かつ機能的でありながら、ユーザーが違和感なくスムーズに操作できるセキュリティフローを設計するのは、非常に繊細なバランスが求められる作業だからです。

複雑な手順や制限を課しすぎれば、ユーザーは二度と戻ってこなくなるかもしれません（新しいアプリにとっては致命的です）。かといって分かりにくくすれば、アカウントにアクセスできないユーザーからの問い合わせ対応に追われるサポートチームを悩ませることになります。逆に簡単すぎれば、セキュリティとしての役割を果たせません。

優れたセキュアなユーザー体験を実現するには、理にかなったフローの中に強固なセキュリティを組み込み、ソフトウェアの魅力を損なわない形で提示する必要があります。セキュアなログイン機能を実装し、複雑なパスワード要件やCAPTCHA、ミニゲームのような認証、さらにはゾンビの群れを倒すような難解な手順を盛り込むことは可能ですが、それがユーザーにとって使いにくい代物であれば、本末転倒です。

ソフトウェアの卓越性を築く基盤を。

私自身も開発者として、私たちの大多数が自分の仕事に誇りを持ち、正しいことをしたいと願っていることを知っています。しかし、時間的な制約や突然の仕様変更、緊急の修正といった厄介な問題が開発の流れを乱し、ミスを引き起こすことがあります。厳しい現実として、多くのソフトウェアエンジニアは成功するための環境が整っていないのです。

「レフト・オブ・レフト（左のさらに左）」から始めることは、開発者ファーストの概念であり、組織がエンジニアの育成に真剣に取り組むことを求めています。セキュリティ意識の高い開発者は非常に貴重な存在です。トレーニングや適切なツールの提供、経験豊富な開発者によるメンタリングといったサポートは、セキュリティを第一に考え、ソフトウェアを次のレベルへ引き上げるための精密さと細部へのこだわりを持ってコードが書かれる環境を育みます。

セキュアコーディングへの情熱を燃やす準備はできましたか？ 挑戦を始めましょう。

‍