AppSecツールが銀の弾丸であるならば、なぜ多くの企業がそれを採用しないのでしょうか？
この記事の一部分は SCマガジン.この記事は更新され、ここでシンジケートされています。
今日のセキュリティ専門家が直面している多くの難問の一つは、直面しているサイバーリスクに対処するためのソリューションのバランスを考えることです。ツールと人材の間で予算をどのように配分すべきか？既存の技術スタックにはどのようなツールが最適なのか？世の中には非常に多くの選択肢があり、簡単な答えはありません。間違った選択肢を選ぶと、後で時間と費用がかかります。
最近のレポートによると、アプリケーション・セキュリティ・ツール市場は、現在から2025年までの間に「爆発的な」成長が見込まれています。これは、アプリケーション・セキュリティ・ツールがDevSecOpsを成功させる上で重要な役割を果たしていることを示しており、また、潜在的なセキュリティ脆弱性を持つコードの量が増加している中で、業界の関連性が高まっていることを示しています。
しかし、ちょっと不思議な問題があります。全体の半数近くの企業が、脆弱なコードを出荷していることを知っている にもかかわらず、それを阻止するためにAppSecツールを多数使用しているのです。否定できない市場需要があり、急速に普及している製品であるにもかかわらず、このような状況はあまり意味がありません。なぜ多くの人が高度なセキュリティツールを購入したにもかかわらず、その結果を無視したり、まったく使用しなかったりするのでしょうか。それはまるで、海辺の家を買ったのに、森の中のテントで寝るようなものです。
AppSecツールが期待通りに活用されていない理由はいくつかありますが、それはツールやその機能の問題ではなく、それらがセキュリティプログラム全体とどのように統合されているかという点にあります。
ツールが多ければ問題が少ないというわけではありません。
企業がソフトウェア開発プロセスを進化させ、アジャイルからDevOps、そして聖なる涅槃であるDevSecOpsへと移行していく中で、複数のスキャナー、モニター、ファイアウォール、そしてあらゆる種類のAppSecツールを購入することは避けられません。多ければ多いほど良い」と思われるかもしれませんが、多くの場合、これはフランケンシュタインの怪物のような技術スタックになり、それが意味する予測不可能性をすべて含んでいます。
必要とされる作業の範囲に対して予算や専門家のリソースがますます限られている中で、混乱を元に戻し、最適なツールのパスを見つけようとするのは大変な作業です。多くの企業がコードの出荷を続けなければならないのも不思議ではありませんが、データやプライバシーに甚大なリスクをもたらすコードの出荷は、むしろ憂慮すべきことなのです。
スキャンツールが遅いため、リリースの俊敏性に影響を与える。
スピード感のあるセキュリティを実現することは、ソフトウェア開発においては白眉であり、実際のところ、組織にDevSecOpsを重視したアプローチを導入したとしても、私たちはまだその実現を目指しています。90年代には、細心の注意を払った手動のコードレビューがセキュリティの安全策として機能していたかもしれませんが、何千億行ものコードを作成している現在では、それはサッカーのピッチを爪切りで準備するのと同じくらい効果のある計画です。
スキャンツールは、潜在的な問題を発見するプロセスを自動化し、綿密なコードレビューの部分を代行してくれます。しかし問題は、CI/CDパイプラインがすべてのシリンダーを作動させている状況では、これらのツールはまだ遅く、すべての脆弱性を発見できるツールはありません。また、スキャン後にセキュリティチームに表示される結果には、いくつかの重大な問題があります。
- 偽陽性（および偽陰性）が多いです。
- 哀れなセキュリティ専門家は、実際のバグと幻のバグを選別するために、そこに座って手動でレビューしなければなりません。
- しばしば、コードがデプロイされる前に発見されるべきだった、あまりにも多くの一般的な脆弱性が明らかになっています。高額な費用をかけているセキュリティ専門家が、大きなセキュリティ問題から小さな問題に気を取られることを本当に望んでいるのでしょうか？
- スキャナーは見つけるだけで、直すことはありません。
サイバーセキュリティのベストプラクティスに基づいて最善を尽くし、時代の流れに合わせてプロセスの各段階にセキュリティを盛り込んでいる組織であっても、スキャナが主な保護手段であり、あまりにも多くの一般的なバグがあるためにチームが安全なコードを展開することができない場合、上記のプロセスは依然として破綻しています。ここで手を抜くと、たとえ一連のソリューションを購入したとしても、すべての潜在的なリスクをカバーすることはできないため、必要最低限のツールに頼ることになります。
技術者主導の自動化がコード品質の低下を招くこともある
スキャンとテストは、ファイアウォールや監視などの基本的な機能とともに、AppSecツールの自動化プロセスの負荷となっていますが、その他の一般的なツールは、時間の経過とともにハンズオンのセキュリティ基盤を不用意に損なってしまう可能性があります。
例えば、RASP（runtime application self-protection）技術は、コーディング速度を犠牲にすることなくセキュリティ態勢を強化するためによく適用されます。RASPは、アプリケーションのランタイム環境で動作し、悪意のあるコードの入力やリアルタイムの攻撃から保護し、奇妙な実行動作を警告します。
しかし、コードベースの潜在的な弱点に対するフェイルセーフと考えてしまうと、開発者は満足してしまう可能性があります。特に、新機能を市場に投入する際の納期がますます厳しくなる中では、開発者は自己満足に陥ってしまうかもしれません。開発者はわざわざ安全でないコーディングパターンを作ることはありませんが、特に自動化された保護機能を前提とした場合、機能の提供を優先してセキュリティが優先されることがよくあります。
ツールは失敗することがありますが（RASPの場合、誤検知を避けるためにモニタリング・モードで実行されることが多いですが、これは攻撃に対する防御ではなく可視性を提供するに過ぎません）、そのような事態が発生した場合、常に信頼できるのは高品質で安全なコードです。コードに触れるすべての役割においてセキュリティを意識することは、DevSecOpsの基本であり、開発者が安全なコードをトレーニングしたり、作成したりしないのは間違いです。安全なコードも安全でないコードも、書くのに必要な労力は同じです。本当のエネルギーを必要とするのは、安全なコードを書くための知識を得ることです。RASPの実装と最適化に費やす時間は、そもそもミスを犯さないように開発者をスキルアップさせることに使う方がはるかに有効です。
ツールと人のバランス：銀の弾丸ではありませんが、（今のところ）最も近い方法だと思っています。
DevSecOpsの主な理念は、セキュリティを共有の責任とすることであり、電力網からドアベルに至るまで、私たちの生活を支えるソフトウェアを作成している組織にとっては、より高いレベルの安全性を確保するために、全員を参加させる必要があります。
ツールですべてをまかなうことはできませんし、最も安い方法でもありません。最良の結果を得るためには、コードに触れるすべての人に関連するセキュリティ・トレーニングを優先し、開発チームがセキュリティを最優先に考えるように積極的に働きかけ、人が主導する積極的なセキュリティ文化を構築し、それをツール群がサポートすることが必要です。
時間の制約や手抜きなど、セキュリティ専門家が夜眠れなくなるような状況にあっても、開発者が一般的なセキュリティ上の欠陥を最初に導入しなければ、それらのツールは（それが使われているかどうかにかかわらず）リスク要因としてははるかに小さくなります。
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はゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
この記事の一部分は SCマガジン.この記事は更新され、ここでシンジケートされています。
今日のセキュリティ専門家が直面している多くの難問の一つは、直面しているサイバーリスクに対処するためのソリューションのバランスを考えることです。ツールと人材の間で予算をどのように配分すべきか？既存の技術スタックにはどのようなツールが最適なのか？世の中には非常に多くの選択肢があり、簡単な答えはありません。間違った選択肢を選ぶと、後で時間と費用がかかります。
最近のレポートによると、アプリケーション・セキュリティ・ツール市場は、現在から2025年までの間に「爆発的な」成長が見込まれています。これは、アプリケーション・セキュリティ・ツールがDevSecOpsを成功させる上で重要な役割を果たしていることを示しており、また、潜在的なセキュリティ脆弱性を持つコードの量が増加している中で、業界の関連性が高まっていることを示しています。
しかし、ちょっと不思議な問題があります。全体の半数近くの企業が、脆弱なコードを出荷していることを知っている にもかかわらず、それを阻止するためにAppSecツールを多数使用しているのです。否定できない市場需要があり、急速に普及している製品であるにもかかわらず、このような状況はあまり意味がありません。なぜ多くの人が高度なセキュリティツールを購入したにもかかわらず、その結果を無視したり、まったく使用しなかったりするのでしょうか。それはまるで、海辺の家を買ったのに、森の中のテントで寝るようなものです。
AppSecツールが期待通りに活用されていない理由はいくつかありますが、それはツールやその機能の問題ではなく、それらがセキュリティプログラム全体とどのように統合されているかという点にあります。
ツールが多ければ問題が少ないというわけではありません。
企業がソフトウェア開発プロセスを進化させ、アジャイルからDevOps、そして聖なる涅槃であるDevSecOpsへと移行していく中で、複数のスキャナー、モニター、ファイアウォール、そしてあらゆる種類のAppSecツールを購入することは避けられません。多ければ多いほど良い」と思われるかもしれませんが、多くの場合、これはフランケンシュタインの怪物のような技術スタックになり、それが意味する予測不可能性をすべて含んでいます。
必要とされる作業の範囲に対して予算や専門家のリソースがますます限られている中で、混乱を元に戻し、最適なツールのパスを見つけようとするのは大変な作業です。多くの企業がコードの出荷を続けなければならないのも不思議ではありませんが、データやプライバシーに甚大なリスクをもたらすコードの出荷は、むしろ憂慮すべきことなのです。
スキャンツールが遅いため、リリースの俊敏性に影響を与える。
スピード感のあるセキュリティを実現することは、ソフトウェア開発においては白眉であり、実際のところ、組織にDevSecOpsを重視したアプローチを導入したとしても、私たちはまだその実現を目指しています。90年代には、細心の注意を払った手動のコードレビューがセキュリティの安全策として機能していたかもしれませんが、何千億行ものコードを作成している現在では、それはサッカーのピッチを爪切りで準備するのと同じくらい効果のある計画です。
スキャンツールは、潜在的な問題を発見するプロセスを自動化し、綿密なコードレビューの部分を代行してくれます。しかし問題は、CI/CDパイプラインがすべてのシリンダーを作動させている状況では、これらのツールはまだ遅く、すべての脆弱性を発見できるツールはありません。また、スキャン後にセキュリティチームに表示される結果には、いくつかの重大な問題があります。
- 偽陽性（および偽陰性）が多いです。
- 哀れなセキュリティ専門家は、実際のバグと幻のバグを選別するために、そこに座って手動でレビューしなければなりません。
- しばしば、コードがデプロイされる前に発見されるべきだった、あまりにも多くの一般的な脆弱性が明らかになっています。高額な費用をかけているセキュリティ専門家が、大きなセキュリティ問題から小さな問題に気を取られることを本当に望んでいるのでしょうか？
- スキャナーは見つけるだけで、直すことはありません。
サイバーセキュリティのベストプラクティスに基づいて最善を尽くし、時代の流れに合わせてプロセスの各段階にセキュリティを盛り込んでいる組織であっても、スキャナが主な保護手段であり、あまりにも多くの一般的なバグがあるためにチームが安全なコードを展開することができない場合、上記のプロセスは依然として破綻しています。ここで手を抜くと、たとえ一連のソリューションを購入したとしても、すべての潜在的なリスクをカバーすることはできないため、必要最低限のツールに頼ることになります。
技術者主導の自動化がコード品質の低下を招くこともある
スキャンとテストは、ファイアウォールや監視などの基本的な機能とともに、AppSecツールの自動化プロセスの負荷となっていますが、その他の一般的なツールは、時間の経過とともにハンズオンのセキュリティ基盤を不用意に損なってしまう可能性があります。
例えば、RASP（runtime application self-protection）技術は、コーディング速度を犠牲にすることなくセキュリティ態勢を強化するためによく適用されます。RASPは、アプリケーションのランタイム環境で動作し、悪意のあるコードの入力やリアルタイムの攻撃から保護し、奇妙な実行動作を警告します。
しかし、コードベースの潜在的な弱点に対するフェイルセーフと考えてしまうと、開発者は満足してしまう可能性があります。特に、新機能を市場に投入する際の納期がますます厳しくなる中では、開発者は自己満足に陥ってしまうかもしれません。開発者はわざわざ安全でないコーディングパターンを作ることはありませんが、特に自動化された保護機能を前提とした場合、機能の提供を優先してセキュリティが優先されることがよくあります。
ツールは失敗することがありますが（RASPの場合、誤検知を避けるためにモニタリング・モードで実行されることが多いですが、これは攻撃に対する防御ではなく可視性を提供するに過ぎません）、そのような事態が発生した場合、常に信頼できるのは高品質で安全なコードです。コードに触れるすべての役割においてセキュリティを意識することは、DevSecOpsの基本であり、開発者が安全なコードをトレーニングしたり、作成したりしないのは間違いです。安全なコードも安全でないコードも、書くのに必要な労力は同じです。本当のエネルギーを必要とするのは、安全なコードを書くための知識を得ることです。RASPの実装と最適化に費やす時間は、そもそもミスを犯さないように開発者をスキルアップさせることに使う方がはるかに有効です。
ツールと人のバランス：銀の弾丸ではありませんが、（今のところ）最も近い方法だと思っています。
DevSecOpsの主な理念は、セキュリティを共有の責任とすることであり、電力網からドアベルに至るまで、私たちの生活を支えるソフトウェアを作成している組織にとっては、より高いレベルの安全性を確保するために、全員を参加させる必要があります。
ツールですべてをまかなうことはできませんし、最も安い方法でもありません。最良の結果を得るためには、コードに触れるすべての人に関連するセキュリティ・トレーニングを優先し、開発チームがセキュリティを最優先に考えるように積極的に働きかけ、人が主導する積極的なセキュリティ文化を構築し、それをツール群がサポートすることが必要です。
時間の制約や手抜きなど、セキュリティ専門家が夜眠れなくなるような状況にあっても、開発者が一般的なセキュリティ上の欠陥を最初に導入しなければ、それらのツールは（それが使われているかどうかにかかわらず）リスク要因としてははるかに小さくなります。
この記事の一部分は SCマガジン.この記事は更新され、ここでシンジケートされています。
今日のセキュリティ専門家が直面している多くの難問の一つは、直面しているサイバーリスクに対処するためのソリューションのバランスを考えることです。ツールと人材の間で予算をどのように配分すべきか？既存の技術スタックにはどのようなツールが最適なのか？世の中には非常に多くの選択肢があり、簡単な答えはありません。間違った選択肢を選ぶと、後で時間と費用がかかります。
最近のレポートによると、アプリケーション・セキュリティ・ツール市場は、現在から2025年までの間に「爆発的な」成長が見込まれています。これは、アプリケーション・セキュリティ・ツールがDevSecOpsを成功させる上で重要な役割を果たしていることを示しており、また、潜在的なセキュリティ脆弱性を持つコードの量が増加している中で、業界の関連性が高まっていることを示しています。
しかし、ちょっと不思議な問題があります。全体の半数近くの企業が、脆弱なコードを出荷していることを知っている にもかかわらず、それを阻止するためにAppSecツールを多数使用しているのです。否定できない市場需要があり、急速に普及している製品であるにもかかわらず、このような状況はあまり意味がありません。なぜ多くの人が高度なセキュリティツールを購入したにもかかわらず、その結果を無視したり、まったく使用しなかったりするのでしょうか。それはまるで、海辺の家を買ったのに、森の中のテントで寝るようなものです。
AppSecツールが期待通りに活用されていない理由はいくつかありますが、それはツールやその機能の問題ではなく、それらがセキュリティプログラム全体とどのように統合されているかという点にあります。
ツールが多ければ問題が少ないというわけではありません。
企業がソフトウェア開発プロセスを進化させ、アジャイルからDevOps、そして聖なる涅槃であるDevSecOpsへと移行していく中で、複数のスキャナー、モニター、ファイアウォール、そしてあらゆる種類のAppSecツールを購入することは避けられません。多ければ多いほど良い」と思われるかもしれませんが、多くの場合、これはフランケンシュタインの怪物のような技術スタックになり、それが意味する予測不可能性をすべて含んでいます。
必要とされる作業の範囲に対して予算や専門家のリソースがますます限られている中で、混乱を元に戻し、最適なツールのパスを見つけようとするのは大変な作業です。多くの企業がコードの出荷を続けなければならないのも不思議ではありませんが、データやプライバシーに甚大なリスクをもたらすコードの出荷は、むしろ憂慮すべきことなのです。
スキャンツールが遅いため、リリースの俊敏性に影響を与える。
スピード感のあるセキュリティを実現することは、ソフトウェア開発においては白眉であり、実際のところ、組織にDevSecOpsを重視したアプローチを導入したとしても、私たちはまだその実現を目指しています。90年代には、細心の注意を払った手動のコードレビューがセキュリティの安全策として機能していたかもしれませんが、何千億行ものコードを作成している現在では、それはサッカーのピッチを爪切りで準備するのと同じくらい効果のある計画です。
スキャンツールは、潜在的な問題を発見するプロセスを自動化し、綿密なコードレビューの部分を代行してくれます。しかし問題は、CI/CDパイプラインがすべてのシリンダーを作動させている状況では、これらのツールはまだ遅く、すべての脆弱性を発見できるツールはありません。また、スキャン後にセキュリティチームに表示される結果には、いくつかの重大な問題があります。
- 偽陽性（および偽陰性）が多いです。
- 哀れなセキュリティ専門家は、実際のバグと幻のバグを選別するために、そこに座って手動でレビューしなければなりません。
- しばしば、コードがデプロイされる前に発見されるべきだった、あまりにも多くの一般的な脆弱性が明らかになっています。高額な費用をかけているセキュリティ専門家が、大きなセキュリティ問題から小さな問題に気を取られることを本当に望んでいるのでしょうか？
- スキャナーは見つけるだけで、直すことはありません。
サイバーセキュリティのベストプラクティスに基づいて最善を尽くし、時代の流れに合わせてプロセスの各段階にセキュリティを盛り込んでいる組織であっても、スキャナが主な保護手段であり、あまりにも多くの一般的なバグがあるためにチームが安全なコードを展開することができない場合、上記のプロセスは依然として破綻しています。ここで手を抜くと、たとえ一連のソリューションを購入したとしても、すべての潜在的なリスクをカバーすることはできないため、必要最低限のツールに頼ることになります。
技術者主導の自動化がコード品質の低下を招くこともある
スキャンとテストは、ファイアウォールや監視などの基本的な機能とともに、AppSecツールの自動化プロセスの負荷となっていますが、その他の一般的なツールは、時間の経過とともにハンズオンのセキュリティ基盤を不用意に損なってしまう可能性があります。
例えば、RASP（runtime application self-protection）技術は、コーディング速度を犠牲にすることなくセキュリティ態勢を強化するためによく適用されます。RASPは、アプリケーションのランタイム環境で動作し、悪意のあるコードの入力やリアルタイムの攻撃から保護し、奇妙な実行動作を警告します。
しかし、コードベースの潜在的な弱点に対するフェイルセーフと考えてしまうと、開発者は満足してしまう可能性があります。特に、新機能を市場に投入する際の納期がますます厳しくなる中では、開発者は自己満足に陥ってしまうかもしれません。開発者はわざわざ安全でないコーディングパターンを作ることはありませんが、特に自動化された保護機能を前提とした場合、機能の提供を優先してセキュリティが優先されることがよくあります。
ツールは失敗することがありますが（RASPの場合、誤検知を避けるためにモニタリング・モードで実行されることが多いですが、これは攻撃に対する防御ではなく可視性を提供するに過ぎません）、そのような事態が発生した場合、常に信頼できるのは高品質で安全なコードです。コードに触れるすべての役割においてセキュリティを意識することは、DevSecOpsの基本であり、開発者が安全なコードをトレーニングしたり、作成したりしないのは間違いです。安全なコードも安全でないコードも、書くのに必要な労力は同じです。本当のエネルギーを必要とするのは、安全なコードを書くための知識を得ることです。RASPの実装と最適化に費やす時間は、そもそもミスを犯さないように開発者をスキルアップさせることに使う方がはるかに有効です。
ツールと人のバランス：銀の弾丸ではありませんが、（今のところ）最も近い方法だと思っています。
DevSecOpsの主な理念は、セキュリティを共有の責任とすることであり、電力網からドアベルに至るまで、私たちの生活を支えるソフトウェアを作成している組織にとっては、より高いレベルの安全性を確保するために、全員を参加させる必要があります。
ツールですべてをまかなうことはできませんし、最も安い方法でもありません。最良の結果を得るためには、コードに触れるすべての人に関連するセキュリティ・トレーニングを優先し、開発チームがセキュリティを最優先に考えるように積極的に働きかけ、人が主導する積極的なセキュリティ文化を構築し、それをツール群がサポートすることが必要です。
時間の制約や手抜きなど、セキュリティ専門家が夜眠れなくなるような状況にあっても、開発者が一般的なセキュリティ上の欠陥を最初に導入しなければ、それらのツールは（それが使われているかどうかにかかわらず）リスク要因としてははるかに小さくなります。
以下のリンクをクリックし、この資料の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はゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
この記事の一部分は SCマガジン.この記事は更新され、ここでシンジケートされています。
今日のセキュリティ専門家が直面している多くの難問の一つは、直面しているサイバーリスクに対処するためのソリューションのバランスを考えることです。ツールと人材の間で予算をどのように配分すべきか？既存の技術スタックにはどのようなツールが最適なのか？世の中には非常に多くの選択肢があり、簡単な答えはありません。間違った選択肢を選ぶと、後で時間と費用がかかります。
最近のレポートによると、アプリケーション・セキュリティ・ツール市場は、現在から2025年までの間に「爆発的な」成長が見込まれています。これは、アプリケーション・セキュリティ・ツールがDevSecOpsを成功させる上で重要な役割を果たしていることを示しており、また、潜在的なセキュリティ脆弱性を持つコードの量が増加している中で、業界の関連性が高まっていることを示しています。
しかし、ちょっと不思議な問題があります。全体の半数近くの企業が、脆弱なコードを出荷していることを知っている にもかかわらず、それを阻止するためにAppSecツールを多数使用しているのです。否定できない市場需要があり、急速に普及している製品であるにもかかわらず、このような状況はあまり意味がありません。なぜ多くの人が高度なセキュリティツールを購入したにもかかわらず、その結果を無視したり、まったく使用しなかったりするのでしょうか。それはまるで、海辺の家を買ったのに、森の中のテントで寝るようなものです。
AppSecツールが期待通りに活用されていない理由はいくつかありますが、それはツールやその機能の問題ではなく、それらがセキュリティプログラム全体とどのように統合されているかという点にあります。
ツールが多ければ問題が少ないというわけではありません。
企業がソフトウェア開発プロセスを進化させ、アジャイルからDevOps、そして聖なる涅槃であるDevSecOpsへと移行していく中で、複数のスキャナー、モニター、ファイアウォール、そしてあらゆる種類のAppSecツールを購入することは避けられません。多ければ多いほど良い」と思われるかもしれませんが、多くの場合、これはフランケンシュタインの怪物のような技術スタックになり、それが意味する予測不可能性をすべて含んでいます。
必要とされる作業の範囲に対して予算や専門家のリソースがますます限られている中で、混乱を元に戻し、最適なツールのパスを見つけようとするのは大変な作業です。多くの企業がコードの出荷を続けなければならないのも不思議ではありませんが、データやプライバシーに甚大なリスクをもたらすコードの出荷は、むしろ憂慮すべきことなのです。
スキャンツールが遅いため、リリースの俊敏性に影響を与える。
スピード感のあるセキュリティを実現することは、ソフトウェア開発においては白眉であり、実際のところ、組織にDevSecOpsを重視したアプローチを導入したとしても、私たちはまだその実現を目指しています。90年代には、細心の注意を払った手動のコードレビューがセキュリティの安全策として機能していたかもしれませんが、何千億行ものコードを作成している現在では、それはサッカーのピッチを爪切りで準備するのと同じくらい効果のある計画です。
スキャンツールは、潜在的な問題を発見するプロセスを自動化し、綿密なコードレビューの部分を代行してくれます。しかし問題は、CI/CDパイプラインがすべてのシリンダーを作動させている状況では、これらのツールはまだ遅く、すべての脆弱性を発見できるツールはありません。また、スキャン後にセキュリティチームに表示される結果には、いくつかの重大な問題があります。
- 偽陽性（および偽陰性）が多いです。
- 哀れなセキュリティ専門家は、実際のバグと幻のバグを選別するために、そこに座って手動でレビューしなければなりません。
- しばしば、コードがデプロイされる前に発見されるべきだった、あまりにも多くの一般的な脆弱性が明らかになっています。高額な費用をかけているセキュリティ専門家が、大きなセキュリティ問題から小さな問題に気を取られることを本当に望んでいるのでしょうか？
- スキャナーは見つけるだけで、直すことはありません。
サイバーセキュリティのベストプラクティスに基づいて最善を尽くし、時代の流れに合わせてプロセスの各段階にセキュリティを盛り込んでいる組織であっても、スキャナが主な保護手段であり、あまりにも多くの一般的なバグがあるためにチームが安全なコードを展開することができない場合、上記のプロセスは依然として破綻しています。ここで手を抜くと、たとえ一連のソリューションを購入したとしても、すべての潜在的なリスクをカバーすることはできないため、必要最低限のツールに頼ることになります。
技術者主導の自動化がコード品質の低下を招くこともある
スキャンとテストは、ファイアウォールや監視などの基本的な機能とともに、AppSecツールの自動化プロセスの負荷となっていますが、その他の一般的なツールは、時間の経過とともにハンズオンのセキュリティ基盤を不用意に損なってしまう可能性があります。
例えば、RASP（runtime application self-protection）技術は、コーディング速度を犠牲にすることなくセキュリティ態勢を強化するためによく適用されます。RASPは、アプリケーションのランタイム環境で動作し、悪意のあるコードの入力やリアルタイムの攻撃から保護し、奇妙な実行動作を警告します。
しかし、コードベースの潜在的な弱点に対するフェイルセーフと考えてしまうと、開発者は満足してしまう可能性があります。特に、新機能を市場に投入する際の納期がますます厳しくなる中では、開発者は自己満足に陥ってしまうかもしれません。開発者はわざわざ安全でないコーディングパターンを作ることはありませんが、特に自動化された保護機能を前提とした場合、機能の提供を優先してセキュリティが優先されることがよくあります。
ツールは失敗することがありますが（RASPの場合、誤検知を避けるためにモニタリング・モードで実行されることが多いですが、これは攻撃に対する防御ではなく可視性を提供するに過ぎません）、そのような事態が発生した場合、常に信頼できるのは高品質で安全なコードです。コードに触れるすべての役割においてセキュリティを意識することは、DevSecOpsの基本であり、開発者が安全なコードをトレーニングしたり、作成したりしないのは間違いです。安全なコードも安全でないコードも、書くのに必要な労力は同じです。本当のエネルギーを必要とするのは、安全なコードを書くための知識を得ることです。RASPの実装と最適化に費やす時間は、そもそもミスを犯さないように開発者をスキルアップさせることに使う方がはるかに有効です。
ツールと人のバランス：銀の弾丸ではありませんが、（今のところ）最も近い方法だと思っています。
DevSecOpsの主な理念は、セキュリティを共有の責任とすることであり、電力網からドアベルに至るまで、私たちの生活を支えるソフトウェアを作成している組織にとっては、より高いレベルの安全性を確保するために、全員を参加させる必要があります。
ツールですべてをまかなうことはできませんし、最も安い方法でもありません。最良の結果を得るためには、コードに触れるすべての人に関連するセキュリティ・トレーニングを優先し、開発チームがセキュリティを最優先に考えるように積極的に働きかけ、人が主導する積極的なセキュリティ文化を構築し、それをツール群がサポートすることが必要です。
時間の制約や手抜きなど、セキュリティ専門家が夜眠れなくなるような状況にあっても、開発者が一般的なセキュリティ上の欠陥を最初に導入しなければ、それらのツールは（それが使われているかどうかにかかわらず）リスク要因としてははるかに小さくなります。
目次
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約するダウンロード
.png)
