信頼関係の構築AppSecと開発者の真のセキュリティシナジーへの道
この記事の一版は サイバーディフェンスマガジン.この記事は更新され、ここでシンジケートされています。
不信感という不安定な基盤の上に築かれた関係は、期待しないで臨むのが一番です。悲しいことに、組織内の開発者とAppSecチームの間には、このような関係が存在します。このような状況は理想的ではなく、リスクの高いテクノロジーへの依存度が高い世界では悪い結果をもたらします。
開発者は、問題を解決し、機能を構築し、創造性を発揮して仕事をします。一方、AppSecは、コードのセキュリティバグを発見し、修正を依頼し、監査やレポートを提供して、エンジニアのペットプロジェクトの輝きを失わせるという気の遠くなるような仕事をしています。セキュリティは開発者の優先事項でもなければ、KPIの一部でもないのですから、開発者だけに責任を負わせるのは公平ではありません。しかし、サイバーセキュリティのベストプラクティスや、組織レベルでのセキュリティの成果を向上させるためには、開発者が仲良くする必要があるのです。
そして、すべては信頼から始まります。
AppSecの「悪者」イメージがDevSecOpsの調和を阻んでいる。
もし、あなたが誰かと接するときに、その人があなたの間違った点を指摘していたとしたら、その人の意見は好意的に受け取られない可能性があります。
問題が発生しない限りめったに姿を現さないセキュリティチームの存在は、ネガティブな意味合いを持ち、摩擦の原因となりがちです。開発者は、AppSecチームを自分たちの創造性、プロセス、機能のタイムリーな出荷を妨げる存在と考え、一方、AppSecは、何十年も前から存在している（その対策も含めて）一般的なセキュリティバグを指摘し続けることに非常に疲弊しています。
ますます不可能になる締め切り、リソース不足のチーム、手戻りを避けたいという強い願望の中で、開発者はコードを出荷するために可能な限り最後の瞬間まで待つことが多くなり、AppSecのレビューと介入の機会の窓ができるだけ小さくなってしまいます。機能不全に陥ったプロセスは、組織のサイバーセキュリティ・リスクを増大させるという受け入れがたい影響をもたらします。
セキュリティの専門家にとっては、「メッセンジャーを撃つな」ということになります。結局のところ、彼らの仕事はバグを見つけて報告し、修正できるようにすることであり、個人的なものではありません。彼らの仕事は、バグを発見し、それを報告して修正することであり、個人的な問題ではありません。問題なのは、彼らはしばしば企業の技術スタックに最適ではない提案をすることがあり、社内のソフトウェア開発の大局的な観点からは、ほとんど役に立たないと見なされることです。
AppSecが悪役であるという考え方は、ほとんどの開発方法論にとっては直感に反するものですが、DevSecOpsにとっては最悪です。ゴールドスタンダードは、ウォーターフォール、アジャイル、さらにはDevOpsをはるかに超えて、SDLCの最初の段階からセキュリティを共有の責任として捉えるプロセスが不可欠となっています。
DevSecOpsを機能させるためには、ソフトウェア・エンジニアがセキュリティに関心を持つ理由を与える必要があります。その理由とは、世界のソフトウェアのセキュリティを確保するために自分の役割を果たすことがなぜそれほど重要なのかを理解することです。努力してオリーブの枝を伸ばし、開発マネージャと協力してチームのニーズを満たし、セキュリティ意識を育むための指導的役割を果たしたセキュリティ・スペシャリストは、その努力から長期的な利益を得る傾向があります。
開発者は、より安全なコーディングを行うことができるようになる必要があります。
多くのエンジニアにとって、高等教育の間に安全なコーディングを学ぶことは存在しません。それは、彼らがビールポンやWoWで遊ぶのに忙しかったからではなく、単にコンピュータサイエンスやITの学位の一部ではないからです。
そのため、開発者がソフトウェア・セキュリティの技術に触れる最初の機会はオン・ザ・ジョブ・トレーニングであることが多いのですが、それが開発者の心を揺さぶることはほとんどありません。何時間もの退屈なビデオが一般的なトレーニング方法であり、また、安全なコーディング方法を開発者に教えたり、組織のソフトウェアに存在する一般的な脆弱性を減少させたりする上で、実際に影響を与えるにはあまりにも頻度の低い「チェックボックス」のようなコンプライアンス演習もあります。
AppSecチームも開発コホートも非常に忙しいので、どんなトレーニングも意味があり、魅力的で、実践的なものでなければなりません。開発者の立場から言うと、私たちは問題を解決したり、ツールを使ったりするのが好きなので、静的なトレーニングの多くは、より差し迫った（あるいは正直に言うと、面白い）ことに集中している間に過ぎ去ってしまいます。
AppSec スペシャリストは影響力のある立場にあり、開発者の最善の利益を擁護することで、長期的なウィン・ウィンの状況を築くことができます。開発者が希望する言語やフレームワークで提供される、職務に関連した実行可能なトレーニングを求めることは、針を移動させ、組織内で草の根的に前向きなセキュリティ文化を鼓舞するための大きな一歩となります。何十年もの間、同じことを繰り返してきましたが、「一長一短」のトレーニング方法ではうまくいかないことは明らかです。適切なツールと知識を開発者に提供することで、開発者は安全なコーディングのスキルアップに成功し、高いセキュリティ意識を持って行動し、より高い水準のコードを作成することができます。
双方が歩み寄ることが必要です。
異なる目的を持った人たちが、お互いに誤解したり、最悪の場合は不信感を抱いてしまうこともあります。AppSecの目的は、大量に生み出されるコードに対応し、データの漏洩や不正アクセス、悪意のある攻撃につながるセキュリティ上の問題点を発見し、お客様の好感度を何年にもわたって低下させることです。
とりわけ開発者は、締め切りまでに機能を構築します。ソフトウェアを機能的に美しく仕上げ、お客様に愛されるユニークなデジタル体験を創造するのが開発者の仕事です。彼らはすでに多くのことをこなしていますが、その彼らにセキュリティの責任というカーブを投げかけることは、困難な見通しです。コードのセキュリティを確保するのはAppSecの問題だと考えられていますが、90年代（車がハッキングされたり、スマートフォンというポケットスーパーコンピュータに生活のすべてを入れて持ち歩いたりする前）にはそれがある程度実現できていましたが、今はコードが多すぎて、それをセキュリティの試練にかける人が足りません。
健全な共感を得て、ソフトウェア作成プロセスの初期段階からセキュリティを優先させることができれば、AppSecと開発者は互いの目標を一致させることができます。結局のところ、積極的なセキュリティ文化はそれに依存しており、セキュリティ意識の高い開発者は、サイバーセキュリティのスキル不足がますます深刻化している中で、一般的な脆弱性を阻止するための秘密の材料となります。
互いの時間を尊重することは、計り知れないメリットがあります。
先に述べたように、魔法（素晴らしいソフトウェア）を実現するためには、誰もが超多忙です。開発者は、安全なコーディングスキルを身につけるための実践的なトレーニングを行うために、仕事の時間を確保する必要があります。
AppSecは、OWASPトップ10の脆弱性を何度も修正することで時間を浪費し、開発者は、セキュリティは面倒なものだという考えを頭の中に植え付けるような、やる気の出ない練習で時間を削られています。
キュレーションされた学習体験は非常に重要であり、必要な時に必要なトレーニングを、文脈に沿って一口サイズで提供することで、本題に入ることができます。
望ましい成果と社内の学習経路に合わせてカスタムメイドのセキュアコーディングコースを作成することで、開発者の時間とワークフローを尊重すると同時に、企業の脆弱性とサイバーセキュリティのリスクを測定可能な形で削減することができます。ソフト面での対立に終止符を打ち、一丸となってサイバーセキュリティの荒野を前進するための迅速な勝利と言えるでしょう。
Secure Code Warriorの最新のコンテクスト・ラーニング機能です。 Coursesが登場しました。
不信感という不安定な基盤の上に築かれた関係は、あまり期待せずに臨むのが一番です。悲しいことに、これは組織内の開発者とAppSecチームの間の仕事上の関係の状態である可能性があります。
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はゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
この記事の一版は サイバーディフェンスマガジン.この記事は更新され、ここでシンジケートされています。
不信感という不安定な基盤の上に築かれた関係は、期待しないで臨むのが一番です。悲しいことに、組織内の開発者とAppSecチームの間には、このような関係が存在します。このような状況は理想的ではなく、リスクの高いテクノロジーへの依存度が高い世界では悪い結果をもたらします。
開発者は、問題を解決し、機能を構築し、創造性を発揮して仕事をします。一方、AppSecは、コードのセキュリティバグを発見し、修正を依頼し、監査やレポートを提供して、エンジニアのペットプロジェクトの輝きを失わせるという気の遠くなるような仕事をしています。セキュリティは開発者の優先事項でもなければ、KPIの一部でもないのですから、開発者だけに責任を負わせるのは公平ではありません。しかし、サイバーセキュリティのベストプラクティスや、組織レベルでのセキュリティの成果を向上させるためには、開発者が仲良くする必要があるのです。
そして、すべては信頼から始まります。
AppSecの「悪者」イメージがDevSecOpsの調和を阻んでいる。
もし、あなたが誰かと接するときに、その人があなたの間違った点を指摘していたとしたら、その人の意見は好意的に受け取られない可能性があります。
問題が発生しない限りめったに姿を現さないセキュリティチームの存在は、ネガティブな意味合いを持ち、摩擦の原因となりがちです。開発者は、AppSecチームを自分たちの創造性、プロセス、機能のタイムリーな出荷を妨げる存在と考え、一方、AppSecは、何十年も前から存在している（その対策も含めて）一般的なセキュリティバグを指摘し続けることに非常に疲弊しています。
ますます不可能になる締め切り、リソース不足のチーム、手戻りを避けたいという強い願望の中で、開発者はコードを出荷するために可能な限り最後の瞬間まで待つことが多くなり、AppSecのレビューと介入の機会の窓ができるだけ小さくなってしまいます。機能不全に陥ったプロセスは、組織のサイバーセキュリティ・リスクを増大させるという受け入れがたい影響をもたらします。
セキュリティの専門家にとっては、「メッセンジャーを撃つな」ということになります。結局のところ、彼らの仕事はバグを見つけて報告し、修正できるようにすることであり、個人的なものではありません。彼らの仕事は、バグを発見し、それを報告して修正することであり、個人的な問題ではありません。問題なのは、彼らはしばしば企業の技術スタックに最適ではない提案をすることがあり、社内のソフトウェア開発の大局的な観点からは、ほとんど役に立たないと見なされることです。
AppSecが悪役であるという考え方は、ほとんどの開発方法論にとっては直感に反するものですが、DevSecOpsにとっては最悪です。ゴールドスタンダードは、ウォーターフォール、アジャイル、さらにはDevOpsをはるかに超えて、SDLCの最初の段階からセキュリティを共有の責任として捉えるプロセスが不可欠となっています。
DevSecOpsを機能させるためには、ソフトウェア・エンジニアがセキュリティに関心を持つ理由を与える必要があります。その理由とは、世界のソフトウェアのセキュリティを確保するために自分の役割を果たすことがなぜそれほど重要なのかを理解することです。努力してオリーブの枝を伸ばし、開発マネージャと協力してチームのニーズを満たし、セキュリティ意識を育むための指導的役割を果たしたセキュリティ・スペシャリストは、その努力から長期的な利益を得る傾向があります。
開発者は、より安全なコーディングを行うことができるようになる必要があります。
多くのエンジニアにとって、高等教育の間に安全なコーディングを学ぶことは存在しません。それは、彼らがビールポンやWoWで遊ぶのに忙しかったからではなく、単にコンピュータサイエンスやITの学位の一部ではないからです。
そのため、開発者がソフトウェア・セキュリティの技術に触れる最初の機会はオン・ザ・ジョブ・トレーニングであることが多いのですが、それが開発者の心を揺さぶることはほとんどありません。何時間もの退屈なビデオが一般的なトレーニング方法であり、また、安全なコーディング方法を開発者に教えたり、組織のソフトウェアに存在する一般的な脆弱性を減少させたりする上で、実際に影響を与えるにはあまりにも頻度の低い「チェックボックス」のようなコンプライアンス演習もあります。
AppSecチームも開発コホートも非常に忙しいので、どんなトレーニングも意味があり、魅力的で、実践的なものでなければなりません。開発者の立場から言うと、私たちは問題を解決したり、ツールを使ったりするのが好きなので、静的なトレーニングの多くは、より差し迫った（あるいは正直に言うと、面白い）ことに集中している間に過ぎ去ってしまいます。
AppSec スペシャリストは影響力のある立場にあり、開発者の最善の利益を擁護することで、長期的なウィン・ウィンの状況を築くことができます。開発者が希望する言語やフレームワークで提供される、職務に関連した実行可能なトレーニングを求めることは、針を移動させ、組織内で草の根的に前向きなセキュリティ文化を鼓舞するための大きな一歩となります。何十年もの間、同じことを繰り返してきましたが、「一長一短」のトレーニング方法ではうまくいかないことは明らかです。適切なツールと知識を開発者に提供することで、開発者は安全なコーディングのスキルアップに成功し、高いセキュリティ意識を持って行動し、より高い水準のコードを作成することができます。
双方が歩み寄ることが必要です。
異なる目的を持った人たちが、お互いに誤解したり、最悪の場合は不信感を抱いてしまうこともあります。AppSecの目的は、大量に生み出されるコードに対応し、データの漏洩や不正アクセス、悪意のある攻撃につながるセキュリティ上の問題点を発見し、お客様の好感度を何年にもわたって低下させることです。
とりわけ開発者は、締め切りまでに機能を構築します。ソフトウェアを機能的に美しく仕上げ、お客様に愛されるユニークなデジタル体験を創造するのが開発者の仕事です。彼らはすでに多くのことをこなしていますが、その彼らにセキュリティの責任というカーブを投げかけることは、困難な見通しです。コードのセキュリティを確保するのはAppSecの問題だと考えられていますが、90年代（車がハッキングされたり、スマートフォンというポケットスーパーコンピュータに生活のすべてを入れて持ち歩いたりする前）にはそれがある程度実現できていましたが、今はコードが多すぎて、それをセキュリティの試練にかける人が足りません。
健全な共感を得て、ソフトウェア作成プロセスの初期段階からセキュリティを優先させることができれば、AppSecと開発者は互いの目標を一致させることができます。結局のところ、積極的なセキュリティ文化はそれに依存しており、セキュリティ意識の高い開発者は、サイバーセキュリティのスキル不足がますます深刻化している中で、一般的な脆弱性を阻止するための秘密の材料となります。
互いの時間を尊重することは、計り知れないメリットがあります。
先に述べたように、魔法（素晴らしいソフトウェア）を実現するためには、誰もが超多忙です。開発者は、安全なコーディングスキルを身につけるための実践的なトレーニングを行うために、仕事の時間を確保する必要があります。
AppSecは、OWASPトップ10の脆弱性を何度も修正することで時間を浪費し、開発者は、セキュリティは面倒なものだという考えを頭の中に植え付けるような、やる気の出ない練習で時間を削られています。
キュレーションされた学習体験は非常に重要であり、必要な時に必要なトレーニングを、文脈に沿って一口サイズで提供することで、本題に入ることができます。
望ましい成果と社内の学習経路に合わせてカスタムメイドのセキュアコーディングコースを作成することで、開発者の時間とワークフローを尊重すると同時に、企業の脆弱性とサイバーセキュリティのリスクを測定可能な形で削減することができます。ソフト面での対立に終止符を打ち、一丸となってサイバーセキュリティの荒野を前進するための迅速な勝利と言えるでしょう。
Secure Code Warriorの最新のコンテクスト・ラーニング機能です。 Coursesが登場しました。
この記事の一版は サイバーディフェンスマガジン.この記事は更新され、ここでシンジケートされています。
不信感という不安定な基盤の上に築かれた関係は、期待しないで臨むのが一番です。悲しいことに、組織内の開発者とAppSecチームの間には、このような関係が存在します。このような状況は理想的ではなく、リスクの高いテクノロジーへの依存度が高い世界では悪い結果をもたらします。
開発者は、問題を解決し、機能を構築し、創造性を発揮して仕事をします。一方、AppSecは、コードのセキュリティバグを発見し、修正を依頼し、監査やレポートを提供して、エンジニアのペットプロジェクトの輝きを失わせるという気の遠くなるような仕事をしています。セキュリティは開発者の優先事項でもなければ、KPIの一部でもないのですから、開発者だけに責任を負わせるのは公平ではありません。しかし、サイバーセキュリティのベストプラクティスや、組織レベルでのセキュリティの成果を向上させるためには、開発者が仲良くする必要があるのです。
そして、すべては信頼から始まります。
AppSecの「悪者」イメージがDevSecOpsの調和を阻んでいる。
もし、あなたが誰かと接するときに、その人があなたの間違った点を指摘していたとしたら、その人の意見は好意的に受け取られない可能性があります。
問題が発生しない限りめったに姿を現さないセキュリティチームの存在は、ネガティブな意味合いを持ち、摩擦の原因となりがちです。開発者は、AppSecチームを自分たちの創造性、プロセス、機能のタイムリーな出荷を妨げる存在と考え、一方、AppSecは、何十年も前から存在している（その対策も含めて）一般的なセキュリティバグを指摘し続けることに非常に疲弊しています。
ますます不可能になる締め切り、リソース不足のチーム、手戻りを避けたいという強い願望の中で、開発者はコードを出荷するために可能な限り最後の瞬間まで待つことが多くなり、AppSecのレビューと介入の機会の窓ができるだけ小さくなってしまいます。機能不全に陥ったプロセスは、組織のサイバーセキュリティ・リスクを増大させるという受け入れがたい影響をもたらします。
セキュリティの専門家にとっては、「メッセンジャーを撃つな」ということになります。結局のところ、彼らの仕事はバグを見つけて報告し、修正できるようにすることであり、個人的なものではありません。彼らの仕事は、バグを発見し、それを報告して修正することであり、個人的な問題ではありません。問題なのは、彼らはしばしば企業の技術スタックに最適ではない提案をすることがあり、社内のソフトウェア開発の大局的な観点からは、ほとんど役に立たないと見なされることです。
AppSecが悪役であるという考え方は、ほとんどの開発方法論にとっては直感に反するものですが、DevSecOpsにとっては最悪です。ゴールドスタンダードは、ウォーターフォール、アジャイル、さらにはDevOpsをはるかに超えて、SDLCの最初の段階からセキュリティを共有の責任として捉えるプロセスが不可欠となっています。
DevSecOpsを機能させるためには、ソフトウェア・エンジニアがセキュリティに関心を持つ理由を与える必要があります。その理由とは、世界のソフトウェアのセキュリティを確保するために自分の役割を果たすことがなぜそれほど重要なのかを理解することです。努力してオリーブの枝を伸ばし、開発マネージャと協力してチームのニーズを満たし、セキュリティ意識を育むための指導的役割を果たしたセキュリティ・スペシャリストは、その努力から長期的な利益を得る傾向があります。
開発者は、より安全なコーディングを行うことができるようになる必要があります。
多くのエンジニアにとって、高等教育の間に安全なコーディングを学ぶことは存在しません。それは、彼らがビールポンやWoWで遊ぶのに忙しかったからではなく、単にコンピュータサイエンスやITの学位の一部ではないからです。
そのため、開発者がソフトウェア・セキュリティの技術に触れる最初の機会はオン・ザ・ジョブ・トレーニングであることが多いのですが、それが開発者の心を揺さぶることはほとんどありません。何時間もの退屈なビデオが一般的なトレーニング方法であり、また、安全なコーディング方法を開発者に教えたり、組織のソフトウェアに存在する一般的な脆弱性を減少させたりする上で、実際に影響を与えるにはあまりにも頻度の低い「チェックボックス」のようなコンプライアンス演習もあります。
AppSecチームも開発コホートも非常に忙しいので、どんなトレーニングも意味があり、魅力的で、実践的なものでなければなりません。開発者の立場から言うと、私たちは問題を解決したり、ツールを使ったりするのが好きなので、静的なトレーニングの多くは、より差し迫った（あるいは正直に言うと、面白い）ことに集中している間に過ぎ去ってしまいます。
AppSec スペシャリストは影響力のある立場にあり、開発者の最善の利益を擁護することで、長期的なウィン・ウィンの状況を築くことができます。開発者が希望する言語やフレームワークで提供される、職務に関連した実行可能なトレーニングを求めることは、針を移動させ、組織内で草の根的に前向きなセキュリティ文化を鼓舞するための大きな一歩となります。何十年もの間、同じことを繰り返してきましたが、「一長一短」のトレーニング方法ではうまくいかないことは明らかです。適切なツールと知識を開発者に提供することで、開発者は安全なコーディングのスキルアップに成功し、高いセキュリティ意識を持って行動し、より高い水準のコードを作成することができます。
双方が歩み寄ることが必要です。
異なる目的を持った人たちが、お互いに誤解したり、最悪の場合は不信感を抱いてしまうこともあります。AppSecの目的は、大量に生み出されるコードに対応し、データの漏洩や不正アクセス、悪意のある攻撃につながるセキュリティ上の問題点を発見し、お客様の好感度を何年にもわたって低下させることです。
とりわけ開発者は、締め切りまでに機能を構築します。ソフトウェアを機能的に美しく仕上げ、お客様に愛されるユニークなデジタル体験を創造するのが開発者の仕事です。彼らはすでに多くのことをこなしていますが、その彼らにセキュリティの責任というカーブを投げかけることは、困難な見通しです。コードのセキュリティを確保するのはAppSecの問題だと考えられていますが、90年代（車がハッキングされたり、スマートフォンというポケットスーパーコンピュータに生活のすべてを入れて持ち歩いたりする前）にはそれがある程度実現できていましたが、今はコードが多すぎて、それをセキュリティの試練にかける人が足りません。
健全な共感を得て、ソフトウェア作成プロセスの初期段階からセキュリティを優先させることができれば、AppSecと開発者は互いの目標を一致させることができます。結局のところ、積極的なセキュリティ文化はそれに依存しており、セキュリティ意識の高い開発者は、サイバーセキュリティのスキル不足がますます深刻化している中で、一般的な脆弱性を阻止するための秘密の材料となります。
互いの時間を尊重することは、計り知れないメリットがあります。
先に述べたように、魔法（素晴らしいソフトウェア）を実現するためには、誰もが超多忙です。開発者は、安全なコーディングスキルを身につけるための実践的なトレーニングを行うために、仕事の時間を確保する必要があります。
AppSecは、OWASPトップ10の脆弱性を何度も修正することで時間を浪費し、開発者は、セキュリティは面倒なものだという考えを頭の中に植え付けるような、やる気の出ない練習で時間を削られています。
キュレーションされた学習体験は非常に重要であり、必要な時に必要なトレーニングを、文脈に沿って一口サイズで提供することで、本題に入ることができます。
望ましい成果と社内の学習経路に合わせてカスタムメイドのセキュアコーディングコースを作成することで、開発者の時間とワークフローを尊重すると同時に、企業の脆弱性とサイバーセキュリティのリスクを測定可能な形で削減することができます。ソフト面での対立に終止符を打ち、一丸となってサイバーセキュリティの荒野を前進するための迅速な勝利と言えるでしょう。
Secure Code Warriorの最新のコンテクスト・ラーニング機能です。 Coursesが登場しました。
以下のリンクをクリックし、この資料の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はゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
この記事の一版は サイバーディフェンスマガジン.この記事は更新され、ここでシンジケートされています。
不信感という不安定な基盤の上に築かれた関係は、期待しないで臨むのが一番です。悲しいことに、組織内の開発者とAppSecチームの間には、このような関係が存在します。このような状況は理想的ではなく、リスクの高いテクノロジーへの依存度が高い世界では悪い結果をもたらします。
開発者は、問題を解決し、機能を構築し、創造性を発揮して仕事をします。一方、AppSecは、コードのセキュリティバグを発見し、修正を依頼し、監査やレポートを提供して、エンジニアのペットプロジェクトの輝きを失わせるという気の遠くなるような仕事をしています。セキュリティは開発者の優先事項でもなければ、KPIの一部でもないのですから、開発者だけに責任を負わせるのは公平ではありません。しかし、サイバーセキュリティのベストプラクティスや、組織レベルでのセキュリティの成果を向上させるためには、開発者が仲良くする必要があるのです。
そして、すべては信頼から始まります。
AppSecの「悪者」イメージがDevSecOpsの調和を阻んでいる。
もし、あなたが誰かと接するときに、その人があなたの間違った点を指摘していたとしたら、その人の意見は好意的に受け取られない可能性があります。
問題が発生しない限りめったに姿を現さないセキュリティチームの存在は、ネガティブな意味合いを持ち、摩擦の原因となりがちです。開発者は、AppSecチームを自分たちの創造性、プロセス、機能のタイムリーな出荷を妨げる存在と考え、一方、AppSecは、何十年も前から存在している（その対策も含めて）一般的なセキュリティバグを指摘し続けることに非常に疲弊しています。
ますます不可能になる締め切り、リソース不足のチーム、手戻りを避けたいという強い願望の中で、開発者はコードを出荷するために可能な限り最後の瞬間まで待つことが多くなり、AppSecのレビューと介入の機会の窓ができるだけ小さくなってしまいます。機能不全に陥ったプロセスは、組織のサイバーセキュリティ・リスクを増大させるという受け入れがたい影響をもたらします。
セキュリティの専門家にとっては、「メッセンジャーを撃つな」ということになります。結局のところ、彼らの仕事はバグを見つけて報告し、修正できるようにすることであり、個人的なものではありません。彼らの仕事は、バグを発見し、それを報告して修正することであり、個人的な問題ではありません。問題なのは、彼らはしばしば企業の技術スタックに最適ではない提案をすることがあり、社内のソフトウェア開発の大局的な観点からは、ほとんど役に立たないと見なされることです。
AppSecが悪役であるという考え方は、ほとんどの開発方法論にとっては直感に反するものですが、DevSecOpsにとっては最悪です。ゴールドスタンダードは、ウォーターフォール、アジャイル、さらにはDevOpsをはるかに超えて、SDLCの最初の段階からセキュリティを共有の責任として捉えるプロセスが不可欠となっています。
DevSecOpsを機能させるためには、ソフトウェア・エンジニアがセキュリティに関心を持つ理由を与える必要があります。その理由とは、世界のソフトウェアのセキュリティを確保するために自分の役割を果たすことがなぜそれほど重要なのかを理解することです。努力してオリーブの枝を伸ばし、開発マネージャと協力してチームのニーズを満たし、セキュリティ意識を育むための指導的役割を果たしたセキュリティ・スペシャリストは、その努力から長期的な利益を得る傾向があります。
開発者は、より安全なコーディングを行うことができるようになる必要があります。
多くのエンジニアにとって、高等教育の間に安全なコーディングを学ぶことは存在しません。それは、彼らがビールポンやWoWで遊ぶのに忙しかったからではなく、単にコンピュータサイエンスやITの学位の一部ではないからです。
そのため、開発者がソフトウェア・セキュリティの技術に触れる最初の機会はオン・ザ・ジョブ・トレーニングであることが多いのですが、それが開発者の心を揺さぶることはほとんどありません。何時間もの退屈なビデオが一般的なトレーニング方法であり、また、安全なコーディング方法を開発者に教えたり、組織のソフトウェアに存在する一般的な脆弱性を減少させたりする上で、実際に影響を与えるにはあまりにも頻度の低い「チェックボックス」のようなコンプライアンス演習もあります。
AppSecチームも開発コホートも非常に忙しいので、どんなトレーニングも意味があり、魅力的で、実践的なものでなければなりません。開発者の立場から言うと、私たちは問題を解決したり、ツールを使ったりするのが好きなので、静的なトレーニングの多くは、より差し迫った（あるいは正直に言うと、面白い）ことに集中している間に過ぎ去ってしまいます。
AppSec スペシャリストは影響力のある立場にあり、開発者の最善の利益を擁護することで、長期的なウィン・ウィンの状況を築くことができます。開発者が希望する言語やフレームワークで提供される、職務に関連した実行可能なトレーニングを求めることは、針を移動させ、組織内で草の根的に前向きなセキュリティ文化を鼓舞するための大きな一歩となります。何十年もの間、同じことを繰り返してきましたが、「一長一短」のトレーニング方法ではうまくいかないことは明らかです。適切なツールと知識を開発者に提供することで、開発者は安全なコーディングのスキルアップに成功し、高いセキュリティ意識を持って行動し、より高い水準のコードを作成することができます。
双方が歩み寄ることが必要です。
異なる目的を持った人たちが、お互いに誤解したり、最悪の場合は不信感を抱いてしまうこともあります。AppSecの目的は、大量に生み出されるコードに対応し、データの漏洩や不正アクセス、悪意のある攻撃につながるセキュリティ上の問題点を発見し、お客様の好感度を何年にもわたって低下させることです。
とりわけ開発者は、締め切りまでに機能を構築します。ソフトウェアを機能的に美しく仕上げ、お客様に愛されるユニークなデジタル体験を創造するのが開発者の仕事です。彼らはすでに多くのことをこなしていますが、その彼らにセキュリティの責任というカーブを投げかけることは、困難な見通しです。コードのセキュリティを確保するのはAppSecの問題だと考えられていますが、90年代（車がハッキングされたり、スマートフォンというポケットスーパーコンピュータに生活のすべてを入れて持ち歩いたりする前）にはそれがある程度実現できていましたが、今はコードが多すぎて、それをセキュリティの試練にかける人が足りません。
健全な共感を得て、ソフトウェア作成プロセスの初期段階からセキュリティを優先させることができれば、AppSecと開発者は互いの目標を一致させることができます。結局のところ、積極的なセキュリティ文化はそれに依存しており、セキュリティ意識の高い開発者は、サイバーセキュリティのスキル不足がますます深刻化している中で、一般的な脆弱性を阻止するための秘密の材料となります。
互いの時間を尊重することは、計り知れないメリットがあります。
先に述べたように、魔法（素晴らしいソフトウェア）を実現するためには、誰もが超多忙です。開発者は、安全なコーディングスキルを身につけるための実践的なトレーニングを行うために、仕事の時間を確保する必要があります。
AppSecは、OWASPトップ10の脆弱性を何度も修正することで時間を浪費し、開発者は、セキュリティは面倒なものだという考えを頭の中に植え付けるような、やる気の出ない練習で時間を削られています。
キュレーションされた学習体験は非常に重要であり、必要な時に必要なトレーニングを、文脈に沿って一口サイズで提供することで、本題に入ることができます。
望ましい成果と社内の学習経路に合わせてカスタムメイドのセキュアコーディングコースを作成することで、開発者の時間とワークフローを尊重すると同時に、企業の脆弱性とサイバーセキュリティのリスクを測定可能な形で削減することができます。ソフト面での対立に終止符を打ち、一丸となってサイバーセキュリティの荒野を前進するための迅速な勝利と言えるでしょう。
Secure Code Warriorの最新のコンテクスト・ラーニング機能です。 Coursesが登場しました。
目次
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.