ソースコードのセキュリティをどのようにチェックすべきですか？
オープンソースプロジェクトのソースコードに悪意のあるコンテンツが含まれていないかどうかを確認する方法たとえば、全体で30,000行のソースコードファイルのセットでは、悪質なステートメント（たとえば、curl http://... | bash）。
これらのプロジェクトはよく知られていないし、それらがよく維持されていると仮定することはできません。したがって、プロジェクトのソースコードを再利用する場合のセキュリティは、単に盲目的な信頼に依存することはできません（cmakeを直接ダウンロード、検証、コンパイル、実行しても安全であると合理的に想定されているはずですが、聞こえませんGitHubでホストされている任意のライブラリを盲目的に使用することをお勧めします）。
誰かが、ソースコードをフィルタリングして、ASCII以外のすべての非表示文字（改行などのささいなものを除く）を削除することを提案しました。次に、各ファイルをテキストエディタで開き、手動ですべての行を読みます。これは多少時間がかかり、コードを読むときに十分な注意を払う必要があり、実際にはかなりエラーが発生しやすくなります。
そのため、このような状況に対処するための一般的な方法を探しています。たとえば、利用可能な標準ツールはありますか？手動で読む必要がある場合に注意する必要があることはありますか？
自動化されたアプローチと手動のアプローチがあります。
自動化の場合、 lgtm -オープンソースプロジェクト用の無料の静的コードアナライザーから始めて、より複雑なSASTソリューションに移行できます。
手動の場合-アプリの脅威モデルを構築し、最も重要な部分から始まる OWASP ASVS チェックリストを実行できます。脅威モデルにファイルの削除がある場合は、次のように呼び出します：grep -ir 'os.remove('。
もちろん、両方を組み合わせる方が良いでしょう。
自分で行うか、他の誰かを信頼する
人生のほとんどのことと同じように、あなたは自分でそれをするか、それを使って誰かを信頼しなければなりません。ここでtrustingは、悪意がないことと、タスクを適切に実行するのに十分な能力があることの両方をカバーしています。
たとえば、税を申告するyourselfまたはtrust税務顧問そうすること（あなたをだまそうとするだけでなく、税金を申告する方法も知っているはずです！）.
あなたが会社である場合、単独でそれを行うことは実際には1人または複数の従業員によって実行され、次に信頼される必要があります。
あなたが信頼する第三者も、一人である必要はありません。 Microsoft Windows開発チーム、またはWordpressコア開発者 。
ソースコードのセキュリティについては、専門家が善意を示すだけでなく、安全な方法でプログラムをコーディングする知識があり、そこに存在する可能性のある潜在的なセキュリティの問題を見つける必要があります。
（さらに、全体として扱う場合のいくつかの追加の境界システム、たとえば、コードがリポジトリにアップロードされている間にコードが危険にさらされないようにしたい、または結果がネットワーク内の悪意のあるハッカーに置き換えられたことを示す従業員からの電子メールアプリケーションは大丈夫だったと言うために）
オプションを評価し、それぞれに関連するリスクを評価して、自分の興味（および予算！）に最適なパスを選択する必要があります。
Wordpressを使用したブログのソースコードのセキュリティをチェックする場合、通常は元のコードが問題ないことを信頼し、違いをチェックします1公式バージョンと使用済みバージョンの間。 Webサイトが侵害された場合、その発見ははるかに容易になります。
later古いバージョンを使用していた場合は、それ以降のバージョンの変更ログを明らかに確認します。
しかし、所有者の甥によって開発されたものであれば、そこに多くの脆弱性が見つかると予想し、すべてを徹底的にチェックすることをお勧めします。
あなたのケースでは、そのライブラリと同等のライブラリを開発するリスクとコストを評価する必要があります（自社製品で問題が発生する可能性もゼロではないことを考慮に入れてください。関係者）とそのライブラリの監査および使用のリスクとコストの比較。
現在、監査を簡素化する減衰要因があるかもしれません。たとえば、信頼されていないコードが分離された仮想マシンで実行できる場合、それ以上の監査は不要です（ここでも、VM実装を信頼しています）。または、 rootとして実行されるプログラムの部分を監査するのに十分です。
ライブラリを監査する場合、コードアナライザーは（指摘されたように）問題のある部分を指摘するのに役立ちますが、それがクリーンであると考えるためには、実際に誰かに読んでもらい、理解してもらいます表面的にであっても、コード。
たとえば、任意のファイルを削除する機能は悪意のあるものではありませんそれ自体。それが理にかなっているかどうかを知るためには、プログラムを理解する必要があります。
繰り返しますが、それはあなたがしていることに対する脅威とリスクの問題です。ライブラリがデータを抽出することだけに関心がある場合は、ファイアウォールでの接続のフィルタリングで十分です。ライブラリが重要なファイルを削除することに懸念がある場合（そして、奇妙な理由でそのようなアクセス許可を拒否できない場合）は、数学的計算のみを実行する一連のコードをスクロールするだけで済みます。そのライブラリーがロケットを発射するためのパラメーターを計算する場合は、まあ、それらの計算が正しいことも確認してください！
サービスを利用する
オープンソースの依存関係を監査する Black Duck や Whitesource などの専門的なサービスがあります。
誰か他の人のコードを使用する場合、メンテナが提供する整合性メカニズムのなすがままになります。これは、オープンソースだけでなく、すべてのソフトウェアに当てはまります。
商用およびパッケージ化されたオープンソースソフトウェア（rpm、debなど）の両方でコード署名が一般的です。これは、受け取った署名者が受け取ったものであることを証明します。
ソースコードの場合、通常チェックサムが使用されます。しかし、チェックサムがソースコードの別のソースからアクセス可能でない限り、これはほとんど価値がありません。
これらは、アプリケーションに対するMITMタイプの攻撃からの保護のみを目的としていることに注意してください。
gitHubでホストされている任意のライブラリを使用する
...その場合、すべてのファイル/バージョンにGithubで公開されたハッシュがあります-これを覆すために、攻撃者はGithub自体またはメンテナのGithubアカウントを覆す必要があります-Githubで何かをフォークできますが、その原因は私と元のリポジトリは、メンテナが私のプルリクエストを受け入れない限り影響を受けません。コードのメンテナーよりもGithubの整合性に自信があるかもしれません。その場合、ソースコードと同じ場所に公開されているハッシュを信頼するのが妥当です。
これらのメカニズムは、整合性検証が適用される前に挿入されたマルウェアに対する保護を提供しません。
ソースコードにアクセスできる場合は、コードを検査するオプションがあり（実行可能ファイルを検査するよりもはるかに簡単です）、オドが提案するような自動化ツールがあります。
静的アナライザーは常に機能するとは限りません
コード内の_os.remove_のチェックは、一部のユーザーが単にeval("os" + ".remove")を実行する可能性があるため、すべての攻撃者に機能するわけではありません。より高度な正規表現を作成することもできますが、攻撃者は常にコードをより複雑にすることができます。
_x = "r"
eval("os." + x + "emove")
_より理論的には、停止の問題により、すべての潜在的な状態をチェックして、危険なシステムコールが呼び出されたかどうかを確認することは不可能です。
攻撃者は、悪意のある操作を実行するカスタム言語用の小さなインタープリターを作成することにより、静的コードアナライザーを簡単に回避できます。
コンテナー/ハニーポット内でコードを実行する
すべてのソフトウェアは最終的にオペレーティングシステムと対話します。 straceまたは同様のツールを使用してコンテナーまたはハニーポット内でソフトウェアを実行することにより、プログラムまたはライブラリが収集しようとしている情報を確認できます。
プログラムは、コンテナー内で実行されているかどうかを判断しようとしますか？想定されていないファイルを読み取ったり、変更したりしますか？次に、悪意のあるソフトウェアを使用している可能性があります。
これは常に機能するとは限らず、手動による検査が必要になる場合があります
一部の悪意のあるコードは特定の日付でのみトリガーされますが、少なくともこれがアクセスされていることがわかります。そこから、コードのどこでこれが発生し、その理由を調べることができます。