🚣🏿 👨🏼‍✈️ ⛔️ PVS-Studioは脆弱性の検索にどのように役立ちますか？ 🚤 🎁 🥡

コンピューターのセキュリティに関する脆弱性-システムの欠陥で、意図的に整合性を侵害したり、誤動作を引き起こしたりすることができます。実践が示すように、一見些細なバグであっても、深刻な脆弱性になる可能性があります。脆弱性は、静的分析を含むソフトウェアの検証と検証のさまざまな方法を使用して回避できます。 PVS-Studioが脆弱性スキャンタスクを処理する方法について説明します。

PVS-Studioは、エラーだけでなく脆弱性も防ぐツールです

この結論に至った経緯を以下に少し説明します。ここで、PVS-Studioとは何かを説明したいと思いました。

写真4

PVS-Studioは、C、C ++、C＃で記述されたプログラムのエラー（および後述する脆弱性）を検索する静的コードアナライザーです。 WindowsおよびLinuxで動作し、プラグインとしてVisual Studio IDEに統合できます。現在、アナライザーには450を超える診断ルールが実装されており、それぞれにドキュメントが添付されています。

執筆時点で、PVS-Studioを使用して、 280を超えるオープンソースプロジェクトがテストされ、 11,000を超えるエラーが検出されました。これらのエラーのうち、どれだけが脆弱性なのでしょうか...

公式WebサイトからPVS-Studioをダウンロードしてお試しください。

ところで、セキュリティの専門家にPVS-Studioのライセンスを提供しています。あなたが公安の専門家であり、脆弱性を探している場合は、ライセンスを取得するために私たちに連絡してください。この提案の詳細については、「セキュリティの専門家にPVS-Studioアナライザーを提供しています」という記事をご覧ください。

用語

用語に精通している場合は、CVEとCWEの違い、およびそれらの共通点を知っている場合は、このセクションをスキップできます。後で理解しやすくするために、残りの部分をよく理解することをお勧めします。

CWE（Common Weakness Enumeration）-セキュリティ欠陥の一般的なリスト。開発者およびソフトウェアセキュリティの専門家向けに設計されています。これは、ソフトウェアのアーキテクチャ、設計、コード、または実装に現れる可能性のある一般的なセキュリティ欠陥の公式レジストリまたは辞書であり、攻撃者がシステムへの不正アクセスを取得するために使用できます。このリストは、ソフトウェアセキュリティの欠陥を記述するための普遍的な公式言語として、また、そのような欠陥を検出し、これらの欠陥を認識、除去、防止するツールの有効性を測定するための標準として開発されました。

CVE（Common Vulnerabilities and Exposures）-攻撃者が直接使用できるプログラムエラー。

MITER Corporationは、一般的なソフトウェアの脆弱性と脆弱性（CVE）のリストが作成された1999年に、ソフトウェアの脆弱性の分類に関する作業を開始しました。 2005年、CVEシステムのさらなる開発の一環として、著者のチームは、一般的なソフトウェアセキュリティの欠陥を識別するために、脆弱性、攻撃、クラッシュ、およびその他の種類のセキュリティ問題の予備分類を開始しました。ただし、CVEのフレームワーク内で作成された分類は自給自足ですが、アナライザーが使用するコードセキュリティ評価方法を定義および分類するにはあまりにも粗雑であることが判明しました。この問題を解決するために、CWEリストが作成されました。

PVS-Studio：異なるポジショニング

背景

PVS-Studioは、常にプログラムコードのエラーを見つけるためのツールとして位置付けられてきました。プロジェクトの検証に関する記事では、バグ、エラー、タイプミスなどの適切な用語を使用しました。エラーごとに重要度が異なることは明らかです。このコードは単純に冗長でプログラマを混乱させる可能性が高いのですが、このエラーのためにシステム全体が3日ごとに午前5時にクラッシュします。これは理解でき、この概念は長い間、さらなる開発を受けませんでした-間違い、それらは間違いです。

しかし、時間の経過とともに、PVS-Studioによって検出されたエラーの一部はより深刻な方法で処理できることが判明しました。たとえば、 printf関数の不適切な使用は、 stdoutに間違ったメッセージを表示するよりもはるかに悪い結果をもたらす可能性があります。多くの診断ルールの助けを借りて、エラーだけでなく潜在的な脆弱性（CWE）を検出できることが明らかになったとき、問題にさらに詳しくアプローチし、PVS-StudioとCWEの診断ルールがどのように関連するかを確認することにしました。

PVS-StudioおよびCWE警告率

PVS-StudioとCWEアラートの関係を特定する作業の結果に基づいて、次の表がコンパイルされました。

CWE	PVS-Studio	CWEの説明
CWE-14	V597	コンパイラーによるバッファーをクリアするコードの削除
CWE-36	V631、V3039	絶対パストラバーサル
CWE-121	V755	スタックベースのバッファオーバーフロー
CWE-122	V755	ヒープベースのバッファオーバーフロー
CWE-123	V575	書き込み場所条件
CWE-129	V557、V781、V3106	配列インデックスの不適切な検証
CWE-190	V636	整数オーバーフローまたはラップアラウンド
CWE-193	V645	オフバイワンエラー
CWE-252	V522、V575	未チェックの戻り値
CWE-253	V544、V545、V676、V716、V721、V724	関数の戻り値の誤ったチェック
CWE-390	V565	アクションなしのエラー状態の検出
CWE-476	V522、V595、V664、V757、V769、V3019、V3042、V3080、V3095、V3105、V3125	NULLポインター逆参照
CWE-481	V559、V3055	比較する代わりに割り当てる
CWE-482	V607	割り当てる代わりに比較する
CWE-587	V566	ポインターへの固定アドレスの割り当て
CWE-369	V609、V3064	ゼロで除算
CWE-416	V723、V774	無料で使用
CWE-467	V511、V512、V568	ポインター型でのsizeof（）の使用
CWE-805	V512、V594、V3106	不正な長さの値を持つバッファアクセス
CWE-806	V512	ソースバッファのサイズを使用したバッファアクセス
CWE-483	V640、V3043	不正なブロック区切り
CWE-134	V576、V618、V3025	外部制御形式文字列の使用
CWE-135	V518、V635	マルチバイト文字列の長さの誤った計算
CWE-462	V766、V3058	連想リスト（リスト）の重複キー
CWE-401	V701、V773	最後の参照を削除する前のメモリの不適切なリリース（「メモリリーク」）
CWE-468	V613、V620、V643	誤ったポインターのスケーリング
CWE-588	V641	非構造ポインターの子にアクセスする試み
CWE-843	V641	互換性のないタイプを使用したリソースへのアクセス（「タイプの混乱」）
CWE-131	V512、V514、V531、V568、V620、V627、V635、V641、V645、V651、V687、V706、V727	バッファサイズの誤った計算
CWE-195	V569	署名されていない変換エラーへの署名
CWE-197	V642	数値切り捨てエラー
CWE-762	V611、V780	メモリ管理ルートの不一致
CWE-478	V577、V719、V622、V3002	Switchステートメントにデフォルトのケースがない
CWE-415	V586	ダブル無料
CWE-188	V557、V3106	データ/メモリレイアウトへの依存
CWE-562	V558	スタック変数アドレスの返却
CWE-690	V522、V3080	NULLポインター逆参照への未チェックの戻り値
CWE-457	V573、V614、V730、V670、V3070、V3128	初期化されていない変数の使用
CWE-404	V611、V773	不適切なリソースのシャットダウンまたはリリース
CWE-563	V519、V603、V751、V763、V3061、V3065、V3077、V3117	使用しない変数への割り当て（「未使用変数」）
CWE-561	V551、V695、V734、V776、V779、V3021	デッドコード
CWE-570	V501、V547、V517、V560、V625、V654、V3022、V3063	式は常に偽
CWE-571	V501、V547、V560、V617、V654、V694、V768、V3022、V3063	表現は常に真実
CWE-670	V696	常に間違った制御フローの実装
CWE-674	V3110	制御されない再帰
CWE-681	V601	数値型間の誤った変換
CWE-688	V549	引数として誤った変数または参照を持つ関数呼び出し
CWE-697	V556、V668	不十分な比較

表N1-ドラフトCWE対応表とPVS-Studio診断

これは表の最終バージョンではありませんが、PVS-StudioとCWEの警告が相互にどのように関連しているかについてのアイデアを提供します。 PVS-Studioは、バグだけでなく潜在的な脆弱性、つまりCWEでもプログラムコードで正常に検出された（そして常に検出された）ことが明らかになりました。このトピックに関していくつかの記事が書かれていますが、そのリストは現在の記事の最後にあります。

CVEベース

写真2

潜在的な脆弱性（CWE）-まだ脆弱性（CVE）はありません。オープンソースとプロプライエタリプロジェクトの両方で発見された実際の脆弱性は、サイトhttp://cve.mitre.orgで収集されています。ここで、特定の脆弱性の説明を表示したり、追加のリンクを見つけたりすることができます（たとえば、ディスカッションへのリンク、脆弱性修正の速報、脆弱性をカバーするコミットへのリンクなど）。必要に応じて、このデータベースを目的の形式で完全にダウンロードできます。執筆時点では、テキスト形式のデータベースは、サイズが約100MB、サイズが270万行を超える.txtファイルでした。とても印象的で、同意します。

写真6

作業の過程で、興味のある人に役立つかもしれない別の興味深いリソース-http://www.cvedetails.com/を見つけました。次のような機能を提供するという点で便利です。

CWE識別子によるCVE検索。
特定の製品でのCVE検索。
脆弱性の出現/修正に関する統計の表示。
CVEに関連する何らかの方法でさまざまなデータテーブルを表示する（たとえば、ソフトウェア製品が最も多くの脆弱性を発見した企業の評価）。
など

PVS-Studioを使用して見つけることができるいくつかのCVE

PVS-Studioアナライザーが脆弱性（少なくともそれらのいくつか）からアプリケーションを保護できることを示すために、この記事を書いています。

PVS-Studioを使用して検出された特定の欠陥が脆弱性として悪用される可能性があるかどうかは調査していません。それは難しく、そのような仕事はありません。したがって、私は別の方法で行動します。すでに発見され、説明されているいくつかの脆弱性を取り上げ、PVS-Studioを使用してコードを定期的にチェックすれば回避できることを示します。

ご注意 この記事で説明されている脆弱性は、合成例ではなく、古いプロジェクトリビジョンから取得された実際のソースファイルで見つかりました。

イルモゲート

写真7

最初に議論される脆弱性は、illumos-gateプロジェクトのソースコードで発見されました。 illumos-gateは、UnixおよびBSDに根ざしたオペレーティングシステムのコアを形成するオープンソースプロジェクト（ GitHubリポジトリで利用可能）です。

この脆弱性のコードネームはCVE-2014-9491です。

説明CVE-2014-9491 ：illumosのdevzvol_readdir関数はstrchr呼び出しの戻り値をチェックしません。これにより、リモートの攻撃者が不特定のベクトルを介してサービス拒否（ NULLポインターの逆参照とパニック）を引き起こすことができます。

問題のコードはdevzvol_readdir関数にあり、次のように見えました。

static int devzvol_readdir(....) { .... char *ptr; .... ptr = strchr(ptr + 1, '/') + 1; rw_exit(&sdvp->sdev_contents); sdev_iter_datasets(dvp, ZFS_IOC_DATASET_LIST_NEXT, ptr); .... }

strchr関数は、2番目の引数として渡された文字の最初の出現を指すポインターを返します。ただし、元の文字列に文字が見つからなかった場合、関数はNULLポインターを返す場合があります。しかし、この事実は忘れられているか、考慮されていません。その結果、戻り値に1が追加され、結果がptr変数に書き込まれます。その後、ポインターは「そのまま」動作します。結果のポインターがnullである場合、そのポインターを追加すると、無効なポインターが取得されます。NULLの不等式をチェックしても、その有効性は意味しません。特定の条件下では、このコードはカーネルパニックを引き起こす可能性があります。

PVS-Studioは、 V769診断ルールを使用してこの脆弱性を検出し、 strchr関数によって返されるポインターがnullになる可能性があることを報告し、同時に（追加1により）破損します。

V769 'strchr（ptr + 1、' / '）+ 1'式の 'strchr（ptr + 1、' / '）'ポインターはnullptrになる可能性があります。そのような場合、結果の値は無意味になり、使用しないでください。

ネットワークオーディオシステム

ネットワークオーディオシステム（NAS）は、 SourceForgeで利用可能なオープンソースのクライアントサーバーオーディオシステムです。 NASはUnixとWindowsの両方で機能します。

このプロジェクトで発見された脆弱性のコードネームはCVE-2013-4258です。

説明CVE-2013-4258 ：ネットワークオーディオシステム（NAS）1.9.3のserver / os / aulog.cのosLogMsg関数にフォーマット文字列の脆弱性があるため、リモートの攻撃者がサービス拒否（クラッシュ）を引き起こし、場合によっては任意のコードを実行できます。 syslogに関連する、指定されていないベクトルの文字列指定子をフォーマットします。

コードは次のようになりました。

 .... if (NasConfig.DoDaemon) { /* daemons use syslog */ openlog("nas", LOG_PID, LOG_DAEMON); syslog(LOG_DEBUG, buf); closelog(); } else { errfd = stderr; ....

このコードスニペットでは、 syslog関数が誤って使用されています。この関数の宣言は次のとおりです。

 void syslog(int priority, const char *format, ...);

2番目のパラメーターはフォーマット文字列で、後続のパラメーターはこの文字列に必要なデータでなければなりません。ここでは、フォーマット文字列が存在せず、ターゲットメッセージ（ buf変数）が引数として直接渡されます。これが、任意のコードの実行につながる脆弱性の理由でした。

SecurityFocusデータベースのエントリによると、この脆弱性はDebianおよびGentooオペレーティングシステムに現れました。

PVS-Studioとは何ですか？ PVS-Studioは、 V618診断ルールを使用してこのエラーを検出し、警告を発行します。

V618このような方法で「syslog」関数を呼び出すことは危険です。渡される行には形式の仕様が含まれている可能性があるためです。安全なコードの例：printf（ "％s"、str）;

このエラーおよび同様のエラーを検出することは、アナライザーに実装された関数注釈メカニズムと多数の注釈に役立ちます。現在、それらの数はC、C ++で6500、C＃で900を超えています。

この関数を正しく呼び出して、この脆弱性を解決する方法は次のとおりです。

 syslog(LOG_DEBUG, "%s", buf);

ここでは、フォーマット文字列「％s」が使用されます 。これにより、 syslog関数の呼び出しが安全になります。

Ytnef（YeraseのTNEFストリームリーダー）

Ytnefは、 GitHubで利用可能なオープンソースプログラムです。たとえば、Outlookで作成されたTNEFストリームのデコード用に設計されています。

2017年の過去の期間に、ここで説明した多くの脆弱性が明らかになりました。このリストに記載されているCVEエントリの1つ、 CVE-2017-6298を検討してください。

説明CVE-2017-6298 ：1.9.1より前のytnefで問題が発見されました。これは、「1 of 9. Null Pointer Deref / calloc return value not checked」として説明されているパッチに関連しています。

NULLポインターの逆参照が発生する可能性のある修正されたすべての場所は、ほぼ同じでした。

 vl->data = calloc(vl->size, sizeof(WORD)); temp_word = SwapWord((BYTE*)d, sizeof(WORD)); memcpy(vl->data, &temp_word, vl->size);

そのようなすべての場所で、脆弱性はcalloc関数の不適切な使用に関連付けられています。要求されたメモリブロックを割り当てることができなかった場合、この関数はNULLポインタを返すことができます。ただし、結果のポインターはNULLの不等式はチェックされませんが、 callocは常にゼロ以外のポインターを返すという計算で使用されます。これはやや不注意です。

PVS-Studioはこのような脆弱性の検出にどのように対処しますか？それは完全に落ち着いています：アナライザーは、nullポインターでの作業を検出するさまざまな診断ルールを実装しています。

特に、上記の脆弱性は診断ルールV575を使用して検出されます。警告は次のとおりです。

V575潜在的なヌルポインターが 'memcpy'関数に渡されます。最初の引数を調べます。

アナライザーは、 calloc関数の呼び出しによって取得された潜在的にnullのポインターがNULL不等式をチェックせずにmemcpy関数に渡されることを発見しました。

したがって、PVS-Studioもこの脆弱性を発見しました。しかし、アナライザーがコードを記述するプロセスで定期的に使用されていた場合、この問題はバージョン管理システムに入る前であっても防ぐことができました...

MySQL

写真8

MySQLは無料のリレーショナルデータベース管理システムです。通常、MySQLはローカルまたはリモートクライアントからアクセスされるサーバーとして使用されますが、ディストリビューションには、MySQLをスタンドアロンプログラムに含めることができる内部サーバーライブラリが含まれています。

このプロジェクトで発見された脆弱性の1つであるCVE-2012-2122を検討してください。

CVE-2012-2122説明： Oracle MySQL 5.1.xより前の5.1.x、5.5.24より前の5.5.x、5.6.6より前の5.6.x、および5.1.62より前のMariaDB 5.1.xのsql / password.c 5.2.xより前の5.2.x、5.3.xより前の5.3.6、5.5.xより前の5.5.xは、 memcmp関数の特定の実装を使用して特定の環境で実行する場合、同じもので繰り返し認証することにより認証をバイパスすることができます誤ったパスワード。これにより、戻り値が正しくチェックされなかったため、最終的にトークン比較が成功します。

脆弱性を含むコードは次のとおりです。

 typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }

memcmp関数の戻り値の型はintであり、 check_scramble関数の戻り値の型はmy_bool 、実際にはcharです。その結果、 intは charにキャストされ、 そこで最上位ビットが破棄されます。これにより、256のうち約1ケースで、ユーザー名を知っている任意のパスワードで接続することができました。 300回の接続試行に1秒もかからなかったため、この保護は不在と同じくらい良好です。この脆弱性の詳細については、 CVE-2012-2122ページに記載されているリンクを参照してください。

PVS-Studioは、 V642診断ルールを使用してこの問題を検出します。警告は次のとおりです。

V642 'memcmp'関数の結果を 'char'型変数内に保存するのは不適切です。プログラムのロジックを壊して、重要なビットが失われる可能性があります。 password.c

この脆弱性はPVS-Studioを使用して発見されたことが判明しています。

iOS

写真9

iOSは、アメリカの会社Appleによって開発および製造されたスマートフォン、電子タブレット、およびポータブルプレーヤー用のモバイルオペレーティングシステムです。

このオペレーティングシステムがさらされた脆弱性の1つ、 CVE-2014-1266を検討してください。幸いなことに、パブリックドメインには、問題の内容を示すコードがあります。

CVE-2014-1266の脆弱性の説明 ：Apple iOS 6.xより前の6.1.6および7.xより前の7.0.6、Apple TVのデータセキュリティコンポーネントのセキュアトランスポート機能のlibsecurity_ssl / lib / sslKeyExchange.cのSSLVerifySignedServerKeyExchange関数6.0.2より前の6.x、および10.9.2より前のApple OS X 10.9.xは、TLSサーバーキー交換メッセージの署名をチェックしません。これにより、中間者攻撃者が（1）によりSSLサーバーをスプーフィングできるようになります。署名ステップに任意の秘密鍵を使用するか、（2）署名ステップを省略します。

脆弱性につながったコードの断片は次のように見えました。

 static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }

問題は、隣同士にある2つのgotoステートメントです。これらの演算子のうち、最初の演算子のみがifステートメントを参照し、2番目の演算子は参照しません。したがって、前の条件の値に関係なく、失敗ラベルへの移行が実行されます。 2番目のgotoステートメントの実行により、 errは成功します。これにより、攻撃者がSSLサーバーを偽装する可能性が生じました。

PVS-Studioは、2つの診断ルール（ V640とV779）を使用してこの問題を検出します。警告は次のとおりです。

V640コードの操作ロジックがそのフォーマットに対応していません。ステートメントは右側にインデントされますが、常に実行されます。中括弧が欠落している可能性があります。
V779到達不能コードが検出されました。エラーが存在する可能性があります

したがって、アナライザーは、彼にとって疑わしいと思われるいくつかのことについて一度に警告します。

プログラムのロジックはコードの設計に対応していません。アライメントによって判断すると、両方のgotoステートメントはifステートメントに属しているようですが、そうではありません。最初のgotoステートメントは実際に条件の影響を受けますが、2番目のステートメントはそうではありません。
到達不能コードの存在：2番目のgotoステートメントは無条件に実行されるため、それに続くコードは実行されません。

ここで、PVS-Studioが正常に機能したことがわかります。

静的解析の効果的な使用

この記事の目的は、前述したように、PVS-Studioが脆弱性検索を正常に処理することを示すことです。この目標を達成するために選択されたアプローチは、アナライザーがいくつかの既知の脆弱性を検出することを実証することです。上記の資料は、静的分析を使用して脆弱性を探ることができるという事実を確認するために必要でした。

次に、これを最も効果的に行う方法についてお話ししたいと思います。理想的には、脆弱性はそのようになる前に発見する必要があります（つまり、誰かがそれらを発見し、それらがどのように悪用される可能性があるかを理解したとき）。静的分析を適切に使用すると、コーディング段階でも脆弱性を検出できます。これをどのように達成できるかを以下に説明します。

ご注意 このセクションでは、一貫性を保つために、「エラー」という言葉を使用します。しかし、これまで見てきたように、単純なエラーは潜在的な脆弱性である可能性があります。忘れないでください。

一般的に、バグが早期に検出され修正されるほど、修正コストは安くなります。以下の図は、Capers Jonesの書籍「Applied Software Measurement」のデータを示しています。

写真1

グラフからわかるように、コーディング段階で約85％のエラーが発生しますが、この段階での修正コストは最小限です。同時に、プログラムコードにエラーが存在するため、それを修正するコストは絶えず増加します。コーディング段階でエラーの解消に約25ドルかかる場合、ソフトウェア製品のリリース後、この数字は数万ドルに増加します。リリース後に発見された脆弱性のコストは、話す価値さえありません。

これから簡単な結論が得られます-エラーが検出されて修正されるのが早ければ早いほど良いです。静的分析の目的は、コードのエラーをできるだけ早く検出することです。静的解析は、他のソフトウェア検証および検証ツールの代替ではありませんが、それらを補完します。

静的アナライザーを使用する利点を最大化する方法は？最初のルールは、コードを定期的にチェックすることです。理想的には、エラーはバージョン管理システムに組み込まれる前に、コードを記述する段階でも修正される必要があります。

ただし、開発者のマシンで進行中のチェックを実行するのは不便かもしれません。さらに、コード全体をチェックする操作は非常に長くなる可能性があり、編集後のコードのダブルチェックを防ぐことができます。 PVS-Studioでは、このためにインクリメンタル分析モードが実装されており、前回のビルド以降に変更/影響を受けたコードのみを分析できます。さらに、この機能を使用すると、アセンブリ後に分析を自動的に実行できるため、分析の独立した起動によって開発者が邪魔されることがなくなります。分析が完了した後、変更されたファイルでエラーが検出された場合、プログラマーに適切な通知が与えられます。

そのような条件下でも、バージョン管理システムにエラーが入ることがあります。したがって、「第2レベルの保護」、つまりビルドサーバーでの静的アナライザーの使用が必要です。たとえば、コード分析を夜間のビルドプロセスに統合します。これにより、夜間や午前中にプロジェクトを定期的にチェックして、バージョン管理システムにどのエラーが発生したかに関する情報を取得できます。この場合の重要なポイントは、この方法で検出されたエラーを迅速に修正する必要があることです-できればすぐに翌日。そうでなければ、時間の経過とともに、誰も新しいエラーの出現に注意を払わなくなり、そのようなチェックから意味がなくなります。

開発プロセスに静的分析を導入することは、プロジェクトがゼロから開発されていない場合、重要なタスクのように思えるかもしれません。この場合に静的分析の使用を開始する方法については、記事「大規模プロジェクトで静的分析を迅速に実装する方法」を参照してください。

おわりに

次のことをお見せできたと思います。

単純な一見バグであっても、深刻な脆弱性になる可能性があります。
PVS-Studioは、コード内のエラーの検索だけでなく、CWEおよびCVEの検索も正常に処理します。

そして、コードの単純なエラーのコストが時間とともに大幅に増加する場合、脆弱性のコストについて言うことはありません...さらに、静的分析を使用する場合、多くの脆弱性はバージョン管理システムに入る前でも修正できます誰かが見つけて活用するために。

最後に、プロジェクトでPVS-Studioを試してみることをお勧めします-突然、プロジェクトがCVEデータベースに入らないようにする興味深いものを見つけることができます。

サイトリンク

この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：セルゲイヴァシリエフ。 PVS-Studioは脆弱性の検出にどのように役立ちますか？

記事を読んで質問がありますか？

多くの場合、記事には同じ質問が寄せられます。ここで回答を収集しました： PVS-Studioバージョン2015に関する記事の読者からの質問への回答。リストをご覧ください。

PVS-Studioは脆弱性の検索にどのように役立ちますか？