「左から左へ」から始める:セキュアコードは常に品質の高いコードなのか?

この記事のバージョンが掲載されました ダークリーディング。ここで更新され、シンジケートされました。

セキュリティについて開発者と話すとき、私のモットーの1つは「品質の高いコードは安全なコードだけだ」ということです。これは変わりません。90 年代に脆弱なソフトウェアが世に出ていたとき、私たちは災害を免れたかもしれませんが、今日ではリスクを冒す価値はありません。多くの開発者が長年にわたり、開発者にセキュリティ意識を浸透させるために懸命に取り組んできました。そうすることで、コードの自己評価において、セキュリティが品質と同義語になることを願っています。

しかし、振り返ってみると（そして私の同僚の間でのいくつかの議論も）、それはおそらく概念を単純化しすぎているでしょう。確かに安全でありながら、初心者の開発技法の兆候や、理想的とは言えないその他の問題領域を示すコードを作成することは完全に可能です。

私たちの業界では、「左へのシフト」という概念について長々と語っています。私の考えでは、エンジニアリングチームがセキュリティ (品質の一面) に対する責任を分担できるようにし、共通の脆弱性を (文字通りの) 指先ひとつで消去する権限をエンジニアリングコホートに与えることが、残された「スタートアップ」に尽きます。しかし、現在のこの難問を踏まえると、限界をもう少し押し進める必要があるように思えます。

ある程度の品質のコードもその定義上安全ですが、すべての安全なコードが必ずしも高品質であるとは限りません。純粋に安全なコーディング標準を確保するには、「左から左へ」から始めるのが公式なのでしょうか？

「質の悪い」セキュアコードとはどのようなものですか?

このコードスニペットを拡大鏡で見てみましょう。

セキュリティの観点からこのコードを分析すると、このスニペットは確かに安全であり、攻撃者が SQL Injection の脆弱性を悪用するための入り口にはなりません。

高品質のコードの例ですか？残念ながら、実際にはそうではありません。引数を a から単純に変更しただけです ミント (エーガー) に ストリング value では、自由形式のユーザー入力でクエリを操作できます。これに対し、数値では操作できません。その変更、あるいはどこか別の場所から String sql を無計画にコピーして貼り付けると、SQL インジェクションの脆弱性とそれに伴うすべてのリスクが発生する可能性のある環境がすぐに作り出されます。

ここではセキュリティ対策の範囲が非常に限られていましたが、より徹底した (または経験豊富な) 開発者は別のアプローチを取り、非効率的な引数構造の影響について検討した可能性があります。このようなコードの公開は、不適切なやり方であるだけでなく、開発コホートの他のメンバーにとっても悪い手本となります。

ソフトウェア「三重の脅威」：形態、機能、要塞のような？

エンターテインメント業界における「三重の脅威」とは、演技、ダンス、歌を同等に高いレベルのスキルで発揮できる個人です。彼らはオーディションのたびに恐れられ、うらやましく思われる人々であり、すでに競争の激しい業界のユニコーンなのです。どの業界にも独自のトップクラスの優れた製品とサービスがありますが、ソフトウェアも例外ではありません。

同等の (高品質) 品質でバランスを取るのが難しいアプリケーションの 3 つの重要な要素を考えてみると、それらは機能性/エレガンス、強固なセキュリティ、そして要求される配信速度を考慮した際の費用対効果です。さて、最後の属性は、間違いなく他の2つの選択肢がどの程度うまく適用されるかを決定づける要因であり、時間の経過とともに全体的な品質が低下するきっかけにもなり得ます。

しかし、すべてのソフトウェアがヒュー・ジャックマンのように動作する必要があるのか、それともニコラス・ケイジとうまくやっていけるのか？言い換えると、ウルヴァリンをチームに入れることができれば、ベストを尽くすことになります。

マーティン・ファウラーが質問しました 高品質はコストに見合う価値がありますか？ ソフトウェア開発では、「それだけの価値がある」だけでなく、時間が経つにつれて実際には安価になったと結論付けました。ほとんどのユーザーは、コードがめちゃくちゃかどうかや、セキュリティが他のすべてと同じくらい重要視されているかどうかを内部から調べることはないでしょう。しかし、ツールを利用している人は、新しい機能を追加するためにずさんなコードをやり直したり、何が起きているのかを理解するためにプロジェクトの主要部分を調べたり、あるいは最悪のシナリオ、つまりAppSecチームから戻ってきて生産を遅らせた脆弱性の修正に貴重な時間を浪費することになります。コードを安全かつ高品質にするために今時間を費やすことで、不適切に実行された作業を解明するコストは言うまでもなく、将来の悩みの種となる多くの問題を解決できます。

熟練したセキュリティ意識の高い開発者は、エンジニアがプロセスの各段階で制御できる一般的なセキュリティ上の落とし穴を取り除くことを考慮しながら、機能提供における創造的で問題解決のビジョンを維持したコードを書きます。安全なコードは単独ではそれほど効果的ではありません。だからこそ、「左から左」から始めるという概念が、リスクを抑えながら素晴らしい機能を提供する能力に組み込まれた、開発者にとって身近な存在としてのセキュリティ文化を支える助けとなるのです。

安全なユーザーエクスペリエンスには、「左から左」から始めることが重要です。

セキュリティは長い間、ソフトウェアのユーザーエクスペリエンスにおいて考慮されてきましたが、結果は明らかにまちまちでした。セキュリティの設定ミスが原因でした。 クラウドベースのデータ侵害の 21% 過去1年間、パスワードをプレーンテキストで保存するなどのアマチュアアワーのミスにより、影響を受けた企業の生産性、収益、顧客の信頼が著しく低下しました。

さらに、ユーザー自身が自分のデータを保護することになると、ユーザー自身が最悪の敵になる可能性があります。 人が多すぎる 依然として「パスワード」をパスワードとして使用しているか、複数の機密アカウントで同じ組み合わせを使用しています。

ログイン画面で作業しなければならないと言われたときに慌てて判断する開発者は誰もいません。それも不思議ではありません。堅牢で機能的なセキュリティフローを設計し、ユーザーが混乱を最小限に抑えながら意味のある方法でナビゲートできるセキュリティフローを設計するのは微妙なバランスです。

複雑な手順や制限が多すぎると、ユーザーは二度と戻らないように切り替える可能性があり（新しいアプリにとっては災害）、混乱を招きすぎて、アカウントにアクセスしようとするユーザーからの問い合わせに対応する際に、サポートチームが集団的な片頭痛に陥る可能性があります。簡単にしすぎると、セキュリティの部分で失敗しているようなものです。

セキュアなユーザーエクスペリエンスを成功させるには、厳密なセキュリティを理にかなったフローに組み込む必要があります。このフローは、ソフトウェアの魅力である他の要素をすべて損なうことのない方法で提示する必要があります。複雑なパスワード要件、CAPTCHA、ミニボス、4波のゾンビなど、安全なログイン機能をコーディングするという目的は確かに達成できますが、それがユーザーにとって嫌な完全に混乱しているとしたら、それは的外れです。

ソフトウェア・エクセレンスの基礎を築きましょう。

私自身開発者として、私たちの大多数は自分の仕事に誇りを持っており、正しいことをしたいと思っていることを知っています。時間の制約、現在の目標の突然の変更、緊急のホットフィックスなどの厄介なカーブボールは、フローを混乱させ、間違いにつながる可能性がありますが、厳しい真実は、多くのソフトウェアエンジニアが成功するための準備が整っていないということです。

「左から左」から始めることは開発者第一の概念であり、組織はエンジニアリングチームの向上に真剣に取り組む必要があります。セキュリティ意識の高い開発者はそれだけの価値があり、トレーニング、適切なツールの提供、経験豊富な開発者からの指導を受ける機会という形でのサポートを受けることで、ソフトウェアを次のレベルに引き上げるために必要な正確さと細部への配慮を備えた、セキュリティ第一の考え方でコードを作成する環境が育まれます。

あなた自身でセキュア・コーディングの火をつける準備はできていますか？ 挑戦に立ち向かえ。

‍