サードパーティの依存関係セキュリティ-snykで確認

最近、素晴らしい出版物「私はあなたのサイトの訪問者からクレジットカード番号とパスワードを盗む方法の物語」がありました、私はそれに答えを翻訳しました 。 著者は最近第2部を公開しましたが、翻訳はないと思われます-重要な入力要素を「個別のiframeに」または「サードパーティのjavascriptのない特別なページに」翻訳するなど、すばらしい方法で問題を解決することが提案されています。 この時点で、最初の記事に依存した人は著者の妥当性を疑うべきでした。これは、新しい記事の低い評価（以前の評価に比べて）を示しています。



UPD ： 同じものを翻訳しました 。



それにもかかわらず、サードパーティの依存関係の問題があり、何らかの方法で解決する必要があります。 さらに、サードパーティの依存関係が使用されるどのエコシステムでも同様に機能します。 最後の投稿へのコメントで、彼らはすでに何らかの解決策を求めていたので、そのうちの1つ、snykと呼ばれるツールを紹介したいと思います。









Snykは非常に人気のあるツールですが、ハブについてはまだ言及していません。 多くのエコシステム（Javascript、Ruby、Python、Scala、Java）の依存関係をベースに対してチェックできます-そして、著者は脆弱性データベースが大きいと主張しています。 自分の目で見ることができます。 プロジェクトコードは開いており、githubにあり、かなりの数のスターとフォークがあります。

主な機能

説明はプロジェクトのウェブサイトから取られており、マーケティングのでたらめを割引します。 個人的な印象は低くなります。

検索する

• Javascript、Ruby、Python、Scala、およびJavaの脆弱性ファインダー
• GitHubリポジトリの確認
• 使用前にオープンソースパッケージを確認する
• Snyk独自の脆弱性データベースが使用されます

モニタリング

• アプリケーションの依存関係チェック
• CIプロセスでの統合
• リアルタイムの脆弱性アラート
• AWS LambdaおよびHerokuでのアプリケーションサポート

訂正

• 脆弱な依存関係を更新または修正する
• SnykからNode.jsおよびRubyのgihubリポジトリへの自動プルリクエスト
• 選択した修正を含むプルリクエスト
• 迅速な修正のための対話型アシスタント
• プロジェクトに影響する新しい脆弱性の通知
• Slackの通知および脆弱性とその修正に関する電子メールによる通知
• 関係の明確な分析

？ handlebars@3.0.0にある重大度の高い脆弱性、

handlebars@3.0.0経由で導入

-desc：コンテンツインジェクション（XSS）

-情報： snyk.io/vuln/npm ：ハンドルバー：20151207

調停オプション

> handlebars@4.0.0へのアップグレード（潜在的に重大な変更）

パッチ（パッチはありません。パッチがある場合はお知らせします）

30日間無視するように設定（ポリシーを更新）

スキップする

予防

• Snykは、Node.js、Ruby、Python、Scala、およびJavaアプリケーションを脆弱にするプル要求をテストできます。
• 自動テストのためにCIでSnykを使用できます。
• ニーズと優先度に応じて、必要なセキュリティレベルを設定できます。

統合

• githubリポジトリの自動監視
• CIプロセスへのSnykの追加
• チームに合わせてカスタマイズ可能な柔軟なポリシー

チームワーク

• チームワークにSnyk組織を使用する
• 管理者とメンバーの役割
• チームの誰でも脆弱性を検索して修正できます。
• 新しい脆弱性は、適切な人にのみ通知されます。

トレーニング

• それらについて時間内に学ぶために脆弱性データベースを購読します
• 脆弱性を悪用する方法とそれらを修正する方法を学びます。

個人的な印象

設置

あなたはこのことを非常に迅速に試すことができます-それをやって

npm install -g snyk cd ~/projects/myproj/ snyk test
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、ご理解のとおり、ツール自体はNode.JSで記述されており、npmが必要です。 また、サイトにログインする必要があります。これは、いくつかのサービス（github、google、bitbucket）で実行できます。 さらに、インストールせずにサイトでパッケージをテストし、 このような明確なレポートを取得できます。 もちろん、次のような美しいバッジを取得できます。







当然、これをCIに統合することもできますが、すべてが明白なので、私はそれについて書きたくありません。

使用する

snykをインストールした後、動作します。 これまでのところ、Node.JSプロジェクトでのみ試してみましたが、不快な後味が残っていました。 少なくとも、node_modulesディレクトリがない場合や空のnode_modulesディレクトリでは、チェックは依存関係がないと見なし、これはプロジェクトですべてが正常であることを意味します。 あなたがあなたの手でそれらを取り壊すことができ、それらが完全に確立されなかったなどの事実は考慮されていません。 しかし、一般的に、レポートは非​​常に良いことが判明しました-本質的には、すべては最新の依存関係を維持する必要があるという事実に帰着します。 これは、特別なツールなしで非常に明白です。 ただし、新しいメジャーバージョンへの「単なるアップグレードとアップグレード」が常に可能であるとは限らないこと、また、監視ツールが時間内に警告した重大な脆弱性の存在が、これを長い「明日」延期しない良い動機となる可能性があることは誰もが知っています。









プロジェクト自体のコードの品質を少し混乱させます。 私はそれがES5で書かれていることをあまり混同していません（しかし、なぜプロジェクトでは大丈夫ですか？）-しかし、コード自体はあまり見栄えがよくありません。 また、プルリクエストでアクティブな作業が表示されないことも悲しくなります（ たとえば、私の場合、 node_modulesで上記の問題を判断したばかりで、実際、 23分の2が受け入れられたようです ）。 モジュールの更新とセキュリティに関連するプロジェクト自体に多数の古い依存関係が含まれており、多数の異なる「自転車」が含まれているのは奇妙です。



繰り返しますが、私はプロジェクトのマーケティングの量に多少混乱しています。 たとえば、検証プロセス自体は脆弱性チェックと呼ばれ、バッジには脆弱性の数が表示されます。 そうではありません。 snykがチェックする最大値は脆弱性ですが、脆弱性ではありません。 これらの概念を単に置き換えることはできません。 同様に、依存関係を含まないプロジェクトに脆弱性がないことを示すことはできません。 これは、概念のひどい代替です。 これは単なる私の妄想である可能性があります-SSLを使用する場合、ブラウザの緑の城と「セキュア」サインはひどく偽善的であると考えています...



なるほど、このプロジェクトには大きなプラスがある-それは動作します。 需要があり、開発中です。 だから私は彼が良くなることを心から願っており、いつか私たちのプロジェクトにおける依存性の脆弱性の世界的な問題に対する良い信頼できる解決策があることを願っています。