私たちは小売業者で安全な開発を構築します。1つの大きなプロジェクトの経験

少し前に、ロシア最大の小売企業の1つで、アプリケーションコードアナライザーに基づいた安全な開発プロセスの構築を完了しました。この経験は困難で長く、ツール自体とそのようなプロジェクトの実施のための開発チームの能力の両方の開発に強力なブレークスルーをもたらしたことを認めなければなりません。この経験を、実際にどのように起こったか、どのレーキを踏んだか、どのように状況から抜け出したか、それが顧客と私たちに最後に何を与えたかについての一連の記事であなたと共有したいと思います。一般的に、実装自体の要点について話しましょう。今日は、小売業者ポータルとモバイルアプリケーションの安全な開発に焦点を当てます。







まず、一般的にプロジェクトについて。私たちは、IT部門に巨大なスタッフがいて、相互に最小限の相関関係にある多くの領域に分割されている大規模な商社で安全な開発プロセスを構築しました。従来、これらの領域は3つの主要なグループに分けることができます。最初の非常に大きなグループは、主にJava（プロジェクトの90％）で作成されたキャッシュレジスタソフトウェアです。コード量の観点から2番目に広範なシステムグループはSAPアプリケーションです。そして最後に、3番目のブロックは、ポータルとモバイルアプリケーションの「寄せ集め」でした。会社のクライアント向けのさまざまな外部サイト、これらのサイト向けのモバイルアプリケーション、および内部リソース（小売業者のスタッフ向けのモバイルアプリケーションとWebポータル）です。



プロジェクトのクライアントである情報セキュリティ部門は、3つのグループすべてについて、かなり標準的な方法で一般的なタスクを策定しました。「脆弱性を減らし、社内で作成されたすべてのシステムの安全な開発を実現したい」。しかし実際には、特定の部門ごとに、すべてが他の同僚のそれとは非常に異なって見えました。安全な開発を実装するすべてのステップで、100万の異なる妥協をしなければならなかったからです。いくつかのニュアンスはプロセスを構築するのに役立ちましたが、逆に他のニュアンスは干渉しました。結局、ほとんどのプロジェクトで多かれ少なかれ一般的なアプローチを作成することができました。



このアプローチは可能な限り単純に策定しました。すべての開発者にとって最も関連性の高いコードをスキャンします。 Gitflowの観点から言えば、SAPを除くすべてのプロジェクトグループがGitflowに開発のブランチを持っていた場合、メインの開発ブランチはスケジュールに従ってスキャンされます。



ただし、いつものように、どのルールにも例外があります。さまざまな理由から、一般的なアプローチを「現状のまま」どこにでも適用することはできませんでした。まず、必要に応じて、いくつかのプログラミング言語の最も詳細な分析を実行できるようにしたいという事実のために、ツール（コードアナライザー）にはいくつかの制限があります。したがって、Javaの場合、分析バイトコードはソースコードのバイトコードよりもはるかに深くなります。したがって、Javaプロジェクトをスキャンするには、バイトコードを事前に組み立ててから、分析のために送信する必要がありました。C ++、Objective C、およびiOSアプリケーションの場合、アナライザーはビルド段階でプロセスに組み込まれました。また、すべてのプロジェクトの開発者からのさまざまな個別の要件を考慮に入れる必要がありました。以下では、ポータルとモバイルアプリケーションのプロセスをどのように構築したかについて説明します。

ポータルとモバイルアプリケーション

これらのアプリケーションはすべて1つの論理グループにまとめられているように見えますが、実際にはひどい混乱でした。 120以上のポータルがありました（！）。会社は非常に大きく、多くのビジネス、管理、技術部門があり、それぞれが自分のポータルとモバイルアプリケーションが必要であると判断することがあります。このポータルとアプリケーションは作成され、しばらくの間使用された後、安全に破棄されます。その結果、これらのアプリケーションの開発者でさえコードベースの単一のリストを持っていなかったため、初期段階では、顧客のインベントリを実行する必要がありました。たとえば、このグループのリポジトリを管理するために、開発者は異なる管理者を持つ2つのGitLabを使用しました。さらに、ポータルとモバイルアプリケーションの中で、プロジェクトの大部分は外部開発を使用して実装されました。そのため、リリース時期が近づくと、請負業者は新しいバージョンのソースコードをほぼUSBフラッシュドライブで会社に転送することがよくありました。その結果、同社はさまざまなアプリケーションの動物園を持ち、コードが完全に混乱していました。すべてのプロジェクトのリストを作成し、それらの責任者（技術所有者、チームリーダー）をすべて見つけて、主要な顧客である情報セキュリティ部門に同意する必要がありました。これらのうち、分析します。



その結果、分析用に本番システムとサポートされているソフトウェアを選択し、アーカイブシステムにはまったく触れませんでした。多くの内部アプリケーションは、会社に金銭的な損害を与える可能性がなく、分析対象として選択されなかったため、重要ではないと見なされました。たとえば、1つの倉庫またはローダー内のパッカーの管理システム。社内の外部クライアントに対して脆弱なものはなく、社内従業員の1人によるハッキングは、多くの部門にわずかな社内の不便をもたらすだけです。



ISサービスは、このソフトウェアグループと開発者の優先タスクとして、脆弱性のコード分析の導入を策定し、開発サイクルに統合された便利な検証プロセスを構築しました。

標準スキームに従った統合

2つの異なるバージョンのGitLabが、ポータルおよびモバイルアプリケーションのグループのバージョン制御システムとして使用されました。





GitLabとの統合のセットアップ



すべてのアプリケーションがCI / CDを使用しているわけではなく、使用されていない場合は、それを使用することを主張する必要がありました。コードの脆弱性をチェックするプロセスを真に自動化して（分析のためにリンクを手動でアップロードするだけでなく）、システム自体がコードをリポジトリにダウンロードして必要なスペシャリスト自身に結果を提供するようにしたい場合は、ランナーをインストールしないと実行できません。この場合のランナーは、バージョン制御システムに自動的に接続し、ソースコードをダウンロードして、分析のためにSolarappScreenerに送信するエージェントです。



ポータルおよびモバイルアプリケーショングループの開発者は、安全な開発を半自動化されたプロセスとして編成し、コードが自分たちの関与なしに脆弱性についてスキャンされるようにしたいと考えていました。セキュリティ担当者が脆弱性の分析結果を検証し、脆弱性が重大であると考えた場合はJiraの開発者にタスクを割り当てるか、明確にするために開発者に送信します。開発者は、脆弱性を緊急に修正する必要があるかどうかを判断します。また、必要に応じて、修正を含めることができるリリースを計画します。



Jiraは主にバグトラッカーとして使用され、コードアナライザーが検出された脆弱性に関する情報を自動的に提供しました。





Jira統合セットアップ



まれに、チームリーダーがクロールの結果を自分で確認し、Jiraで手動でタスクを開始しました。





Jiraでのタスクの作成



このようなケースも、別の機能として規則に登録しました。一部のプロジェクトでは、一般に、すべての修正はSlackまたはTelegramで議論され、タスクはリアルタイムで設定されました。



その結果、Solar appScreenerの実装後の安全な開発のプロセスは、次のようになり始めました。ポータルは、メインの開発ブランチのコードの変更について毎日チェックされます。メインの最も関連性の高いブランチが24時間以内に更新されていない場合、何も起こりません。更新されている場合、このブランチは分析のためにこのリポジトリの対応するプロジェクトに送信されます。 GitLabのリポジトリは、コードアナライザの特定のプロジェクトに関連付けられており、そこでメインブランチがスキャンされました。その後、セキュリティ担当者が分析結果を確認して検証し、Jiraで修正作業を開始しました。





Jiraで作成された分析結果と脆弱性修正タスク



原則として、緊急に排除する必要のある重大な脆弱性から脆弱性を修正し始めました。このような脆弱性が終了すると、チームはコードで見つかった新しいエラーの修正に進みました。そして、すでに第3段階で、たとえば、いくつかの技術的債務をクローズするという枠組みの中で、古い残りの脆弱性も排除されました。

標準として非標準

これは、一見、それほど複雑ではないプロセスには、2つの重大な制限がありました。まず、Androidアプリケーション（つまり、Javaで記述されたもの）を分析するには、アセンブリが必要でした。次に、iOSには、エージェントをインストールするmacOSマシンが必要であり、アプリケーションを構築できる環境があります。私たちはAndroidアプリケーションを非常に簡単に扱いました。開発者がすでに利用できるスクリプトにパーツを書き込み、スケジュールに従って起動しました。スクリプトの私たちの部分は、最も広い構成でプロジェクトのビルドを事前に起動し、分析のためにソーラーappScreenerに送信されました。 iOSアプリケーションをチェックするために、MacマシンにMacOSエージェントをインストールしました。Macマシンはコードをアセンブルし、GitLabCIを介してスキャンするためにコードをアナライザーに送信しました。さらに、他のタイプのソフトウェアの場合と同様に、セキュリティ担当者は分析結果を確認して検証し、修正の問題をJiraに提出しました。



また、ポータルとモバイルアプリケーションをJavaで記述されたプロジェクトと呼び、同様の方法でそれらを収集して分析しました。



私たちの前提条件であるCI / CDがなかったプロジェクトでは、次のように述べています。「分析したい場合は、手動で収集して、自分でスキャナーにロードします。JavaやJVMのような言語（Scala、Kotlinなど）がない場合は、リンクからリポジトリにコードをアップロードするだけで、すべて問題ありません。」

プロジェクトの複雑さ

上記からわかるように、このアプリケーションスタックでは、主な問題は多くのプロジェクトでCI / CDが不足していることでした。開発者はしばしば手作業でビルドを行いました。アナライザーをC＃のSharepointポータルと統合し始めました。現在、C＃は多かれ少なかれLinuxシステムに切り替えられていますが、本格的ではありません。プロジェクトが本格化したとき、この言語はまだWindowsで機能していたため、GitLab用のエージェントをWindowsにインストールする必要がありました。私たちのスペシャリストはLinuxコマンドの使用に慣れているため、これは実際の課題でした。特別な解決策が必要でした。たとえば、exeファイルへのフルパスを指定する必要がある場合、そうでない場合、何かをエスケープする必要があるなどです。そして、Sharepointとの統合の実装後、PHPのモバイルアプリケーションプロジェクトのチームは次のように述べています。ランナーもいないので、C＃を使いたいと思っています。私も彼らのために操作を繰り返さなければなりませんでした。

概要

その結果、テクノロジー、チーム、プロセスのこのような異種のパークにもかかわらず、このケースの主なケースをいくつかのパイプラインにグループ化し、必要に応じてそれらの実行を自動化し、実装することができました。この例では、次のことを確認できました。

• 私たちが実装しているソリューションは、根本的に異なる展開環境でDevSecOpsプロセスを構築するために必要な柔軟性を提供するのに十分古いものです。柔軟性は、組み込みおよびカスタム統合の大規模なセットによって実現されます。これがないと、実装の人件費が大幅に増加するか、不可能になります。
• . 3-4 ;
• DevSecOps DevOps , , . win-win - .

思い出してください。これは、大規模小売業者での安全な開発プロセスの構築に関する一連の記事の最初の部分です。次の投稿では、SAPファミリーのアプリケーショングループでのこのプロジェクトの実装の詳細を明らかにします。



同様のプロジェクトを実施した経験はありますか？安全な開発慣行を実施した事例をコメント欄で共有していただければ幸いです。



著者：Ivan Staroselsky、情報システム運用および自動化部門の責任者