信頼関係の構築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が登場しました。
マティアス・マドゥ博士
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
信頼関係の構築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が登場しました。
