💮 😉 💳 QIWIセキュリティ開発ライフサイクル 🏵️ 👨🏾‍🏭 👎

ほぼすべてのフィンテック企業の生活のある時点で、内部開発アプリケーションの数が開発者の数を超え始め、ビジネスはより多くの新機能を必要とし、ますます多くの脆弱性がBug Bountyに引き継がれ続けます...

ただし、同時に、高品質で安全なソフトウェアを迅速にリリースする必要があり、バージョンロールバックや夜間の修正プログラムで特定されたセキュリティエラーによる火災を消す必要はありません。

情報セキュリティチームが数人で構成されている場合、これが常に当てはまるように見えますが、状況から最大限に絞り、アプリケーションのすべての「秘密」を決定することにしました。

どこから始めますか？私たちの計画はシンプルでした：

開発の車輪にとらわれることなく、タスクの設定、実行、リリースのプロセスを合理化します。
ファッショナブルなセキュリティスキャナーをねじ込みます。
数十のアプリケーションを確認します。
椅子に寄りかかって、それがすべて単独でどのように機能するかを見てください。

プロセス

ソフトウェア開発ライフサイクル開発プロセステンプレートは長い間書かれてきましたが、GOSTやISOもあります。しかし、数年前にわが国で「安全な」開発を構築するためのテンプレートについてはほとんど聞いていませんでした。

最初は、Microsoftが安全な開発のアイデアのエンジンでした。 redmodの巨人の用語では、 セキュリティ開発ライフサイクルは、特定の設計およびソフトウェア開発ルールに従って、開発者が最小限の時間でより安全なアプリケーションを構築できるようにするプロセスです。

これに来る方法一般的な概念では、SDLCは、たとえばMicrosoftのような、プロセスの閉ループです。私たち自身のために、このようなプロセスステップを特定しました：

最初は、このテンプレートのいくつかのポイントを既存の開発サイクルに追加する必要があるようにタスクが見えました。

つまり、長年にわたって確立されたサイクルがあり、そのサイクルに従って、部門（ビジネス、分析）の1つから来たタスクが開発者に落ち、テストされました。機能的なバグを明らかにした場合、開発に戻り、管理者に渡され、最終的に戦いになりました。

QSDLCの開始時には、次のものがありました。

開発者向けの年次トレーニング。
バージョンをロールバックする機能を備えたビルドシステムおよび確立された展開システム。
可能な限り-リリースで公開されているアプリケーションをテストします。
HackerOneでのプログラム。

したがって、パターンに従って、3つの重要なポイントをカバーしました。

少数のリリースでは、これらの手順で十分です。しかし、この場合、タスク設定プロセスを改良し、セキュリティテストを自動化する必要がありました。

問題の記述と設計

一部のセキュリティエラーは、アプリケーション設計の初期段階で修正できます。基本的に欠陥のある論理スキームまたは信頼性の低いメカニズムの導入により発生する可能性があります。

私たち自身のために、タスクの情報セキュリティ分析が必要な主なポイントを特定しました。

サードパーティのサービス、パートナー/クライアントとのデータ交換、
サードパーティのコード、システムへの実装、
サービスのプライバシーレベルを下げる、
ユーザーの個人データを操作し、
基本ではないサービス/機能システムの新しい。

この段階のコストは小さいですが、

システムの個々の部分を保護する
改善のための時間と労力を節約し、バグをキャッチします。
開発者だけでなく、アナリストや製品マネージャーの情報セキュリティに対する意識を高めます。

自動化

DAST

彼は動的アプリケーションセキュリティテストです。どんなに奇妙に聞こえても、Webアプリケーションの場合はBurp Suiteを使用しました。彼はすでに彼の仕事で有名で不可欠なツールでした。さらに、このスキャナーには、ウィッシュリストで改良するための優れたAPIがあります。おそらく誰かがこれは単なるペンテスター向けのデスクトップツールであると言うでしょうが、実際には企業の要件をカバーすることができます。

SDLCのコンテキストでは、次のとおりです。

スケジュールスキャンおよびイベントスキャン（新しいリリース）;
アプリケーションの初期評価。
スポットスキャン、不規則なファジング、およびアプリケーションの負荷。
オープンAPIのおかげで、特定の各プロジェクトに追加でき、ツールを完全に制御できます。

ダイナミックスキャンが定性的にカバーできないのは、アプリケーション内のすべての入力ポイントを見つけることです（その後、トラフィックを最終テストノードとQA自動テストにプロキシすることで問題が解決されましたが、予期しないシナリオからは救われません）。

DASTが基本的にカバーできないもの：

二次脆弱性の発見（100％のカバレッジではありません）;
変更された入力ポイントと変更されていない入力ポイントを分離することは困難です。したがって、スキャンはアプリケーション全体で行われ、スキャン時間が非常に長くなる可能性があります。
軍事プロジェクトをスキャンする場合の製品データの歪みの危険。

SAST

当時の最適な自動化オプションは、SAST、 静的アプリケーションセキュリティテスト -潜在的な脆弱性についてのアプリケーションソースコードの静的スキャンです。

スキャナーは、入出力ポイント、システムのさまざまなモジュール（DB、サービス）への中間呼び出し、および外部環境からのデータ型（ユーザー入力、データベースからの選択）を分析することにより、プログラム呼び出しのグラフを作成します。

このデータとスキャナーのアンチパターンと悪い慣行に関する知識に基づいて、sast-toolは潜在的なセキュリティエラーを見つけます。

SASTスキャナーはDASTと基本的にどのように異なり、SDLCバンドルでより優れています。

バージョン管理システムのcommit-hookでスキャンを終了し、スキャンするリポジトリブランチを指定できます。
DASTとは異なり、テスト/戦闘環境で動作するアプリケーションの計算を待つ必要はありません。
すべてのプラットフォーム（Web、デスクトップ、モバイル）のスキャンに同様に適しています。
アプリケーションを繰り返しスキャンできます-変更されたコールグラフのみを表示します。コードカバレッジを失うことなく、スキャン時間が大幅に短縮されます。

しかし、スキャナーの導入のプラス面に加えて、多くの落とし穴に直面しなければなりませんでした。

SDLCは継続的な開発ライフサイクルを意味します

あらゆるタイプのスキャナーに関連する共通点。

スキャナーは単なるツールであり、適切なタイミングで実行する必要があります。できれば時間内にいくつかのイベントにハングアップしてください。さらに、SASTでは、スキャンがプロジェクトのすべてのデータとその依存関係を通過するために、すべてのプロジェクトの依存関係のコードを収集する必要があります。また、すべてのスキャナーが自分でできるわけではありません。また、後続のスキャンでの新しいポジティブの出現を監視し、それらに関するニュースレターを受信し、クリーンビルドおよびバグを含むビルドに関するビルドシステムでタグをハングアップすることも素晴らしいでしょう。

その結果、スキャナーをSDLCに接続するために、すべての統合の問題を扱う別のサービスを作成しました。

一般的に、これはTeamCityの新しいアセンブリのフックであり、エージェントの1つからコントロールセンターサービスに情報が送信されます。彼はソースに対して一連の操作を行い、それらをスキャナーに送信して監視を開始します。

豊富なプロジェクト、初期スキャン

便利な反復スキャンを開始するには、送信の開始点が必要です。後続のスキャンと比較し、現在の反復で発生したエラーのみを示すことができます。

最初に、レポートに表示されるすべてのトリガーを表示する必要があります。プロジェクト/言語の詳細に応じて、多くの誤検知があります。また、アプリケーションポイントの署名が指定されるまで、スキャナーは、モデルを記述するクラスの抽象setNameメソッドgetNameがReflected XSSであると主張します。

カスタムロジックは、すべてのホーム開発についても説明する必要があります。フレームワークを作成する場合、独自の検索ルールを作成する必要があります。スキャナーの実装中に、さまざまな言語およびプロジェクト用にこれらのルールを100以上収集しました。

そして、少なくとも現時点では、ツールがすべての言語とフレームワークをサポートしていないという事実に我慢する必要があります。