left of left」から始める。安全なコードは常に品質の高いコードか？

この記事の一版は ダークリーディング.この記事はDark Readingに掲載されたものを更新し、ここにシンジケートされています。

開発者にセキュリティの話をするとき、私は「質の高いコードとは、安全なコードである」ということをモットーにしています。これは今でも真実です。90年代に脆弱なソフトウェアが野放しにされていたときには災害を免れたかもしれませんが、今日ではリスクを冒す価値はありません。長年にわたり、多くの開発者がセキュリティを意識した考え方を身につけようと努力してきました。そうすることで、コードの自己assessment に関しては、セキュリティが品質と同義語になっていることを期待しています。

しかし、よく考えてみると（仲間内でも議論がありましたが）、これは概念を単純化しすぎているのではないでしょうか。確かに安全なコードであっても、開発技術が未熟であったり、その他の問題点があったりして、理想的ではないコードを作ることは十分に可能です。

私たちの業界では、「左にシフトする」という概念が盛んに語られています。私の考えでは、「左遷」とは、エンジニア仲間が（品質の一面である）セキュリティに対する責任を共有できるようにし、（文字通り）指先で一般的な脆弱性を消し去る力を与えることです。しかし、今回の問題を考慮すると、限界をもう少し広げなければならないように思えます。

ある程度の品質のコードは、その定義上、安全でもありますが、すべての安全なコードが必ずしも良い品質であるとは限りません。レフト・オブ・レフト "から始めることが、純粋に安全なコーディング基準を確保するための公式なのでしょうか？

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

このコードスニペットに虫眼鏡をかけてみましょう。

このコードをセキュリティの観点から分析すると、このスニペットは確かに安全であり、攻撃者がSQLインジェクションの脆弱性を悪用するためのエントリーポイントではありません。  

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

このセキュリティ対策は非常に限られた範囲のものでしたが、より徹底した（あるいは経験豊富な）開発者であれば、非効率な引数構造の影響を考慮して別のアプローチをとったかもしれません。このようなコードを出荷することは不適切な行為であるだけでなく、開発グループの他のメンバーにとっても悪い手本となります。

ソフトウェアの「三重奏」。形、機能、要塞のようなもの？

エンターテインメント業界における「三拍子揃った人材」とは、演技、ダンス、歌を同じように高いレベルでこなす人のことです。彼らは、オーディションのたびに恐れられ、羨ましがられる存在であり、すでに競争が激化している業界のユニコーンともいえる存在です。どの業界にも、その業界の製品やサービスのトップレベルの例外的な例がありますが、ソフトウェアも例外ではありません。

アプリケーションにおいて、同等の（高い）品質とのバランスをとるのが難しい3つの要素を考えてみると、「機能性／優美さ」、「鉄壁のセキュリティ」、「要求される納品スピードを考慮したコスト効率」ではないでしょうか。さて、最後の属性は、他の2つの選択肢がどれだけ適用されるかを決定づける要因であることは間違いなく、時間の経過とともに全体的な品質が低下するきっかけにもなります。

しかし、すべてのソフトウェアはヒュー・ジャックマンのようなパフォーマンスが必要なのか、それともニコラス・ケイジでも良いのか。言い換えれば、ウルヴァリンをチームに迎え入れることができるなら、ベストショットを尽くすということです。

マーティン・ファウラーは、ソフトウェア開発において「高品質はコストに見合うか」という問いを投げかけ、「価値がある」だけでなく、時間が経てば経つほど実際に安くなると結論づけました。ほとんどのユーザーは、コードがめちゃくちゃになっていないか、セキュリティが他のものと同じように重要になっていないかを評価するために、ボンネットの中を見ようとはしません。しかし、ツール担当者は、新しい機能を追加するためにずさんなコードをやり直したり、何が起こっているのかを理解するためにプロジェクトの主要部分を調べたり、最悪の場合は、AppSecチームから跳ね返ってきた脆弱性を修正して生産を遅らせるなど、貴重な時間を浪費することになります。今、コードを安全で良質なものにするために時間を費やすことは、不完全に実行された作業を解明するためのコストは言うまでもなく、将来の多くの苦痛を避けることになります。

熟練したセキュリティ意識の高い開発者は、エンジニアがプロセスの各段階でコントロールできる一般的なセキュリティの落とし穴を取り除くことを考慮しながら、機能提供における創造的で問題解決のビジョンを維持するコードを書きます。セキュアなコードは、単独ではあまり効果的ではありません。だからこそ、「レフト・オブ・レフト」という考え方は、開発者にとってセキュリティが自然なことであり、リスクを抑えて素晴らしい機能を提供する能力に組み込まれているという文化を支えることになるのです。

ユーザーが安心して使用できるようにするためには、"left of left "から始めることが重要です。

ソフトウェアのユーザー体験において、セキュリティは長い間考慮されてきましたが、明らかに成功とは言えない結果となっています。過去1年間に発生したクラウドベースのデータ漏洩のうち、セキュリティの設定ミスは21％を占めており、パスワードを平文で保存するなどの素人的なミスにより、被害を受けた企業は生産性、収益、顧客の信頼を大きく失うことになりました。

また、自分のデータを保護することに関しては、ユーザー自身が最大の敵となる可能性があります。いまだにパスワードに「password」を使っていたり、複数の重要なアカウントで同じ組み合わせを使っている人があまりにも多いのです。

堅牢で機能的なセキュリティフローを設計し、ユーザーが納得して操作でき、かつ混乱を最小限に抑えるには、微妙なバランスが必要なのです。

あまりにも複雑な手順や制限を設けると、ユーザーが二度と戻ってこなくなる可能性があります（新しいアプリにとっては最悪です）。簡単すぎると、セキュリティの面で失敗することになります。

安全なユーザー体験を成功させるためには、しっかりとしたセキュリティを意味のある流れの中に織り込み、ソフトウェアの魅力を損なわないような方法で提示する必要があります。複雑なパスワードの要求、CAPTCHA、ミニボス、4種類のゾンビなど、あらゆる方法で安全なログイン機能をコーディングするという目的は確かに達成できますが、それがユーザーの反感を買うような混乱したものであれば、的外れと言わざるを得ません。

ソフトウェア・エクセレンスの基礎を築く。

私自身も開発者の一人ですが、大多数の人は自分の仕事に誇りを持ち、正しいことをしたいと思っています。しかし、多くのソフトウェアエンジニアは、成功するための環境が整っていないという厳しい現実があります。

レフト・オブ・レフト」は、開発者ファーストのコンセプトであり、組織はエンジニア集団のレベルアップに真剣に取り組む必要があります。セキュリティを意識した開発者は金に値する存在であり、トレーニングや適切なツールの提供、経験豊富な開発者から指導を受ける機会などのサポートを受けることで、ソフトウェアを次のレベルに引き上げるために必要な正確さと細部へのこだわりを持って、セキュリティを第一に考えたコードが作成される環境が醸成される。

自分の中のセキュアコーディングの火をつける準備はできていますか？ 挑戦する.

‍