DevSecOpsへの恐怖と嫌悪

2つのコードアナライザー、4つの動的テスト用ツール、独自のクラフト、250のスクリプトがありました。 現在のプロセスでこれがすべて必要というわけではありませんが、DevSecOpsの実装を開始してから、最後まで行かなければなりません。







出所 キャラクター作者：ジャスティン・ロイランドとダン・ハーモン。



SecDevOpsとは何ですか？ DevSecOpsはどうですか？ 違いは何ですか？ アプリケーションセキュリティ-それは何ですか？ なぜ古典的なアプローチはもう機能しないのですか？ Swordfish Securityの Yury Shabalinは 、これらすべての質問に対する答えを知っています。 ユーリは、すべてに詳細に答え、従来のアプリケーションセキュリティモデルからDevSecOpsプロセスへの移行の問題を分析します。DevOpsプロセスに安全な開発プロセスを適切に埋め込み、同時に何も壊さない方法、セキュリティテストの主要段階を通過する方法、使用できるツール、それらは異なり、落とし穴を避けるためにそれらを正しく構成する方法です。





スピーカーについて： Yuri Shabalin- Swordfish Securityのチーフセキュリティアーキテクト。 彼は、SSDLの実装、アプリケーション分析ツールの単一の開発およびテストエコシステムへの一般的な統合を担当しています。 情報セキュリティの7年の経験。 彼は、Alfa Bank、Sberbank、およびソフトウェアの開発とサービスを提供するPositive Technologiesで働いていました。 国際会議ZerONights、PHDays、RISSPA、OWASPのスピーカー。

アプリケーションセキュリティ：それは何ですか？

アプリケーションセキュリティは、アプリケーションセキュリティを担当するセキュリティセクションです。 これは、インフラストラクチャやネットワークのセキュリティ、つまり、私たちが書いているものや開発者が取り組んでいるものには当てはまりません。これらは、アプリケーション自体の欠陥と脆弱性です。



SDLまたはSDLCの方向- セキュリティ開発ライフサイクル -はマイクロソフトによって開発されました。 この図は、標準のSDLCモデルを示しています。その主なタスクは、要件からリリース、実稼働へのリリースまで、開発のあらゆる段階でのセキュリティ参加です。 マイクロソフトは、プロムにバグが多すぎて、さらに多くのバグがあり、何かする必要があることに気づき、このアプローチを提案しました。







Application SecurityとSSDLは、一般に考えられているように脆弱性を検出することを目的とせず、脆弱性の発生を防ぐことを目的としています。 時間が経つにつれて、Microsoftの標準的なアプローチが改善、開発され、より深く詳細な没入感が現れました。







Canonical SDLCは、OpenSAMM、BSIMM、OWASPなどのさまざまな方法論で非常に詳細に記述されています。 方法論は異なりますが、一般的に似ています。

成熟モデルでのセキュリティの構築

私はBSIMMが最も 成熟したセキュリティモデルであるのが好きです 。 方法論の基礎は、アプリケーションセキュリティプロセスを4つのドメイン（ガバナンス、インテリジェンス、SSDLタッチポイント、展開）に分離することです。 各ドメインには12のプラクティスがあり、112のアクティビティとして表されています。







112の各アクティビティには、 3つの成熟度レベルがあります ：プライマリ、中級、上級。 12のプラクティスすべてをセクションで学習し、重要なものを選択し、それらの実装方法を理解し、静的および動的なコード分析やコードレビューなどの要素を徐々に追加できます。 選択したアクティビティの実装の一環として、計画をペイントし、冷静に作業します。

DevSecOpsを選ぶ理由

DevOpsは、セキュリティの面倒を見る必要がある一般的な大きなプロセスです。

最初、 DevOpsにはセキュリティチェックが含まれていました 。 実際には、セキュリティチームの数は現在よりもはるかに少なく、プロセスの参加者としてではなく、リリースの最後にそれを要求し、製品の品質をチェックする管理および監督機関として行動しました。 これは、セキュリティチームが開発の壁の後ろにいて、プロセスに関与していなかった古典的なアプローチです。







主な問題は、情報セキュリティが開発とは別個であることです。 通常、これはIB回路の一種であり、2〜3個の大型で高価なツールが含まれています。 6か月に1回、ソースコードまたはアプリケーションが到着しますので、チェックする必要があり、1年に1回ペンテストが作成されます。 これはすべて、プロムに入るための期限が延期され、自動化ツールからの膨大な数の脆弱性が開発者に落ちるという事実につながります。 過去6か月間の結果が整理されていないため、これをすべて分解および修復することはできませんが、ここに新しいバッチがあります。



弊社のプロセスでは、すべての分野と業界のセキュリティが、 アジャイルの 1つのホイールでの開発で自分自身を引き、スピンする時だと理解していることがわかります。 DevSecOpsパラダイムは、アジャイル開発方法論、実装、サポート、および各リリースとイテレーションへの参加にうまく適合します。

DevSecOpsへの移行

セキュリティ開発ライフサイクルで最も重要な言葉は「プロセス」です 。 ツールの購入を検討する前に、これを理解する必要があります。

DevOpsプロセスにツールを組み込むだけでは十分ではありません。プロセスの参加者間の相互作用と理解は重要です。

ツールよりも人よりも重要

多くの場合、安全な開発プロセスの計画はツールの選択と購入から始まり、ツールを現在のプロセスに統合しようとする試みで終わります。 すべてのツールには独自の特性と制限があるため、これは悲しい結果につながります。



セキュリティ部門が優れた機能を備えた優れた高価なツールを選択し、開発者に来てプロセスに組み込むという一般的なケース。 しかし、うまくいきません。プロセスは、すでに購入したツールの制限が現在のパラダイムに適合しないように構成されています。

最初に、希望する結果とプロセスの外観を説明します。 これは、プロセスにおけるツールの役割と安全性を理解するのに役立ちます。

すでに使用されているものから始めます。

高価なツールを購入する前に、すでに持っているものを見てください。 各会社には開発のための安全要件があり、チェック、ペンテストがあります-これをすべての人にとって理解しやすい便利な形に変えてみませんか？



通常、要件は紙のタルムードであり、棚の上にあります。 会社に来てプロセスを確認し、ソフトウェアのセキュリティ要件を示すように依頼する場合がありました。 これを行った専門家は長い間探していました。



-さて、メモのどこかに、この文書が存在する方法がありました。



その結果、1週間後にドキュメントを受け取りました。



要件、チェックなどについては、たとえばConfluenceでページを作成します-これは誰にとっても便利です。

すでにあるものを再フォーマットし、それを使用して開始する方が簡単です。

セキュリティチャンピオンを使用する

通常、100〜200人の開発者を抱える中規模の会社では、1人のセキュリティ担当者が働いており、複数の機能を実行し、物理的にすべてをチェックする時間はありません。 彼が最善を尽くしても、開発者が生成するすべてのコードをチェックするわけではありません。 そのような場合のために、コンセプトが開発されました-Security Champions 。

セキュリティチャンピオンは、製品のセキュリティに関心のある開発チーム内の人です。

セキュリティチャンピオンは開発チームへの入り口であり、セキュリティエバンジェリストはすべて1つになりました。



通常、金庫が開発チームに来て、コードにエラーがあることを示すと、驚きの答えを受け取ります。



「あなたは誰ですか？」 初めて会いましょう 私は元気です-コードレビューのシニアフレンドが私に「適用」するように設定しました。



これは典型的な状況です。なぜなら、開発者が仕事やコードレビューで絶えずやり取りしている先輩やチームメイトに多くの信頼があるからです。 セキュリティガードの代わりに、セキュリティチャンピオンがエラーと結果を示す場合、彼の言葉はより重要になります。



また、開発者はどのセキュリティプロバイダーよりもコードをよく知っています。 静的分析ツールに少なくとも5つのプロジェクトがある人にとって、すべてのニュアンスを覚えることは通常困難です。 セキュリティチャンピオンは自社の製品を知っています。つまり、何が何と相互作用し、何を見なければならないか-彼らはより効果的です。



そのため、セキュリティチャンピオンを実装し、セキュリティチームの影響力を拡大することを検討してください。 チャンピオン自身にとっても、これは有用です。新しい分野での専門能力開発、技術の視野の拡大、技術、管理、リーダーシップのスキルの向上、市場価値の向上。 これはソーシャルエンジニアリングの一部であり、開発チームの「目」です。

テスト手順

20から80のパラダイムでは、努力の20％が結果の80％を生み出します。 これらの20％は、自動化できるアプリケーションのプラクティスです。 そのようなアクティビティの例としては、静的分析-SAST 、動的分析-DAST、およびオープンソース管理があります。 アクティビティ、ツール、プロセスに導入されたときに通常遭遇する機能、およびそれを正しく行う方法について詳しく説明します。

ツールの主な問題

注意が必要なすべてのツールに関連する問題を強調します。 これ以上繰り返さないように、それらをより詳細に分析します。



長時間の分析。 コミットから製品に至るまでのすべてのテストとアセンブリを完了するのに30分かかる場合、情報セキュリティチェックには1日かかります。 したがって、誰もプロセスを遅くすることはありません。 この機能を検討し、結論を導き出します。



高い偽陰性または偽陽性。 すべての製品は異なり、誰もが異なるフレームワークと独自のスタイルのコードを使用しています。 さまざまなコードベースおよびテクノロジで、ツールはさまざまなレベルのFalse NegativeおよびFalse Positiveを表示できます。 したがって、企業内およびアプリケーションで何が正確かつ信頼できる結果をもたらすかを正確に確認してください 。



既存のツールとの統合はありません 。 すでに使用しているように、統合の観点からツールを見てください。 たとえば、JenkinsまたはTeamCityを使用している場合は、使用しないGitLab CIではなく、このソフトウェアとツールの統合を確認してください。



カスタマイズの欠如または過度の複雑さ。 ツールにAPIがない場合、なぜ必要なのですか？ インターフェイスでできることはすべて、APIを介してアクセスできる必要があります。 理想的には、ツールはチェックをカスタマイズできる必要があります。



ロードマップ製品開発はありません。 開発は止まることなく、常に新しいフレームワークと機能を使用し、古いコードを新しい言語に書き換えます。 購入するツールが新しいフレームワークとテクノロジーをサポートすることを確認したいと思います。 したがって、製品には実際の適切な開発ロードマップがあることを知っておくことが重要です。

プロセス機能

ツールの機能に加えて、開発プロセスの機能を検討してください。 たとえば、開発の妨害は典型的な間違いです。 他のどの機能を検討し、セキュリティチームが何に注意を払うべきかを見てみましょう。



開発日とリリース日を中断させないために、異なる環境に対して、 異なるルールと異なるショーストッパー （脆弱性が存在する場合にビルドプロセスを停止するための基準）を作成します 。 たとえば、現在のブランチは開発スタンドまたはUATに移動することを理解しているため、停止せず、次のように言っていません。



-あなたはここに脆弱性があります、あなたはそれ以上どこにも行かないでしょう！



この段階では、注意する価値のあるセキュリティの問題があることを開発者に伝えることが重要です。



脆弱性の存在は 、手動、統合、または手動のさらなるテストの障害にはなりません 。 一方、製品のセキュリティを何らかの方法で強化する必要があります。そのため、開発者が安全性を見つけることを忘れないようにします。 そのため、これを行うことがあります。スタンドでは、開発環境に展開するときに、開発に通知するだけです。



-皆さん、問題がありますので注意してください。



UATステージでは、脆弱性に関する警告を再度表示し、プロムの終了ステージでは次のように言います。



-みんな、私たちは何度も警告しました、あなたは何もしませんでした-私たちはあなたにこれを手放しません。



コードとダイナミクスについて話す場合、これらの機能の脆弱性とこの機能で作成されたばかりのコードについてのみ表示して警告する必要があります。 開発者がボタンを3ピクセル移動し、そこにSQLインジェクションがあり、緊急に修正する必要があることを伝えた場合、これは間違っています。 現在記述されている内容と、アプリケーションに生じる変更のみを確認してください。



特定の機能上の欠陥があると仮定します-アプリケーションが動作しない方法：お金が送金されない、ボタンをクリックすると、次のページに遷移しない、または製品がロードされない セキュリティの欠陥は同じ欠陥ですが、アプリケーションのコンテキストではなく、セキュリティです。

すべてのソフトウェア品質の問題がセキュリティの問題ではありません。 ただし、すべてのセキュリティ問題はソフトウェアの品質に関連しています。 シェリフマンスール、エクスペディア。

すべての脆弱性は同じ欠陥であるため、すべての開発欠陥と同じ場所に配置する必要があります。 だから誰も読まないレポートや怖いPDFを忘れてください。







開発会社で働いていたとき、静的分析ツールからレポートを受け取りました。 私はそれを開け、ぞっとさせ、コーヒーをbrewれ、350ページをめくって、閉じて作業を続けました。 大きなレポートは死んだレポートです。 通常、彼らはどこにも行かず、手紙は削除されたり、忘れられたり、紛失したりします。



どうする 確認した欠陥を開発に便利な形式に変換するだけです。たとえば、Jiraのバックログに追加します。 機能の欠陥とテストの欠陥とともに、優先順位の高い欠陥を優先して排除します。

静的分析-SAST

これは脆弱性のコード分析ですが、SonarQubeとは異なります。 パターンやスタイルだけではありません。 分析では、脆弱性ツリー、 DataFlow 、構成ファイルの分析など、多くのアプローチが使用されます。 これはすべてコードに直接関連しています。



アプローチの利点 ：スタンドおよび完成したツールがない開発の初期段階でコードの脆弱性を特定し、 インクリメンタルスキャンの可能性 ：変更されたコードのセクションをスキャンし、現在実行している機能のみをスキャンすることで、スキャン時間を短縮します。



短所 -これは、必要な言語のサポートの欠如です。



私の主観的な意見では、ツールに必要な統合 ：

• 統合ツール：Jenkins、TeamCity、およびGitlab CI。
  
  
• 開発環境：Intellij IDEA、Visual Studio。 開発者にとっては、覚えておく必要のあるわかりにくいインターフェースに登るのではなく、自分の開発環境の職場で、必要なすべての統合と脆弱性を確認する方が便利です。
  
  
• コードレビュー：SonarQubeおよび手動レビュー。
  
  
• 欠陥トラッカー：JiraおよびBugzilla。
  
  

写真は、静的解析の最良の代表のいくつかを示しています。







重要なのはツールではなくプロセスであるため、プロセスの実行にも適したオープンソースソリューションがあります。







SAST Open Sourceは、膨大な数の脆弱性や複雑なDataFlowを発見しませんが、プロセスを構築する際に使用することができ、使用する必要があります。 プロセスがどのように構築されるか、誰がバグに対応するか、誰が報告するか、誰が報告するかを理解するのに役立ちます。 コードのセキュリティを構築する初期段階を過ごしたい場合は、オープンソースソリューションを使用してください。



道の初めにいる場合、CI、Jenkins、TeamCityのいずれも何もない場合、これをどのように統合できますか？ プロセスへの統合を検討してください。

CVS統合

BitbucketまたはGitLabがある場合は、 Concurrent Versions Systemレベルで統合を行うことができます。



イベント別 -プルリクエスト、コミット。 コードをスキャンし、ビルドステータスでセキュリティチェックが成功または失敗したことを示します。



フィードバック。 もちろん、フィードバックは常に必要です。 単にセキュリティ側で実行した場合は、ボックスに入れて誰にも言わずに、月末に大量のバグをダンプしました。これは正しくも良くもありません。

コードレビューとの統合

一度、多くの重要なプロジェクトで、AppSec技術ユーザーのデフォルトのレビュー担当者を設定しました。 新しいコードでエラーが検出されたかどうか、またはエラーがないかどうかに応じて、レビュアーはプルリクエストのステータスを「受け入れる」または「作業が必要」にします-すべてが正常であるか、最終化するものを正確に絞り込んでリンクする必要があります。 製品版のバージョンと統合するために、IBテストが失敗した場合にマージ禁止をオンにしました。 これを手動のコードレビューに含め、プロセスの他の参加者はこの特定のプロセスのセキュリティステータスを確認しました。

SonarQubeとの統合

多くには、コード品質の品質ゲートがあります。 ここでも同じこと-SASTツールに対してのみ同じゲートを作成できます。 同じインターフェース、同じ品質ゲートがあり、それだけがセキュリティゲートと呼ばれます。 また、SonarQubeを使用するプロセスがある場合は、そこにすべてを簡単に統合できます。

CI統合

ここでも、すべてが非常に簡単です。

• autotestsと同じレベルで 、単体テスト。
  
  
• 開発の段階による分離 ： 開発 、テスト、製品。 さまざまなルールセットが含まれている場合や、さまざまな失敗条件（アセンブリを停止する、アセンブリを停止しない）が含まれる場合があります。
  
  
• 同期/非同期スタート 。 セキュリティテストの終了を待っているか、待っていません。 つまり、私たちはそれらを起動して先に進み、すべてが良いか悪いかのステータスを受け取ります。
  
  

すべてが完璧なピンクの世界にあります。 実際には、これはそうではありませんが、私たちは努力しています。 セキュリティチェックの結果は、単体テストの結果と類似している必要があります。



たとえば、大規模なプロジェクトを取り上げ、SAST'omでスキャンすることにしました-OK。 このプロジェクトをSASTに押し込み、20,000の脆弱性を与えました。そして、強い意志で、すべてが順調であることを受け入れました。 20,000の脆弱性は技術的な義務です。 借金を箱に入れて、ゆっくりとすくい取り、欠陥追跡システムでバグを開始します。 会社を雇って、自分でやるか、セキュリティのチャンピオンが助けてくれる-そして技術的な負債が減るだろう。



そして、新しいコードに新たに出現したすべての脆弱性と、ユニットまたは自動テストのエラーを修正する必要があります。 比較的言えば、アセンブリが開始され、追い出され、2つのテストと2つのセキュリティテストが落ちました。 OK-私たちは行って、何が起こったのかを見て、1つのことを修正し、2番目の問題を修正し、次回にそれを追い出しました-すべてが正常で、新しい脆弱性はなく、テストは失敗しませんでした このタスクがより深く、それをよく理解する必要がある場合、または脆弱性の修正が内部にあるものの大きなレイヤーに影響する場合：バグを欠陥トラッカーに持ち込んだ場合、それは優先順位が付けられて修正されます。 残念ながら、世界は完全ではなく、テストは時々失敗します。



セキュリティゲートの例は、コード内の脆弱性の存在と数による品質ゲートの類似物です。



SonarQubeと統合します-プラグインがインストールされ、すべてが非常に便利でクールです。

開発環境の統合

統合機能：

• コミット前に開発環境からスキャンを開始します。
  
  
• 結果を表示します。
  
  
• 結果の分析。
  
  
• サーバーとの同期。
  
  

サーバーから結果を取得するように見えます。







Intellij IDEA開発環境では、スキャン中にそのような脆弱性が検出されたことを報告する追加項目が表示されます。 コードをすぐに編集できます。推奨事項とフローグラフを参照してください。 これらはすべて開発者の職場にあり、非常に便利です。他のリンクにアクセスして余分なものを見る必要はありません。

オープンソース

これは私のお気に入りのトピックです。 誰もがオープンソースのライブラリを使用しています-すべてがすでに実装されている既製のライブラリを入手できるのに、なぜ松葉杖や自転車をたくさん書くのですか？







もちろん、これは事実ですが、ライブラリも人によって作成されており、特定のリスクも含まれています。また、定期的または絶えず報告される脆弱性もあります。 したがって、アプリケーションセキュリティの次のステップは、オープンソースコンポーネントの分析です。

オープンソース分析-OSA

このツールには3つの大きなステップが含まれています。



ライブラリの脆弱性を検索します。 たとえば、このツールは、ある種のライブラリを使用していること、およびこのバージョンのライブラリに関連するCVEまたはバグトラッカーに脆弱性があることを認識しています。 このツールを使用しようとすると、ツールはライブラリが脆弱であることを警告し、脆弱性のない別のバージョンを使用するようにアドバイスします。



認可された清潔さの分析。 これはまだあまり人気がありませんが、外国で働いている場合、使用または変更できないオープンソースコンポーネントを使用するためのATAを定期的に受け取ることができます。 ライセンスライブラリのポリシーによると、これを行うことはできません。 または、変更して使用する場合は、コードをレイアウトする必要があります。 もちろん、彼らの製品のコードをアップロードしたい人はいませんが、これからあなた自身を守ることもできます。



産業環境で使用されるコンポーネントの分析。 ようやく開発が完了し、マイクロサービスの最新の最新リリースをpromでリリースしたという仮想的な状況を想像してください。 彼はすばらしくそこに住んでいます-一週間、一ヶ月、一年。 私たちはそれを収集せず、セキュリティチェックも実施しません。すべてがうまくいくようです。 しかし、突然、リリースの2週間後に、このアセンブリで使用するオープンソースコンポーネントに産業環境で重大な脆弱性が発生します。 何をどこで使用するかを記録しないと、この脆弱性は見られません。 一部のツールには、現在プロムで使用されているライブラリの脆弱性を監視する機能があります。 これは非常に役立ちます。



機能：

• 開発のさまざまな段階のさまざまなポリシー。
  
  
• 産業環境での監視コンポーネント。
  
  
• 組織ループ内のライブラリ制御。
  
  
• さまざまなビルドシステムと言語のサポート。
  
  
• Dockerイメージの分析。
  
  

オープンソースを分析するエリアリーダーのいくつかの例。





唯一無料のものは、OWASPのDependency-Checkです。 最初の段階で有効にし、どのように機能し、何をサポートするかを確認できます。 基本的に、これらはすべてクラウド製品またはオンプレミスですが、その基盤の背後ではインターネットに送信されます。 ライブラリは送信しませんが、ハッシュまたはその値を計算し、サーバーにフィンガープリントして脆弱性のニュースを受信します。

プロセス統合

外部ソースからダウンロードされた境界ライブラリ 。 外部リポジトリと内部リポジトリがあります。 たとえば、NexusはEvent Central内にあり、リポジトリ内にステータスが「クリティカル」または「高」の脆弱性がないことを確認する必要があります。 Nexus Firewallライフサイクルツールを使用してプロキシを設定すると、このような脆弱性が遮断され、内部リポジトリに分類されなくなります。



CIでの統合 。 自動テスト、ユニットテスト、開発段階ごとの分離と同じレベル：dev、test、prod。 各段階で、任意のライブラリをダウンロードして、何でも使用できますが、ステータスが「クリティカル」で難しいものがある場合は可能です。プロムに入る段階でこれに注意する必要があります。



アーティファクトとの統合 ：NexusおよびJFrog。



開発環境への統合。 選択するツールには、開発環境との統合が必要です。 開発者は、職場のスキャン結果にアクセスするか、CVSにコミットする前にコードをスキャンして脆弱性をチェックする機能を持っている必要があります。



CDへの統合。 これは私が本当に気に入っており、すでにお話ししたクールな機能です。産業環境での新しい脆弱性の出現を監視します。 このように機能します。







パブリックコンポーネントリポジトリ -外部のツールと内部リポジトリがあります。 信頼できるコンポーネントのみが必要です。 リクエストをプロキシする場合、ダウンロードしたライブラリに脆弱性がないことを確認します。 私たちが確立し、開発と調整する必要がある特定のポリシーに該当する場合は、アップロードせず、別のバージョンを使用するようになります。 したがって、ライブラリに本当に重大で悪いものがある場合、開発者はインストール段階でライブラリを受け取りません。より高いバージョンまたはより低いバージョンを使用してください。

• ビルド中に、誰も悪いことをすべらないこと、すべてのコンポーネントが安全であること、およびフラッシュドライブに危険なものを持ち込まないことを確認します。
  
  
• リポジトリには、信頼できるコンポーネントのみがあります。
  
  
• デプロイするとき、パッケージ自体を再度チェックします：ポリシーと一致するwar、jar、DLまたはDocker-image。
  
  
• 産業に行くときは、産業環境で何が起こっているかを監視します。重大な脆弱性が現れるかどうかです。
  
  

動的分析-DAST

動的分析ツールは、前述のすべてのものと根本的に異なります。 これは、アプリケーションでのユーザーの作業を模倣したものです。 これがWebアプリケーションである場合、クライアントの動作をシミュレートするリクエストを送信し、前面のボタンをクリックし、フォームから人工データを送信します：引用符、括弧、異なるエンコーディングの文字、アプリケーションがどのように動作し、外部データを処理するかを確認します。



同じシステムを使用すると、オープンソースのパターンの脆弱性を確認できます。 DASTは、使用しているオープンソースを認識していないため、単に「悪意のある」パターンをスローし、サーバーの応答を分析します。



-うん、逆シリアル化の問題がありますが、ここではありません。



これには大きなリスクがあります。テスターが作業するのと同じスタンドでこのセキュリティテストを実施すると、不快なことが起こる可能性があるためです。

• ネットワーク\アプリケーションサーバーの高負荷。
  
  
• 統合なし。
  
  
• 分析されたアプリケーションの設定を変更する機能。
  
  
• 必要な技術に対するサポートはありません。
  
  
• 設定の複雑さ。
  
  

AppScanをようやく立ち上げたときの状況がありました。長い間、アプリケーションへのアクセスをノックアウトし、3つのアカウントを取得して喜んでいました。最後にすべてをチェックします。 スキャンを開始し、AppScanが最初に行ったのは、管理パネルに登り、すべてのボタンを押して、データの半分を変更してから、 メールフォームリクエストでサーバーを強制終了することでした。 テストによる開発は次のように述べています。



-みんな、冗談でしょ？ 私たちはあなたに記録を与えました、そしてあなたはスタンドを置きました！



起こりうるリスクを考慮してください。 理想的には、ISをテストするための別個のスタンドを準備します。これは、少なくとも何らかの形で環境の他の部分から隔離され、手動モードで管理パネルを条件付きで確認することをお勧めします。 これはペンテストです-現在検討していない努力の残りの割合。



これを負荷テストの類似物として使用できることを検討する価値があります。 最初の段階では、10〜15スレッドでダイナミックスキャナーをオンにして、何が起こるかを確認できますが、通常、実践が示すように、何も良いことはありません。



よく使用するいくつかのリソース。







Burp Suiteを強調する価値があります。これは、セキュリティの専門家にとっては「スイスナイフ」です。 誰もがそれを使用し、それは非常に便利です。 - enterprise edition. stand alone , - , . , .

: .



mock-, — , .

• — .
  
  
• .
  
  
• — .
  
  

プロセス

, . — , , OpenSource, - , , Waf .

.

, , , , -.



. , , . , , . , .







API, , , , — AppSec , .



, security- , , , , , . , , — Confluence , Jira -, / CI/CD.

Key Takeaways

. — . , , . — «» , — - high mega super critical, , .



— , . , , . DevSecOps, SecDevOps, .



, : , , , , . — . — .



.



, . , — . - , . , .



— Security Champions .



, , , - — . , . , community, , . , .



.

• False Positive.
  
  
• .
  
  
• .
  
  
• .
  
  
• Roadmap .
  
  
• .
  
  

DevOpsConf 2018. 27 28 DevOpsConf ++ . , , 21 .