静的コードアナライザーに関する3つのインタビュー

親愛なる読者の皆さん、こんにちは！

著者は、ソフトウェア開発の方法論、特に静的コードアナライザーの使用に関する最新の大規模で興味深いプロジェクトの代表者との3回のインタビューを提供します。 著者は、読者がこのテキストを読むことに興味を持つことを望んでいます。 参加者：アクロニス、AlternativaPlatform、NGOエシェロン。

よろしく
アレクサンダー・ティモフィーエフ

参加者と記事の構造

インタビューのために、著者は3つの会社に注目しました。
-バックアップと復元のためのAcronis BackupとAcronis


-マルチプレイヤーゲームであるTankiOnlineプロジェクトを使用したAlternativaPlatform


-セキュリティコードの改訂用の多数の製品を含むNPO「エシェロン」


エシェロンNGOの変更を除き、質問はすべての企業で同じであったため、インタビューはこの企業の詳細をよりよく反映するようになりました。

アクロニスへのインタビュー

スピーカー-キリルコロタエフ、Acronis Backup製品開発担当副社長

1）会社/プロジェクトのメインで最も大規模な製品の概要情報（製品の本質、製品が書かれている言語、製品の作成に携わる人の数、日または週ごとにプロジェクトコードを行またはキロバイト単位で変更する通常の割合） \月、CVSが使用されます）

私たちが開発しているAcronis Backup製品の本質は、ユーザーデータのバックアップコピーをコンピューター、ラップトップ、サーバー上に作成することです。 これらのバックアップから後でデータを復元する機会を人々に提供するため。 たとえば、コンピューターがクラッシュした場合、回復が必要になる場合があります。 または、ファイルまたはドキュメントの以前のバージョンが必要な場合。 または、ファイルが失われた場合。

プロジェクト全体は、99％C ++パーセントで記述されています。 約70人の開発者が取り組んでいます。 平均して、1週間に100〜300の編集（コミット）がプロジェクトコードに対して行われます。 使用されるバージョン管理システムはSVN（Subversion）です。

2）プロジェクトコードを誰とどのように分析しますか？ テストサイクルはどのように構成されていますか？ テスターのスタッフの幅はどのくらいですか？ 会社はエラー情報の出現にどのように反応しますか？そのような状況のために開発されたプロトコルはありますか？

アーキテクトがおり、それぞれが担当するプロジェクトのそれらの部分のコードを知り、このコードを分析し、それを改善する方法を知っているリーダーがいます。 各コミットはコードレビューシステムを通過します。つまり、変更は最初にコードの責任者によって分析されます。
現時点では、テスターの数は開発者の数に匹敵します。 テストには、自動テストと手動テストが使用されます。 たとえば、ビルド検証テスト-新しいビルドをそれぞれチェックする一連のテストがあります。 そして理想的には、各コミットの後に、新しいビルドをコードで収集し、すぐにチェックする必要があります。

見つかったエラーに対する反応プロセスは次のように整理されます。 テスト部門で見つかったエラー（問題）は、Jiraシステム（より高度な有料バージョンのBugZilla）に記録されます。 これらはすべてSVNと統合されています。たとえば、特定の問題を修復するコミットが行われると、このコミットへのリンクがJiraに追加されます。 また、エラー情報は当社製品のユーザーから提供される場合があります。 まず、技術サポート（サポート）に連絡します。 サポートで分析が必要なバグが明らかになった場合、再びバグに関する情報が最初にJiraに届きます。 また、エラーは次の製品アップデートで修正されます。

3）ツールは静的コード分析に使用されますか？ 使用する場合、どれですか？ 使用する場合は、専門家に依頼して、アナライザーが見つけた最も注目すべき興味深いエラーの例を提示してください。 アナライザーを使用した場合の通常の結果と統計は何ですか？ 検査はどのような頻度で、どの計画に従って実施されますか？ アナライザーによって検出されたエラー応答シナリオは何ですか？

以前はさまざまな静的アナライザーを使用していました。たとえば、無料のオープンソースcppcheckとPVS-Studioの両方を使用していました。 もちろん、あらゆるプロジェクトでそれらを使用することは理にかなっています。 しかし、さまざまなコードアナライザーは互いに非常に異なり、さまざまなクラスのエラーをキャッチします。したがって、使用するツールの多様性に賛成です。

これらは興味深い潜在的なバグです。 たとえば、より複雑なものの中で、PVS-StudioはSTLライブラリから標準の自動ポインターの誤った使用を検出します。 または、たとえば、このような興味深いエラーを見つけます-ある構造またはパラメーターから1つのsizeofを別のsizeofで乗算すると、PVS-Studioは、一般に1つのsizeofに別のsizeofを乗算するのがおかしいと言われます。 ここでは、正方形でも次元が論理的に取得されることがわかります。

静的アナライザーは、使用前にポインターのnullがチェックされないことを理解できる場合があります。 しかし、これらはより複雑なチェックです。コードのこの時点でポインターがnullになる可能性があるかどうかが常に明らかではないためです。 静的アナライザーで1日に1回コードをチェックするのは非常に良いタスクです。 同時に、同じJiraでバグを自動的にジャムします-これは開発中の製品に役立ちます。

4）大規模なソフトウェア製品を作成するための将来の方法に関する専門家の意見。 それとは別に、専門家は静的コード分析のツールに何を期待し、望んでいますか？

自動化ツールは進化しており、進化します。 たとえば、現在、行われた変更に基づいてテストを選択する自動システムはありません。 たとえば、コードの特定の変更のために、実行する必要のあるテストを選択します。

静的アナライザーの将来については、静的アナライザーが処理する状況の数が増えると思います。 この場合、静的アナライザーはより複雑な分析に移行します。 また、たとえば、任意のプロトコルを使用したコード準拠の保証もあります。

5）同僚や読者への専門家の訴え

品質の高いコードを作成してテストし、さまざまな手法を適用します。 含む、および静的アナライザー。

AlternativaPlatformへのインタビュー

スピーカー-Alexi Quiring、TankiOnline LLCテクニカルディレクター

1）会社/プロジェクトのメインで最も大規模な製品の概要情報（製品の本質、製品が書かれている言語、製品の作成に携わる人の数、日または週ごとにプロジェクトコードを行またはキロバイト単位で変更する通常の割合） \月、CVSが使用されます）

現時点では、そのような製品の1つ-オンラインゲームTankiOnlineがあります。 サーバー側はJavaで記述されています。 クライアント部分はAS3上にあります。 約20人のプログラマがいます。 週に約5K行が追加されます。 GITをCVSとして使用します。

2）プロジェクトコードを誰とどのように分析しますか？ テストサイクルはどのように構成されていますか？ テスターのスタッフの幅はどのくらいですか？ 会社はエラー情報の出現にどのように反応しますか？そのような状況のために開発されたプロトコルはありますか？

Gitの典型的なプロセスがあります。 すべてのコードは必須のコードレビューに合格します。 継続的インテグレーションも導入され、ビルドサーバーは常にコードをチェックし、テストを実行します。

テストはいくつかの段階で行われます-最初に自動テストを行い、次に開発者自身が自分の手でテスト（プレイ）し、次にテスターのチーム。 すべてが順調であれば、コミュニティのテスターがつながります。 そして、この変更が実稼働に入って初めてです。 テスターの小さなチームがあります-3人です。 しかし、私たちはコミュニティのテスターを積極的に使用しています。数十人のボランティアがいます。

それでもエラーが本番環境に侵入した場合、検出後すぐに修正されます。 通常、このようなエラーはすべて数日で修正されます。

3）ツールは静的コード分析に使用されますか？ 使用する場合、どれですか？ 使用する場合は、専門家に依頼して、アナライザーが見つけた最も注目すべき興味深いエラーの例を提示してください。 アナライザーを使用した場合の通常の結果と統計は何ですか？ 検査はどのような頻度で、どの計画に従って実施されますか？ アナライザーによって検出されたエラー応答シナリオは何ですか？

会社レベルでは、このようなツールは使用しません。 過去に、興味のために、いくつかの分析ツールを実行しましたが、致命的なものは見つかりませんでした（JetBrain IDEAチェッカー）。

静的解析は、CやC ++のような複雑な言語に非常に適していると思います。 しかし、Javaなどの単純なものの場合、その関連性はそれほど大きくありません。 Javaでは、クラスとして、メモリの問題はありません。 構文は単純で単純であり、矛盾は許されません。コンパイラはコンパイル段階で多くのことをチェックします。 開発環境は、リファクタリングのための便利なツールを提供します。これにより、コードを手動で変更する際の偶発的なエラーがなくなります。

Java用の静的アナライザーを使用する領域が1つあります。 これは、マルチスレッド実行の正確性に関するプログラムチェックです。 しかし、現時点ではそのようなツールはありません。 一般に、静的アナライザーが高品質で、実際にエラーを探している場合、これはプロジェクトにとって有用です。

4）大規模なソフトウェア製品を作成するための将来の方法に関する専門家の意見。 それとは別に、専門家は静的コード分析のツールに何を期待し、望んでいますか？

未来は、自動テストシステム、継続的インテグレーション、コードアナライザーにあります。 静的分析から、マルチスレッドアプリケーションの分析と、アーキテクチャの決定の正確性の分析が期待されます。

5）同僚や読者への専門家の訴え

生産サイクルに新しいテクノロジーを導入することを恐れないでください。 より経験豊富なプログラマーから学びましょう。 古い決定を修正します。 そして、すべてが確実に機能します。

NGOエシェロンへのインタビュー

スピーカー-Andrey Fadin（a.fadin@cnpo.ru）、エシェロンNPO社のチーフデザイナー

1）会社に関する概要情報およびソフトウェアに関連するその活動。

エシェロンNPOは、セキュリティ分析ツールの開発者であり、情報セキュリティ認証および商用コード監査プロジェクトの一部としてこれらの製品のアクティブユーザーでもあります。

当社が開発したセキュリティ分析ツールには以下が含まれます。

• AK-VS 2-宣言されていない機能がないことを監視する要件に従って、ソーステキストの認証テストを実施するためのクラウド環境（制御のレベル1まで）。
• AppChecker-ソフトウェアブックマーク、重要なソフトウェアの脆弱性、およびプログラムコードの欠陥に関連するその他の問題を識別するために、プログラムコードのシグネチャヒューリスティック分析を実行します。
• PIC-ファイル、フォルダー、コンピューター記憶媒体のチェックサムを修正および比較する手段。
• Scanner-VS-ネットワークおよびローカルセキュリティ監査を実行するためのツールと環境のセット。セキュリティスキャナ、トラフィック分析ツール、メディア上の残留情報の検索、および他の多くのコンポーネントが含まれます。

エシェロンコードセキュリティ分析および侵入テストチームは、AO NPOエシェロンおよびMSTUにちなんで名付けられた国内有数の技術大学の人員、研究およびエンジニアリング基盤で作成された、情報技術および情報セキュリティの分野の有資格専門家の協会です。 N.E.バウマン。

PHP、Java、C＃、C / C ++、Perl、Python、JavaScriptなど、最新の標準を含む、最も一般的なプログラミング言語を使用しています。

エシェロン社のスペシャリストによって実行されるプログラムコードの監査により、次のタスクを解決できます。
内部および外部（外部委託）コードの品質管理、典型的な欠陥（コーディングまたは設計エラー）の検出;
コード内の意図的なソフトウェアブックマークの識別。
借用コード制御（オープンソースおよび他の外部コンポーネントからの外部ソフトウェア依存関係の分析）

監査されたソフトウェアについては、NPOエシェロンの試験所で情報セキュリティ要件の認証が可能です。

2）専門家の仕事の概要（非機密および非機密情報）-プロジェクトコードを誰とどのように分析するか、テストサイクルをどのように編成するか、コードで重要な瞬間が検出された場合の通常のプロトコルは何ですか？

コード監査チームは、主に2種類の専門家で構成されています。

最初のタイプの専門家は、エシェロンNGOのテストラボの専門家であり、大規模なソフトウェアプロジェクト（オペレーティングシステム、ファイアウォール）の開発者とのやり取りの整理、および大量のコードのレビューに関する共同作業の経験があります。

2番目のタイプの専門家は、さまざまなプログラミング言語、そのフレームワーク、および標準ライブラリの高い技術的能力を持っている開発者（エシェロンの研究開発部門の従業員）です。 可能な場合は常に、静的分析ツールの開発者をコード監査に直接関与させるようにします。これにより、経験上、分析ツールの利便性を直接評価できます。 さらに、開発者は統計アナライザーの新しいシグネチャを作成するスキルが高いため、調査対象のソフトウェアプロジェクトの仕様で必要な場合、開発者を欠陥データベースのタイムリーな更新のために接続することは理にかなっています。

一般に、開発とテストのプロセスは次の段階に関連付けられています。
1.プロジェクトコードのコンポーネントへの分解（サードパーティプロジェクトの分析が進行中の場合）
2.脅威モデルの構築、これらのコンポーネントの分析、および情報セキュリティの観点からの重要性に関する相互作用インターフェース。
3.パラグラフ2の結果を考慮した静的および動的分析ツールの起動
4.条項3および2の結果に基づく選択的なコードレビュー
5.特定された潜在的に危険な構造のプロトコルの準備と、ソフトウェアプロジェクトの開発者チームとのこれらの結果の議論。
通常、ステージ3、4、および5は3〜4回繰り返されます。これは、潜在的に危険な構造のそれぞれの分析結果に従って、原則として、欠陥を排除するためにソフトウェアプロジェクトが完成するためです（3から始まるステージの繰り返しが必要です）。このコードフラグメントは、専門家の誤った仮定、または静的アナライザーの誤った操作（4から始まる段階の繰り返しを伴う）であること。

3）静的分析ツールに関する情報-使用されている静的アナライザー。 アナライザーが見つけた最も注目すべき興味深いエラーの例。 アナライザーの使用による通常の結果と統計は何ですか。 アナライザーによって検出された瞬間応答スクリプトとは何ですか？

彼らの仕事では、監査人は私たち自身の開発（AK-BC2、AppChecker）とオープンソースツール（CppCheck、PMD）の両方を使用し、またサードパーティの市販製品（プログラム検証CppCat）を使用します。

応答シナリオについては、段落2で説明しました。 アナライザーの使用に関する統計については、原則として、大規模プロジェクトでのアナライザーの誤検知（誤検知）の割合は50％を超えており、特定された潜在的に危険な構造の長いリストをコンパイルするには、何らかの方法で専門家の関与が必要です。 ただし、コード全体をレビューするのではなく、重要なセクションのみをレビューするため、平均してコードの合計量の5％を超えないため、コード分析の時間を大幅に節約できます。

残念ながら、営業秘密契約の非開示の違反を回避するために、特定の製品で見つかったエラーについて話すことはできません。 しかし、私たちの経験から、興味深いエラーのほとんどは関連していました。

• ハードコードされたパスワード（ハー​​ドコードされたパスワードの使用、CWE-259）およびその他の認証データ（ハードコードされた資格情報の使用、CWE-798）;
• 「イースターエッグ」およびその他の非表示機能（非表示機能、CWE-912）。
• 多くの場合、「レース」および共有リソースに関連するエラーは「ポップアップ」します（レース条件、CWE-362）。

4）将来のソフトウェア製品の作成方法に関する専門家の意見、および静的コード分析ツールとは別に専門家が期待し、望んでいること。

私たちの意見では、将来的には、ソフトウェア検証は継続的インテグレーションシステムのフレームワーク内および継続的展開（継続的デリバリー）の両方で、開発プロセスにますます密接にリンクされるでしょう。

将来これらのシステムと緊密に統合することにより、ソフトウェアの開発と配信を完全に制御できるようになり、これらのプロセス内での統計が可能になります。 アナライザーは、一種のIPSの役割を果たし始め、コミットのレベルでブロックし、品質基準（品質ゲート）の要件を満たしていないコードをリリースします。 この観点から、CI / CDシステムはセキュリティ管理システム（SIEM）の興味深いイベントのソースでもあります。

statの導入にも大きな見通しがあります。 モデル駆動型開発パラダイムへのアナライザー、CASEツールとの緊密な統合により、構文レベル、ソフトウェアコンポーネントとそのインターフェイスのレベル、さらにはビジネス要件のレベルでエラーをチェックできるため、たとえばアナリストはシステム設計の段階で、アクセス制御に特定の役割を追加する必要性を顧客に正当化します。

5）同僚や読者への専門家の訴え

過去10年間、企業の情報セキュリティを確保しながら、主にネットワークセキュリティ、およびノー​​ドとワークステーションのセキュリティ（エンドポイントセキュリティ）に重点を置いていました。

ただし、ゼロデイ脆弱性の特定、ブックマークおよび「インプラント」（国家または産業スパイのためのソフトウェアに埋め込まれたコードと構成の断片）の検出などの問題の解決について話す場合、古典的なツールという事実に直面していますネットワークレベルまたはホストレベル（侵入検知システム、ウイルス対策ツール）での情報の保護は、これらの脅威に効果的に対処する方法ではありません。

これらの問題に対処するには、一方で企業の情報セキュリティ管理を集中化する包括的なアプローチ（SIEMシステム）が必要であり、他方では、ソフトウェアをその起源を制御するコンポーネントに構造的に分解し、コンポーネントおよび材料のコンテンツの静的分析を使用する必要がありますそれらの製品（ソースコードを含む）。

おわりに

著者は、効率的な作業とインタビューの質問に対する回答の完全性について、調査に参加している企業のプレスサービスと専門家に感謝します。 また、 OOO Program Verに感謝し、この記事のスポンサーとなった最新の静的コードアナライザーPVS-Studioを開発しました。 そして、この記事の助けがなければ日の目はほとんど見えなかったでしょう。