left of left」から始める。安全なコードは常に品質の高いコードか？
この記事の一版は ダークリーディング.この記事はDark Readingに掲載されたものを更新し、ここにシンジケートされています。
開発者にセキュリティの話をするとき、私は「質の高いコードとは、安全なコードである」ということをモットーにしています。これは今でも真実です。90年代に脆弱なソフトウェアが野放しにされていたときには災害を免れたかもしれませんが、今日ではリスクを冒す価値はありません。長年にわたり、多くの開発者がセキュリティを意識した考え方を身につけようと努力してきました。そうすることで、コードの自己assessment に関しては、セキュリティが品質と同義語になっていることを期待しています。
しかし、よく考えてみると（仲間内でも議論がありましたが）、これは概念を単純化しすぎているのではないでしょうか。確かに安全なコードであっても、開発技術が未熟であったり、その他の問題点があったりして、理想的ではないコードを作ることは十分に可能です。
私たちの業界では、「左にシフトする」という概念が盛んに語られています。私の考えでは、「左遷」とは、エンジニア仲間が（品質の一面である）セキュリティに対する責任を共有できるようにし、（文字通り）指先で一般的な脆弱性を消し去る力を与えることです。しかし、今回の問題を考慮すると、限界をもう少し広げなければならないように思えます。
ある程度の品質のコードは、その定義上、安全でもありますが、すべての安全なコードが必ずしも良い品質であるとは限りません。レフト・オブ・レフト "から始めることが、純粋に安全なコーディング基準を確保するための公式なのでしょうか？
質の悪い」セキュアコードとはどのようなものでしょうか？
このコードスニペットに虫眼鏡をかけてみましょう。
このコードをセキュリティの観点から分析すると、このスニペットは確かに安全であり、攻撃者がSQLインジェクションの脆弱性を悪用するためのエントリーポイントではありません。
これは高品質なコードの例ですか？残念ながら、そうではありません。引数をint(整数)からString値に変更するだけで、自由形式のユーザ入力でクエリを操作することができますが、数値ではできません。この変更（あるいはどこか他の場所からString sqlを無造作にコピー＆ペーストした場合）は、SQLインジェクションの脆弱性が可能な環境を即座に作り出し、それに伴うすべてのリスクが発生します。
このセキュリティ対策は非常に限られた範囲のものでしたが、より徹底した（あるいは経験豊富な）開発者であれば、非効率な引数構造の影響を考慮して別のアプローチをとったかもしれません。このようなコードを出荷することは不適切な行為であるだけでなく、開発グループの他のメンバーにとっても悪い手本となります。
ソフトウェアの「三重奏」。形、機能、要塞のようなもの？
エンターテインメント業界における「三拍子揃った人材」とは、演技、ダンス、歌を同じように高いレベルでこなす人のことです。彼らは、オーディションのたびに恐れられ、羨ましがられる存在であり、すでに競争が激化している業界のユニコーンともいえる存在です。どの業界にも、その業界の製品やサービスのトップレベルの例外的な例がありますが、ソフトウェアも例外ではありません。
アプリケーションにおいて、同等の（高い）品質とのバランスをとるのが難しい3つの要素を考えてみると、「機能性／優美さ」、「鉄壁のセキュリティ」、「要求される納品スピードを考慮したコスト効率」ではないでしょうか。さて、最後の属性は、他の2つの選択肢がどれだけ適用されるかを決定づける要因であることは間違いなく、時間の経過とともに全体的な品質が低下するきっかけにもなります。
しかし、すべてのソフトウェアはヒュー・ジャックマンのようなパフォーマンスが必要なのか、それともニコラス・ケイジでも良いのか。言い換えれば、ウルヴァリンをチームに迎え入れることができるなら、ベストショットを尽くすということです。
マーティン・ファウラーは、ソフトウェア開発において「高品質はコストに見合うか」という問いを投げかけ、「価値がある」だけでなく、時間が経てば経つほど実際に安くなると結論づけました。ほとんどのユーザーは、コードがめちゃくちゃになっていないか、セキュリティが他のものと同じように重要になっていないかを評価するために、ボンネットの中を見ようとはしません。しかし、ツール担当者は、新しい機能を追加するためにずさんなコードをやり直したり、何が起こっているのかを理解するためにプロジェクトの主要部分を調べたり、最悪の場合は、AppSecチームから跳ね返ってきた脆弱性を修正して生産を遅らせるなど、貴重な時間を浪費することになります。今、コードを安全で良質なものにするために時間を費やすことは、不完全に実行された作業を解明するためのコストは言うまでもなく、将来の多くの苦痛を避けることになります。
熟練したセキュリティ意識の高い開発者は、エンジニアがプロセスの各段階でコントロールできる一般的なセキュリティの落とし穴を取り除くことを考慮しながら、機能提供における創造的で問題解決のビジョンを維持するコードを書きます。セキュアなコードは、単独ではあまり効果的ではありません。だからこそ、「レフト・オブ・レフト」という考え方は、開発者にとってセキュリティが自然なことであり、リスクを抑えて素晴らしい機能を提供する能力に組み込まれているという文化を支えることになるのです。
ユーザーが安心して使用できるようにするためには、"left of left "から始めることが重要です。
ソフトウェアのユーザー体験において、セキュリティは長い間考慮されてきましたが、明らかに成功とは言えない結果となっています。過去1年間に発生したクラウドベースのデータ漏洩のうち、セキュリティの設定ミスは21％を占めており、パスワードを平文で保存するなどの素人的なミスにより、被害を受けた企業は生産性、収益、顧客の信頼を大きく失うことになりました。
また、自分のデータを保護することに関しては、ユーザー自身が最大の敵となる可能性があります。いまだにパスワードに「password」を使っていたり、複数の重要なアカウントで同じ組み合わせを使っている人があまりにも多いのです。
堅牢で機能的なセキュリティフローを設計し、ユーザーが納得して操作でき、かつ混乱を最小限に抑えるには、微妙なバランスが必要なのです。
あまりにも複雑な手順や制限を設けると、ユーザーが二度と戻ってこなくなる可能性があります（新しいアプリにとっては最悪です）。簡単すぎると、セキュリティの面で失敗することになります。
安全なユーザー体験を成功させるためには、しっかりとしたセキュリティを意味のある流れの中に織り込み、ソフトウェアの魅力を損なわないような方法で提示する必要があります。複雑なパスワードの要求、CAPTCHA、ミニボス、4種類のゾンビなど、あらゆる方法で安全なログイン機能をコーディングするという目的は確かに達成できますが、それがユーザーの反感を買うような混乱したものであれば、的外れと言わざるを得ません。
ソフトウェア・エクセレンスの基礎を築く。
私自身も開発者の一人ですが、大多数の人は自分の仕事に誇りを持ち、正しいことをしたいと思っています。しかし、多くのソフトウェアエンジニアは、成功するための環境が整っていないという厳しい現実があります。
レフト・オブ・レフト」は、開発者ファーストのコンセプトであり、組織はエンジニア集団のレベルアップに真剣に取り組む必要があります。セキュリティを意識した開発者は金に値する存在であり、トレーニングや適切なツールの提供、経験豊富な開発者から指導を受ける機会などのサポートを受けることで、ソフトウェアを次のレベルに引き上げるために必要な正確さと細部へのこだわりを持って、セキュリティを第一に考えたコードが作成される環境が醸成される。
自分の中のセキュアコーディングの火をつける準備はできていますか？ 挑戦する.
ある程度の品質のコードは、その定義上、安全でもありますが、すべての安全なコードが必ずしも良い品質であるとは限りません。レフト・オブ・レフト "から始めることが、純粋に安全なコーディング基準を確保するための公式なのでしょうか？
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
この記事の一版は ダークリーディング.この記事はDark Readingに掲載されたものを更新し、ここにシンジケートされています。
開発者にセキュリティの話をするとき、私は「質の高いコードとは、安全なコードである」ということをモットーにしています。これは今でも真実です。90年代に脆弱なソフトウェアが野放しにされていたときには災害を免れたかもしれませんが、今日ではリスクを冒す価値はありません。長年にわたり、多くの開発者がセキュリティを意識した考え方を身につけようと努力してきました。そうすることで、コードの自己assessment に関しては、セキュリティが品質と同義語になっていることを期待しています。
しかし、よく考えてみると（仲間内でも議論がありましたが）、これは概念を単純化しすぎているのではないでしょうか。確かに安全なコードであっても、開発技術が未熟であったり、その他の問題点があったりして、理想的ではないコードを作ることは十分に可能です。
私たちの業界では、「左にシフトする」という概念が盛んに語られています。私の考えでは、「左遷」とは、エンジニア仲間が（品質の一面である）セキュリティに対する責任を共有できるようにし、（文字通り）指先で一般的な脆弱性を消し去る力を与えることです。しかし、今回の問題を考慮すると、限界をもう少し広げなければならないように思えます。
ある程度の品質のコードは、その定義上、安全でもありますが、すべての安全なコードが必ずしも良い品質であるとは限りません。レフト・オブ・レフト "から始めることが、純粋に安全なコーディング基準を確保するための公式なのでしょうか？
質の悪い」セキュアコードとはどのようなものでしょうか？
このコードスニペットに虫眼鏡をかけてみましょう。
このコードをセキュリティの観点から分析すると、このスニペットは確かに安全であり、攻撃者がSQLインジェクションの脆弱性を悪用するためのエントリーポイントではありません。
これは高品質なコードの例ですか？残念ながら、そうではありません。引数をint(整数)からString値に変更するだけで、自由形式のユーザ入力でクエリを操作することができますが、数値ではできません。この変更（あるいはどこか他の場所からString sqlを無造作にコピー＆ペーストした場合）は、SQLインジェクションの脆弱性が可能な環境を即座に作り出し、それに伴うすべてのリスクが発生します。
このセキュリティ対策は非常に限られた範囲のものでしたが、より徹底した（あるいは経験豊富な）開発者であれば、非効率な引数構造の影響を考慮して別のアプローチをとったかもしれません。このようなコードを出荷することは不適切な行為であるだけでなく、開発グループの他のメンバーにとっても悪い手本となります。
ソフトウェアの「三重奏」。形、機能、要塞のようなもの？
エンターテインメント業界における「三拍子揃った人材」とは、演技、ダンス、歌を同じように高いレベルでこなす人のことです。彼らは、オーディションのたびに恐れられ、羨ましがられる存在であり、すでに競争が激化している業界のユニコーンともいえる存在です。どの業界にも、その業界の製品やサービスのトップレベルの例外的な例がありますが、ソフトウェアも例外ではありません。
アプリケーションにおいて、同等の（高い）品質とのバランスをとるのが難しい3つの要素を考えてみると、「機能性／優美さ」、「鉄壁のセキュリティ」、「要求される納品スピードを考慮したコスト効率」ではないでしょうか。さて、最後の属性は、他の2つの選択肢がどれだけ適用されるかを決定づける要因であることは間違いなく、時間の経過とともに全体的な品質が低下するきっかけにもなります。
しかし、すべてのソフトウェアはヒュー・ジャックマンのようなパフォーマンスが必要なのか、それともニコラス・ケイジでも良いのか。言い換えれば、ウルヴァリンをチームに迎え入れることができるなら、ベストショットを尽くすということです。
マーティン・ファウラーは、ソフトウェア開発において「高品質はコストに見合うか」という問いを投げかけ、「価値がある」だけでなく、時間が経てば経つほど実際に安くなると結論づけました。ほとんどのユーザーは、コードがめちゃくちゃになっていないか、セキュリティが他のものと同じように重要になっていないかを評価するために、ボンネットの中を見ようとはしません。しかし、ツール担当者は、新しい機能を追加するためにずさんなコードをやり直したり、何が起こっているのかを理解するためにプロジェクトの主要部分を調べたり、最悪の場合は、AppSecチームから跳ね返ってきた脆弱性を修正して生産を遅らせるなど、貴重な時間を浪費することになります。今、コードを安全で良質なものにするために時間を費やすことは、不完全に実行された作業を解明するためのコストは言うまでもなく、将来の多くの苦痛を避けることになります。
熟練したセキュリティ意識の高い開発者は、エンジニアがプロセスの各段階でコントロールできる一般的なセキュリティの落とし穴を取り除くことを考慮しながら、機能提供における創造的で問題解決のビジョンを維持するコードを書きます。セキュアなコードは、単独ではあまり効果的ではありません。だからこそ、「レフト・オブ・レフト」という考え方は、開発者にとってセキュリティが自然なことであり、リスクを抑えて素晴らしい機能を提供する能力に組み込まれているという文化を支えることになるのです。
ユーザーが安心して使用できるようにするためには、"left of left "から始めることが重要です。
ソフトウェアのユーザー体験において、セキュリティは長い間考慮されてきましたが、明らかに成功とは言えない結果となっています。過去1年間に発生したクラウドベースのデータ漏洩のうち、セキュリティの設定ミスは21％を占めており、パスワードを平文で保存するなどの素人的なミスにより、被害を受けた企業は生産性、収益、顧客の信頼を大きく失うことになりました。
また、自分のデータを保護することに関しては、ユーザー自身が最大の敵となる可能性があります。いまだにパスワードに「password」を使っていたり、複数の重要なアカウントで同じ組み合わせを使っている人があまりにも多いのです。
堅牢で機能的なセキュリティフローを設計し、ユーザーが納得して操作でき、かつ混乱を最小限に抑えるには、微妙なバランスが必要なのです。
あまりにも複雑な手順や制限を設けると、ユーザーが二度と戻ってこなくなる可能性があります（新しいアプリにとっては最悪です）。簡単すぎると、セキュリティの面で失敗することになります。
安全なユーザー体験を成功させるためには、しっかりとしたセキュリティを意味のある流れの中に織り込み、ソフトウェアの魅力を損なわないような方法で提示する必要があります。複雑なパスワードの要求、CAPTCHA、ミニボス、4種類のゾンビなど、あらゆる方法で安全なログイン機能をコーディングするという目的は確かに達成できますが、それがユーザーの反感を買うような混乱したものであれば、的外れと言わざるを得ません。
ソフトウェア・エクセレンスの基礎を築く。
私自身も開発者の一人ですが、大多数の人は自分の仕事に誇りを持ち、正しいことをしたいと思っています。しかし、多くのソフトウェアエンジニアは、成功するための環境が整っていないという厳しい現実があります。
レフト・オブ・レフト」は、開発者ファーストのコンセプトであり、組織はエンジニア集団のレベルアップに真剣に取り組む必要があります。セキュリティを意識した開発者は金に値する存在であり、トレーニングや適切なツールの提供、経験豊富な開発者から指導を受ける機会などのサポートを受けることで、ソフトウェアを次のレベルに引き上げるために必要な正確さと細部へのこだわりを持って、セキュリティを第一に考えたコードが作成される環境が醸成される。
自分の中のセキュアコーディングの火をつける準備はできていますか？ 挑戦する.
この記事の一版は ダークリーディング.この記事はDark Readingに掲載されたものを更新し、ここにシンジケートされています。
開発者にセキュリティの話をするとき、私は「質の高いコードとは、安全なコードである」ということをモットーにしています。これは今でも真実です。90年代に脆弱なソフトウェアが野放しにされていたときには災害を免れたかもしれませんが、今日ではリスクを冒す価値はありません。長年にわたり、多くの開発者がセキュリティを意識した考え方を身につけようと努力してきました。そうすることで、コードの自己assessment に関しては、セキュリティが品質と同義語になっていることを期待しています。
しかし、よく考えてみると（仲間内でも議論がありましたが）、これは概念を単純化しすぎているのではないでしょうか。確かに安全なコードであっても、開発技術が未熟であったり、その他の問題点があったりして、理想的ではないコードを作ることは十分に可能です。
私たちの業界では、「左にシフトする」という概念が盛んに語られています。私の考えでは、「左遷」とは、エンジニア仲間が（品質の一面である）セキュリティに対する責任を共有できるようにし、（文字通り）指先で一般的な脆弱性を消し去る力を与えることです。しかし、今回の問題を考慮すると、限界をもう少し広げなければならないように思えます。
ある程度の品質のコードは、その定義上、安全でもありますが、すべての安全なコードが必ずしも良い品質であるとは限りません。レフト・オブ・レフト "から始めることが、純粋に安全なコーディング基準を確保するための公式なのでしょうか？
質の悪い」セキュアコードとはどのようなものでしょうか？
このコードスニペットに虫眼鏡をかけてみましょう。
このコードをセキュリティの観点から分析すると、このスニペットは確かに安全であり、攻撃者がSQLインジェクションの脆弱性を悪用するためのエントリーポイントではありません。
これは高品質なコードの例ですか？残念ながら、そうではありません。引数をint(整数)からString値に変更するだけで、自由形式のユーザ入力でクエリを操作することができますが、数値ではできません。この変更（あるいはどこか他の場所からString sqlを無造作にコピー＆ペーストした場合）は、SQLインジェクションの脆弱性が可能な環境を即座に作り出し、それに伴うすべてのリスクが発生します。
このセキュリティ対策は非常に限られた範囲のものでしたが、より徹底した（あるいは経験豊富な）開発者であれば、非効率な引数構造の影響を考慮して別のアプローチをとったかもしれません。このようなコードを出荷することは不適切な行為であるだけでなく、開発グループの他のメンバーにとっても悪い手本となります。
ソフトウェアの「三重奏」。形、機能、要塞のようなもの？
エンターテインメント業界における「三拍子揃った人材」とは、演技、ダンス、歌を同じように高いレベルでこなす人のことです。彼らは、オーディションのたびに恐れられ、羨ましがられる存在であり、すでに競争が激化している業界のユニコーンともいえる存在です。どの業界にも、その業界の製品やサービスのトップレベルの例外的な例がありますが、ソフトウェアも例外ではありません。
アプリケーションにおいて、同等の（高い）品質とのバランスをとるのが難しい3つの要素を考えてみると、「機能性／優美さ」、「鉄壁のセキュリティ」、「要求される納品スピードを考慮したコスト効率」ではないでしょうか。さて、最後の属性は、他の2つの選択肢がどれだけ適用されるかを決定づける要因であることは間違いなく、時間の経過とともに全体的な品質が低下するきっかけにもなります。
しかし、すべてのソフトウェアはヒュー・ジャックマンのようなパフォーマンスが必要なのか、それともニコラス・ケイジでも良いのか。言い換えれば、ウルヴァリンをチームに迎え入れることができるなら、ベストショットを尽くすということです。
マーティン・ファウラーは、ソフトウェア開発において「高品質はコストに見合うか」という問いを投げかけ、「価値がある」だけでなく、時間が経てば経つほど実際に安くなると結論づけました。ほとんどのユーザーは、コードがめちゃくちゃになっていないか、セキュリティが他のものと同じように重要になっていないかを評価するために、ボンネットの中を見ようとはしません。しかし、ツール担当者は、新しい機能を追加するためにずさんなコードをやり直したり、何が起こっているのかを理解するためにプロジェクトの主要部分を調べたり、最悪の場合は、AppSecチームから跳ね返ってきた脆弱性を修正して生産を遅らせるなど、貴重な時間を浪費することになります。今、コードを安全で良質なものにするために時間を費やすことは、不完全に実行された作業を解明するためのコストは言うまでもなく、将来の多くの苦痛を避けることになります。
熟練したセキュリティ意識の高い開発者は、エンジニアがプロセスの各段階でコントロールできる一般的なセキュリティの落とし穴を取り除くことを考慮しながら、機能提供における創造的で問題解決のビジョンを維持するコードを書きます。セキュアなコードは、単独ではあまり効果的ではありません。だからこそ、「レフト・オブ・レフト」という考え方は、開発者にとってセキュリティが自然なことであり、リスクを抑えて素晴らしい機能を提供する能力に組み込まれているという文化を支えることになるのです。
ユーザーが安心して使用できるようにするためには、"left of left "から始めることが重要です。
ソフトウェアのユーザー体験において、セキュリティは長い間考慮されてきましたが、明らかに成功とは言えない結果となっています。過去1年間に発生したクラウドベースのデータ漏洩のうち、セキュリティの設定ミスは21％を占めており、パスワードを平文で保存するなどの素人的なミスにより、被害を受けた企業は生産性、収益、顧客の信頼を大きく失うことになりました。
また、自分のデータを保護することに関しては、ユーザー自身が最大の敵となる可能性があります。いまだにパスワードに「password」を使っていたり、複数の重要なアカウントで同じ組み合わせを使っている人があまりにも多いのです。
堅牢で機能的なセキュリティフローを設計し、ユーザーが納得して操作でき、かつ混乱を最小限に抑えるには、微妙なバランスが必要なのです。
あまりにも複雑な手順や制限を設けると、ユーザーが二度と戻ってこなくなる可能性があります（新しいアプリにとっては最悪です）。簡単すぎると、セキュリティの面で失敗することになります。
安全なユーザー体験を成功させるためには、しっかりとしたセキュリティを意味のある流れの中に織り込み、ソフトウェアの魅力を損なわないような方法で提示する必要があります。複雑なパスワードの要求、CAPTCHA、ミニボス、4種類のゾンビなど、あらゆる方法で安全なログイン機能をコーディングするという目的は確かに達成できますが、それがユーザーの反感を買うような混乱したものであれば、的外れと言わざるを得ません。
ソフトウェア・エクセレンスの基礎を築く。
私自身も開発者の一人ですが、大多数の人は自分の仕事に誇りを持ち、正しいことをしたいと思っています。しかし、多くのソフトウェアエンジニアは、成功するための環境が整っていないという厳しい現実があります。
レフト・オブ・レフト」は、開発者ファーストのコンセプトであり、組織はエンジニア集団のレベルアップに真剣に取り組む必要があります。セキュリティを意識した開発者は金に値する存在であり、トレーニングや適切なツールの提供、経験豊富な開発者から指導を受ける機会などのサポートを受けることで、ソフトウェアを次のレベルに引き上げるために必要な正確さと細部へのこだわりを持って、セキュリティを第一に考えたコードが作成される環境が醸成される。
自分の中のセキュアコーディングの火をつける準備はできていますか？ 挑戦する.
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
この記事の一版は ダークリーディング.この記事はDark Readingに掲載されたものを更新し、ここにシンジケートされています。
開発者にセキュリティの話をするとき、私は「質の高いコードとは、安全なコードである」ということをモットーにしています。これは今でも真実です。90年代に脆弱なソフトウェアが野放しにされていたときには災害を免れたかもしれませんが、今日ではリスクを冒す価値はありません。長年にわたり、多くの開発者がセキュリティを意識した考え方を身につけようと努力してきました。そうすることで、コードの自己assessment に関しては、セキュリティが品質と同義語になっていることを期待しています。
しかし、よく考えてみると（仲間内でも議論がありましたが）、これは概念を単純化しすぎているのではないでしょうか。確かに安全なコードであっても、開発技術が未熟であったり、その他の問題点があったりして、理想的ではないコードを作ることは十分に可能です。
私たちの業界では、「左にシフトする」という概念が盛んに語られています。私の考えでは、「左遷」とは、エンジニア仲間が（品質の一面である）セキュリティに対する責任を共有できるようにし、（文字通り）指先で一般的な脆弱性を消し去る力を与えることです。しかし、今回の問題を考慮すると、限界をもう少し広げなければならないように思えます。
ある程度の品質のコードは、その定義上、安全でもありますが、すべての安全なコードが必ずしも良い品質であるとは限りません。レフト・オブ・レフト "から始めることが、純粋に安全なコーディング基準を確保するための公式なのでしょうか？
質の悪い」セキュアコードとはどのようなものでしょうか？
このコードスニペットに虫眼鏡をかけてみましょう。
このコードをセキュリティの観点から分析すると、このスニペットは確かに安全であり、攻撃者がSQLインジェクションの脆弱性を悪用するためのエントリーポイントではありません。
これは高品質なコードの例ですか？残念ながら、そうではありません。引数をint(整数)からString値に変更するだけで、自由形式のユーザ入力でクエリを操作することができますが、数値ではできません。この変更（あるいはどこか他の場所からString sqlを無造作にコピー＆ペーストした場合）は、SQLインジェクションの脆弱性が可能な環境を即座に作り出し、それに伴うすべてのリスクが発生します。
このセキュリティ対策は非常に限られた範囲のものでしたが、より徹底した（あるいは経験豊富な）開発者であれば、非効率な引数構造の影響を考慮して別のアプローチをとったかもしれません。このようなコードを出荷することは不適切な行為であるだけでなく、開発グループの他のメンバーにとっても悪い手本となります。
ソフトウェアの「三重奏」。形、機能、要塞のようなもの？
エンターテインメント業界における「三拍子揃った人材」とは、演技、ダンス、歌を同じように高いレベルでこなす人のことです。彼らは、オーディションのたびに恐れられ、羨ましがられる存在であり、すでに競争が激化している業界のユニコーンともいえる存在です。どの業界にも、その業界の製品やサービスのトップレベルの例外的な例がありますが、ソフトウェアも例外ではありません。
アプリケーションにおいて、同等の（高い）品質とのバランスをとるのが難しい3つの要素を考えてみると、「機能性／優美さ」、「鉄壁のセキュリティ」、「要求される納品スピードを考慮したコスト効率」ではないでしょうか。さて、最後の属性は、他の2つの選択肢がどれだけ適用されるかを決定づける要因であることは間違いなく、時間の経過とともに全体的な品質が低下するきっかけにもなります。
しかし、すべてのソフトウェアはヒュー・ジャックマンのようなパフォーマンスが必要なのか、それともニコラス・ケイジでも良いのか。言い換えれば、ウルヴァリンをチームに迎え入れることができるなら、ベストショットを尽くすということです。
マーティン・ファウラーは、ソフトウェア開発において「高品質はコストに見合うか」という問いを投げかけ、「価値がある」だけでなく、時間が経てば経つほど実際に安くなると結論づけました。ほとんどのユーザーは、コードがめちゃくちゃになっていないか、セキュリティが他のものと同じように重要になっていないかを評価するために、ボンネットの中を見ようとはしません。しかし、ツール担当者は、新しい機能を追加するためにずさんなコードをやり直したり、何が起こっているのかを理解するためにプロジェクトの主要部分を調べたり、最悪の場合は、AppSecチームから跳ね返ってきた脆弱性を修正して生産を遅らせるなど、貴重な時間を浪費することになります。今、コードを安全で良質なものにするために時間を費やすことは、不完全に実行された作業を解明するためのコストは言うまでもなく、将来の多くの苦痛を避けることになります。
熟練したセキュリティ意識の高い開発者は、エンジニアがプロセスの各段階でコントロールできる一般的なセキュリティの落とし穴を取り除くことを考慮しながら、機能提供における創造的で問題解決のビジョンを維持するコードを書きます。セキュアなコードは、単独ではあまり効果的ではありません。だからこそ、「レフト・オブ・レフト」という考え方は、開発者にとってセキュリティが自然なことであり、リスクを抑えて素晴らしい機能を提供する能力に組み込まれているという文化を支えることになるのです。
ユーザーが安心して使用できるようにするためには、"left of left "から始めることが重要です。
ソフトウェアのユーザー体験において、セキュリティは長い間考慮されてきましたが、明らかに成功とは言えない結果となっています。過去1年間に発生したクラウドベースのデータ漏洩のうち、セキュリティの設定ミスは21％を占めており、パスワードを平文で保存するなどの素人的なミスにより、被害を受けた企業は生産性、収益、顧客の信頼を大きく失うことになりました。
また、自分のデータを保護することに関しては、ユーザー自身が最大の敵となる可能性があります。いまだにパスワードに「password」を使っていたり、複数の重要なアカウントで同じ組み合わせを使っている人があまりにも多いのです。
堅牢で機能的なセキュリティフローを設計し、ユーザーが納得して操作でき、かつ混乱を最小限に抑えるには、微妙なバランスが必要なのです。
あまりにも複雑な手順や制限を設けると、ユーザーが二度と戻ってこなくなる可能性があります（新しいアプリにとっては最悪です）。簡単すぎると、セキュリティの面で失敗することになります。
安全なユーザー体験を成功させるためには、しっかりとしたセキュリティを意味のある流れの中に織り込み、ソフトウェアの魅力を損なわないような方法で提示する必要があります。複雑なパスワードの要求、CAPTCHA、ミニボス、4種類のゾンビなど、あらゆる方法で安全なログイン機能をコーディングするという目的は確かに達成できますが、それがユーザーの反感を買うような混乱したものであれば、的外れと言わざるを得ません。
ソフトウェア・エクセレンスの基礎を築く。
私自身も開発者の一人ですが、大多数の人は自分の仕事に誇りを持ち、正しいことをしたいと思っています。しかし、多くのソフトウェアエンジニアは、成功するための環境が整っていないという厳しい現実があります。
レフト・オブ・レフト」は、開発者ファーストのコンセプトであり、組織はエンジニア集団のレベルアップに真剣に取り組む必要があります。セキュリティを意識した開発者は金に値する存在であり、トレーニングや適切なツールの提供、経験豊富な開発者から指導を受ける機会などのサポートを受けることで、ソフトウェアを次のレベルに引き上げるために必要な正確さと細部へのこだわりを持って、セキュリティを第一に考えたコードが作成される環境が醸成される。
自分の中のセキュアコーディングの火をつける準備はできていますか？ 挑戦する.
目次
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約するダウンロード始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
.png)
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
