ブログへようこそ

なぜここに？

Dockerのセキュリティに関する2つの質問に対する本当の答えを知りたい：

Dockerは本番環境でも安全か？

はい、違います。Dockerは名前空間とリソースの分離に依存するセキュリティモデルを使用しており、クラウドVMやベアメタルシステムから直接アプリケーションを実行するよりも、特定の攻撃からコンテナ内のプロセスをよりセキュアにします。

Dockerのセキュリティを（ひどく苦痛を伴わない方法で）向上させるにはどうすればよいでしょうか？

公式イメージの使用やホストを最新の状態に保つといった、Googleのあちこちにあるような基本的な推奨事項を飛ばして、最も一般的で深刻なDockerの脆弱性について説明します。代わりに、新しいデフォルトのDockerコンテナのデプロイメントをこれまでよりもはるかに安全にする、新しいdockerオプションやDockerfileの行を直接紹介します。

ノーBSのDockerセキュリティ・チェックリスト

コンテナ内ファイルシステムを読み取り専用にする

何が得られるのか？

攻撃者がDockerコンテナの実行環境を編集できないようにすることで、インフラに関する有益な情報を収集したり、ユーザーデータを収集したり、DOSやランサムウェア攻撃を直接行ったりできるようになります。

どのように設定するのですか？

実行時またはDocker Composeの設定内で、2つのオプションがあります。

実行時に： docker run --read-only your-app:v1.0.1

Docker Composeファイルに

サービス
webapp：
image: your-app:v1.0.1read_only: true
...

ロック権限の昇格

何が得られるのか？

setuidやsetgidを使うことで、Dockerコンテナや、コンテナ内部で悪さをする攻撃者が、新しい特権（rootレベルでも）を有効にできないようにすることができます。コンテナへのアクセスがより許可されるようになると、攻撃者はパスワードやデータベースなど、デプロイの接続部分へのキーの形で認証情報にアクセスできるようになります。

どのように設定するのですか？

もう一度、実行時またはDocker Composeの設定内で。

実行時に： docker run --security-opt=no-new-privileges your-app:v1.0.1

Docker Composeファイルに

サービスを提供する： 
	webapp：    
		image: your-app:v1.0.1    
		security_opt：     
			-no-new-privileges:true    
...

コンテナ間ネットワークの分離

何が得られるのか？

デフォルトでは、Dockerはすべてのコンテナをdocker0ネットワーク経由で通信させるため、攻撃者は侵害されたコンテナから別のコンテナへと横方向に移動できる可能性がある。個別のサービス A そして B 容器入り Y そして ZDockerのセキュリティを向上させるために横方向の移動を防止しながら、ネットワークを分離することで、同じエンドユーザー・エクスペリエンスを提供します。

どのように設定するのですか？

Dockerネットワークは、実行時またはDocker Compose設定内で指定することができます。ただし、最初にネットワークを作成する必要があります：

docker network create your-isolated-network

実行時に --ネットワークオプションn: docker run --network your-isolated-network your-app:v1.0.1

または、Docker Composeファイルの同等のオプション：

サービスを提供する： 
	webapp：    
    	 image: your-app:v1.0.1    
        networks：     
        	- 分離されたネットワーク    
		...

適切な非 root ユーザーを設定する

何が得られるのか？

コンテナ内のデフォルトユーザーは ルートuidは 0. 別個のユーザを指定することで、攻撃者がrootのような制限なしにアクションを実行できる別のユーザに権限をエスカレートさせることを防ぎます。

どのように設定するのですか？

ビルド・プロセス中またはランタイム中にユーザーを作成します。実行時に、初めてユーザーを作成するか、あるいは ユーザー はビルド時に設定済みである。

ビルドの過程で ドッカーファイル:

...
RUN groupadd -r your-user
RUN useradd -r -g your-user your-user
ユーザー myuser
...

‍

実行時に： docker run -u your-user your-app:v1.0.1

Linuxカーネルの機能を落とす

何が得られるのか？

デフォルトでは、DockerコンテナはLinuxカーネル機能の制限されたセットの使用を許可されている。Docker社の人々は、完全にセキュアにするためにこの制限されたセットを作ったと思うかもしれないが、多くの機能は互換性とシンプルさのために存在している。例えば、デフォルトのコンテナは、ファイルの所有権を任意に変更したり、ルート・ディレクトリを変更したり、プロセスのUIDを操作したり、ソケットを読んだりできる。これらの機能の一部またはすべてを削除することで、攻撃ベクトルの数を最小限に抑えることができる。

どのように設定するのですか？

実行時に能力を削除したり、新しい能力を設定したりできる。たとえば、すべてのカーネル機能を削除して、コンテナには既存のファイルの所有権を変更する機能だけを許可することができる。

docker run --cap-drop ALL --cap-add CHOWN your-app:v1.0.1

‍

またはDocker Composeの場合：

サービス
	webapp：
    	 image: your-app:v1.0.1
        cap_drop：
        	- すべて
        cap_add：
        	- CHOWN
        ...

フォーク爆弾を防ぐ

何が得られるのか？

フォークボムは、既存のプロセスを無限に複製するDoS攻撃の一種である。まずパフォーマンスを低下させリソースを制限するため、必然的にコストが上昇し、最終的にはコンテナやホストシステムをクラッシュさせる可能性がある。いったんフォークボムが始まると、コンテナやホストを再起動する以外に止める方法はない。

どのように設定するのですか？

実行時に、コンテナが作成できるプロセス（PID）の数を制限できる。

docker run --pids-limit 99あなたのアプリ:v1.0.1

‍

あるいはDocker Composeを使う：

サービス
	webapp：
		image: your-app:v1.0.1
デプロイ
			制限
				pids: 99

‍

オープンソースの依存関係を監視してDockerのセキュリティを向上させる

何が得られるのか？

Dockerでデプロイするためにコンテナ化したアプリケーションは、おそらく幅広い依存関係のツリーを持っている。

どのように設定するのですか？

最も "非BS的 "な方法は、Aikido オープンソース依存性スキャンです。私たちの継続的なモニタリングは、アプリケーション内のロックファイルの存在に基づいて、12以上の言語で書かれたプロジェクトをスキャンし、脆弱性とマルウェアの概要を即座に提供します。偽陽性をフィルタリングする自動トリアージにより、Aikido 、あなたが他の多くの参考文書やGitHubの問題を読んだ後だけでなく...すぐに作業を開始できる修復アドバイスを提供します。

Aikido、Trivy、Syft、Grypeのような確立されたオープンソース・プロジェクトが大好きです。また、これらのプロジェクトを単独で使用することは、開発者にとって特に良い経験にはならないことも経験から知っています。Aikido 、これらのプロジェクトをカスタム・ルールで強化することで、ギャップを埋め、他の方法では見つけられないようなセキュリティ上の欠陥を明らかにします。様々なオープンソースのツールを連結して使うのとは異なり、Aikido 、スキャンスクリプトを構築したり、CI/CDでカスタムジョブを作成したりする必要から解放します。

Dockerのセキュリティのために信頼できるイメージのみを使用する

何が得られるのか？

Docker Content Trust (DCT)は、Docker HubのようなDockerレジストリから取り出した公式イメージに署名し、その内容と完全性を検証するシステムです。作者によって署名されたイメージのみをプルすることで、デプロイに脆弱性を生じさせるような改ざんがされていないことをより確実にすることができます。

どのように設定するのですか？

最も簡単な方法は、シェルに環境変数を設定することで、あなたや他の人が信頼できないイメージで作業するのを防ぐことができる。

exportDOCKER_CONTENT_TRUST=1
docker run ...

あるいは、Dockerを実行するたびに環境変数を設定することもできる：

docker_content_trust=1docker run ...

製造終了（EOL）ランタイムの更新

何が得られるのか？

Dockerコンテナのセキュリティに関する一般的な推奨事項の1つは、イメージと依存関係を特定のバージョンに固定することです。 最新.理論的には、改ざんされたものであっても、新たな脆弱性をもたらす新しい画像を無意識のうちに使用することを防ぐことができる。

どのように設定するのですか？

EOLを発見し、最善の準備をするのに役立つオープンソースのプロジェクトがいくつかある。endoflife.dateプロジェクト（GitHubリポジトリ）は、複数のソースからのデータを集約し、公開APIを介して利用できるようにすることで、300以上の製品を追跡している。endoflife.dateや同様のプロジェクトにはいくつかの選択肢がある：

• アプリケーションが依存している依存関係のアップデートがないかプロジェクトを手動でチェックし、必要なアップデートのチケットや課題を作成します。
• APIから依存関係のEOL日を取得するスクリプト（Bash、Pythonなど）を書き、cronジョブのように定期的に実行する。
• 公開API、またはカスタムスクリプトをCIプラットフォームに組み込んで、EOLに近い、またはEOLに達したプロジェクトを使用するビルドを失敗させる。

開発者として、あなたの時間は貴重であり、しばしば限られていることを理解しています。そこでAikido EOLスキャン機能は、Node.jsやNginxウェブサーバのように、最も影響と露出のあるランタイムを優先的に、コードとコンテナを追跡します。いつものように、Aikidoは情報収集を自動化するだけでなく、適切な重要度を持つアラートを配信し、ユーザを圧倒するのではなく、情報を提供します。

コンテナ・リソースの使用を制限する

何が得られるのか？

デフォルトでは、コンテナにはリソース制約がなく、ホストのスケジューラと同じだけのメモリやCPUを使用する。特定のコンテナの リソース使用量を制限することで、DoS攻撃の影響を最小限に抑えることができます。Out of Memory Exceptionによってコンテナやホストシステムがクラッシュする代わりに、進行中のDoS攻撃はエンドユーザーエクスペリエンスに悪影響を与える「だけ」になります。

どのように設定するのですか？

実行時に --メモリ そして --CPU オプションを使用して、それぞれメモリと CPU の使用量の上限を設定する。メモリ・オプションは、g がギガバイト、m がメガバイトの数値をとり、CPU オプションは、コンテナとそのプロセスで使用可能な専用 CPU の上限を反映する。

docker run --memory="1g"--cpus="2"あなたのアプリ:v1.0.1

これはDocker Composeでも使える：

サービス
	webapp：
    	 image: your-app:v1.0.1
        deploy：
            limits：
            	 cpus: '2'
                memory: 1G
         ...

Dockerセキュリティのための最後のコマンドとComposeオプション

今までに、あなたはかなりの数のDockerセキュリティのヒントと、それらに関連するCLIオプションや設定を見てきました。以下では、より安全なDockerコンテナのデプロイをすぐに始められるように、推奨事項を1つのコマンドや設定テンプレートにまとめました。

もちろん、非rootユーザー名、カーネル機能、リソース制限などのオプションのいくつかは、アプリケーションのニーズに応じて変更したい。

exportDOCKER_CONTENT_TRUST=1
docker run  \ 
    --read-only  
    --read-only--security-opt=no-new-privileges 
    --network your-isolated-network ￤ --cap-drop ALL  
    --cap-drop ALL 
    --cap-add CHOWN  
    --pids-limit 99 
    --memory="1g" --cpus="2" ୧--user=your-user 
    --ユーザー=ユーザー  
    ...                 # その他のオプションはこちら  
    your-app:v1.0.1

ホストのシェルでdrunエイリアスを作成し、詳細を覚えていなくても呼び出せるようにするのもいいだろう。

関数 drun  { 
docker run   
    	--読み取り専用    
       --security-opt=no-new-privileges \
        --network your-isolated-network ˶ --cap-drop ALL   
        --cap-drop ALL 
        --cap-add CHOWN    
        --pids-limit 99 
        --memory="1g" --cpus="2" ୧--user=your-user   
        -user=your-user ୧-͈ᴗ-͈ᴗ    
        $1\ 
       $2
}.

次に、オプションとイメージ名を指定して、エイリアスを次のように実行する。

もしあなたがDocker Composeを使う人であれば、同じオプションをすべて、今後作業できる新しいベースラインDocker Composeテンプレートに適応させることができます：

サービス
	webapp：
    	 image: your-app:v1.0.1
        read_only: true
        security_opt：
           -no-new-privileges:true
        networks：
           - 分離されたネットワーク
        cap_drop：
           - すべて
        cap_add：
           - CHOWN
        デプロイ
        	limits：
        		 pids: 9
        		 cpus: '2'
        		memory: 1G
        ...               # その他のオプションはこちら

おまけ：ルートレスコンテナでDockerを動かす

Dockerを任意のシステムにインストールすると、そのデーモンはrootレベルの特権で動作します。上記のオプションをすべて有効にし、Dockerコンテナ内での権限昇格を防いだとしても、ホストシステム上のコンテナランタイムの残りの部分は依然としてルート権限を持っています。そのため、必然的に攻撃対象が広がってしまいます。

その解決策がルートレス・コンテナであり、非特権ユーザーが作成・管理できる。root権限が必要ないということは、ホスト・システムのセキュリティ問題がはるかに少ないことを意味する。

1つのオプションやコマンドでルートレス・コンテナを使う手助けができればいいのだが、そう簡単にはいかない。ルートレス・コンテナのウェブサイトには、Docker用のハウツー・ガイドを含む詳細な手順が掲載されている。

Dockerセキュリティの次は？

‍

この経験から何かを学んだとしたら、それはコンテナ・セキュリティは長丁場の作業だということだ。Dockerやその古く、誤解されがちな従兄弟であるKubernetesのコンテナをロックダウンするための堅牢化チェックリストや深く掘り下げた記事は、いつでも読むことができる。多忙な開発スケジュールの中にセキュリティに取り組む時間を作り、影響度と重大性に基づいて段階的に改善することで、長い時間をかけて長い道のりを歩むことができます。

このような継続的なプロセスを最大限に活用し、アプリケーション・セキュリティを有意義に改善するための修正に優先順位をつけるために、次のようなものがあります。 Aikido.私たちは、"ノー・BS "開発者セキュリティ・プラットフォームのために、1,700万ドルのシリーズAを調達したばかりです。

‍

なぜここに？

JavaScriptによるSQLインジェクション攻撃について耳にしたことはあるだろうが、実際にどのようなものなのか、そもそも心配する必要があるのか、まったくわからない。もしかしたら、それがどの程度悪いものなのか把握しようとしているかもしれない。

要するに、MySQLやPostgreSQLのようなSQLデータベースを使用してアプリケーションを構築している場合、あなたは危険にさらされているのです。開発者としては、ユーザーデータを保護するガードレールを実装し、基礎となるインフラが決して侵入されたり、探索されたり、徴用されたりしないようにする責任があります。

新しいツールはすべて、あなたを助けると言っているが、開発をより複雑にしているだけだ。

Sequelizeや TypeORMの ようなオブジェクトリレーショナルマッパー（ORM）を追加することで、MySQLやPostgreSQLのようなSQLデータベースでの作業を簡素化することはできるが、リスクを完全に回避できるわけではない。ウェブアプリケーションファイアウォール（WAF）は、ネットワークレベルでの攻撃をブロックするのに役立つが、高価なインフラと継続的なメンテナンスが必要だ。コードスキャナー（Code Scanner）は、明らかな欠陥を特定するのに役立つが、未知の未知数や潜んでいるゼロデイテクニックに対しては、ほとんど役に立たない。

SQLインジェクション攻撃がどのようなもので、どのようなリスクがあり、どのような開発ミスがSQLインジェクション攻撃を可能にしているのかを明確に説明します。そして、グローバルなHotfixのインストール方法を説明することで、お客様のアプリが安全であることを確実にお伝えします。

SQLインジェクション攻撃の例とその影響

SQLインジェクション攻撃の最も基本的な定義は、アプリがデータベースクエリを実行するために、検証もサニタイズもされていないユーザー入力を許可することで、攻撃者がSQLデータベースを読んだり、レコードを変更したり、思いのままに削除したりできるようにすることです。

いつものように、XKCDはSQLの危険性を、私たちが夢見るような暗いシナリオよりもうまく説明している：

脆弱なJavaScriptアプリはどのようなものか？

簡単な擬似コードの例から始めましょう。ユーザーが猫のデータベースを検索できる入力要素を持つJavaScriptアプリです。以下のJavaScriptコード例では、アプリは/catsパスのPOSTリクエストに応答して、リクエストボディからユーザー入力を抽出し、一致するidを持つすべての猫を返すクエリでデータベースに接続します。そして、アプリはJSONレスポンスを使って猫を表示します。

app.post("/cats", (request, response) => {
	const query = `SELECT * FROM cats WHERE id = ${request.body.id}`;
	connection.query(query, (err, rows) => {
    	if(err) throw err;
        response.json({
        	data: rows
		});  
	});
});

この例はSQLインジェクション攻撃の訓練を受けていない人には無害に見えるかもしれませんが、非常に脆弱です。特筆すべきは、このアプリは潜在的に危険な文字列やエンコーディング方法について、ユーザー入力を検証したりサニタイズしたりしようとせず、ユーザー入力をSQLクエリに直接連結していることです。

JavaScriptのSQL攻撃ペイロードの例

SQLインジェクションは、アプリがSQLクエリを生成する方法によって、MySQLやPostgreSQLデータベースを騙してアクションを起こさせたり、想定外のデータで応答させたりすることにかかっています。

会社情報 1=1は常に真 攻撃は、アポストロフィや引用符のようなトリックを使って、猫の表全体を返すことができる。 1=1 は確かに常に 本当だ：

• ユーザーは入力する： ボビー・テーブル'または1='1
• データベースはSQLクエリを実行する： SELECT * FROM Users WHERE Cat = BOBBY TABLES OR 1=1；

同様に、攻撃者は = は常に真である というのも、すべての猫を返せという攻撃だからだ。 ""="" は常に 本当だ：

• ユーザーは入力する： "OR ""=""
• データベースはSQLクエリを実行する： SELECT * FROM Cats WHERE CatId ="" または ""=""；

攻撃者はしばしば、データベースがインラインコメントをどのように扱うかを悪用し、コメント (/* ... */) をクエリに入れることで、意図を難読化したり、フィルタを迂回したりすることができる。

• ユーザーは入力する： DR/*hello world*/OP/*sneak attack*/ TABLE Cats；
• データベースはSQLクエリを実行する： DROP TABLE Cats；

これは、攻撃者に無害な文字列で開始させ、セミコロン（;）を使ってそのステートメントを終了させ、インジェクションを含む別のステートメントを開始させるものです。攻撃者はクエリスタッキングを使って、DROP TABLEコマンドでデータベース全体を一挙に削除することがよくあります：

• ユーザーは入力する： ボビー; DROP TABLE キャッツ--。
• アプリはSQLクエリーを構築する： const query = "SELECT * FROM Cats WHERE CatId = " + input；
• データベースはSQLクエリを実行する： SELECT * FROM Cats WHERE CatId = BOBBY; DROP TABLE Cats；

NoSQLインジェクション攻撃についてはどうだろうか？

NoSQLインジェクション攻撃は、アプリとユーザーデータのセキュリティにとって同様に危険だが、MongoDBのようなデータベースを使用する技術スタックにのみ影響する。SQLとNoSQLのクエリはまったく独自の構文を使用するため、一方のカテゴリーから他方のカテゴリーに変換することはできません。

SQLデータベースを使用していれば、NoSQLインジェクション攻撃のリスクはない。

基本的な方法：SQLインジェクションの脆弱性をすべて手動で修正する。

この時点では、可能性のあるインジェクションのトリックがどのようなものかにはあまり興味がなく、MySQL や PostgreSQL にあるデータをどのように保護するかに関心があるかもしれません。

• パラメータ化されたクエリを使用する:SQLにはクエリと値の実行を切断する機能があり、インジェクション攻撃からデータベースを保護します。上記のJavaScript/Node.jsの例では、SQLクエリにクエスチョンマーク(?).その connection.query() メソッドは第2引数にパラメータを取り、インジェクション防止メソッドと同じ結果を提供する。

app.post("/cats", (request, response) => {  
	const query = `SELECT * FROM Cats WHERE id = ?`;  
    const value = request.body.id;  
    connection.query(query, value, (err, rows) => {    
    	if(err) throw err;    
        response.json({      
        	data: rows    
		});  
	});
});

‍

• ユーザー入力の検証とサニタイズ:パラメータ化されたクエリは、SQLデータベースを侵入や攻撃から保護するのに役立ちますが、ユーザーが潜在的に危険な文字列をアプリケーションに入力するのを防ぐこともできます。
  
  サニタイズとバリデーションのためのオープンソースのライブラリをアプリに追加するのも一つの方法だ。例えば バリデータ.js JavaScript/Node.jsエコシステムにおいて、ユーザーがサインアップフォームにSQLインジェクション攻撃ではなく、本物のメールアドレスを入力しようとしていることをダブルチェックする。
  
  同じような作業を行うために、正規表現ベースのカスタムバリデータを開発することもできますが、調査や膨大な手作業によるテストなど、膨大な時間と複雑な道のりが待ち受けています。さらに、この正規表現例を本当にEメールバリデーションのために解釈できるでしょうか？
  
  const re = /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
  
  のような文字列を防ぐのにも同じ考え方が適用される。 ...' OR 1-'1. このような機会をすべて自分で調査し、潰していくこともできるが、それよりも新機能の構築に時間を費やした方がいいだろう。

‍

• WAFやエージェントベースのセキュリティ・プラットフォームを導入する：
  
  第一に、高価であることが多く、オンプレミスまたはクラウド上に新しいインフラを立ち上げる必要がある。第二に、ルールセットを更新するために手作業によるメンテナンスが必要になり、SQLインジェクションに対する他の手作業による介入から注意をそらすことになる。最後に、計算負荷が増えたり、分析のためにすべてのリクエストを自社のプラットフォーム経由でリダイレクトすることで、待ち時間が増え、エンドユーザー・エクスペリエンスが損なわれることがよくある。

大きな問題は、SQLインジェクション攻撃の機会は雑草のようなものであることだ。これらのツールを使えば一度はすべて刈り取ることができるが、二度と芽が出ないようにコードベース全体を常に警戒しなければならない。

JavaScriptのSQLインジェクション攻撃を解決する代替パス：Aikido ファイアウォール

Aikido Securityが最近リリースしたFirewallは、SQLインジェクション攻撃から自律的にあなたを守る、フリーでオープンソースのセキュリティ・エンジンだ。

Node.jsを使用していない場合、私たちは将来的に他の言語やフレームワークのサポートを開始する予定です。FirewallがJavaScriptの世界を超えて拡大する正確な情報を得るために、いつでも製品ニュースレターを購読することができますし、特定の言語を売り込みたい場合はhello@aikido.devまでメールしてください。

JavaSciptのSQLインジェクションに脆弱なアプリのテスト

オープンソースのリポジトリに同梱されているサンプルアプリを使って、Aikido Firewallの動作を紹介しよう。ローカルのMySQLデータベースをデプロイするためにDocker/DockerComposeも必要だ。

まず、firewall-nodeリポジトリをフォークし、そのフォークをローカルのワークステーションにクローンします。

git clone https://github.com/<YOUR-GITHUB-USERNAME>/firewall-node.gitcd firewall-node

Dockerを使って、ローカルのMySQLデータベースをポート27015にデプロイする。このdocker-compose.ymlファイルは、s3mock、MongoDB、PostgreSQLコンテナも作成します。これは、Aikido チームがFirewallが様々な攻撃をどのようにブロックするかをテストするために作成されたものです。

docker-compose -f sample-apps/docker-compose.yml up -d

次に、サンプルアプリを起動します：

node sample-apps/express-mysql2/app.js

オープン http://localhost:4000 をブラウザで開いて、とてもシンプルな猫アプリをチェックしよう。テキストエリアに猫の名前をいくつか入力して 追加 ボタンをクリックします。SQLインジェクションをテストするには テスト噴射 リンクをクリックするか、テキストエリアに以下を入力してください： キティ'); DELETE FROM cats;-- H をクリックしてください。 追加 もう一度。いずれにせよ、このアプリを使えば、複数のクエリーをまとめて、卑劣なクエリーコメントを使って、ネコのデータベース全体を削除することができる。

どうしてこうなるのか？先に警告したように、このアプリは単に いずれも SQLクエリの最後にユーザー入力を入力するが、これは本質的に安全ではない。

const query = `INSERT INTO cats(petname) VALUES ('${name}');`

ここでの結果は小さいかもしれないが、このしばしば起こる正直なミスが、本番アプリに悲惨な結果をもたらすことは想像に難くない。

Aikido FirewallでJavaScriptのSQLインジェクションをブロックする

では、私たちのオープンソースのセキュリティ・エンジンが、あなたのコードにあるデータベースのやり取りをすべて手作業で修正することなく、JavaScriptのSQLインジェクション攻撃をどれだけ素早くブロックするか見てみましょう。

まだAikido アカウントを持っていない場合は、先に進んでください。 無料で作る.すでにお持ちの場合は、ログインして GitHubアカウントに接続する.その過程で、Aikido あなたのフォークを読むことを許可する。 ファイアウォールノード プロジェクトに参加している。

に行く。 ファイアウォール・ダッシュボード をクリックし、Add Serviceをクリックします。サービス名を付け、再度、フォークを選択して ファイアウォールノード プロジェクトに参加している。

Aikido 、Aikido Firewallをインストールして実装する方法を説明します。サンプルアプリを使用しているので、その作業はすでに終わっていますが、JavaScriptのSQLインジェクション攻撃に脆弱な可能性のあるすべてのNode.jsアプリに、私たちのオープンソースのセキュリティエンジンを導入する方法について参考になります。

をクリックする。 トークンの生成 ボタンをクリックし、Aikido FirewallがブロックされたSQLインジェクション攻撃に関する情報をAikido セキュリティプラットフォームに安全に渡すためのトークンを作成します。で始まる生成されたトークンをコピーします。 AIK_RUNTIME...そしてターミナルに戻ってサンプルアプリを再実行する：

AIKIDO_TOKEN=<YOUR-AIKIDO-TOKEN> AIKIDO_DEBUG=true AIKIDO_BLOCKING=true node sample-apps/express-mysql2/app.js

オープン ローカルホスト:4000 を実行し、もう一度SQLインジェクション攻撃を実行する。今回、Aikido ブラウザであなたをブロックし、ローカルのウェブサーバのログに出力し、新しいイベントを生成します。これをクリックすると、ペイロードやアプリが危険なSQLクエリを生成した場所など、SQLインジェクションの試みに関する包括的な詳細が表示されます。

Aikido Firewallは、JavaScriptによるSQLインジェクション攻撃からアプリを永遠に守ることに悩む代わりに、攻撃ソース、一般的なペイロード、潜在的な弱点について常に情報を提供する包括的なブロックと洗練された観測機能を提供します。

次はどうする？

Aikido Firewallは、Node.jsベースのアプリケーションに無料でインストール、実装することができます。私たちのオープンソースの組み込みセキュリティエンジンは、JavaScriptのSQLインジェクション攻撃、コマンドインジェクション、プロトタイプ汚染、パストラバーサル、およびすぐに来るより多くからあなたのインフラストラクチャとユーザーデータを保護します。

Firewall が SQL インジェクションから守るための開発のベストプラクティス（パラメータ化されたクエリを使 うとか、ユーザの入力を信用しないとか）に取って代わるべきだと言っているわけではありません。コードベースに欠陥はなく、正直な間違いは常に起こります。

FirewallはSQLインジェクションのグローバルな修正プログラムだと思ってください。カスタム開発された正規表現、レイテンシーを誘発するWAF、あるいは高額な費用がかかる複雑なセキュリティ・エージェントとは異なり、Firewallはこの1つの仕事を非常にうまく、しかも影響はごくわずかで、完全に無料で行うことができる。

もし気に入っていただけたなら、ロードマップをご覧いただき、GitHub リポジトリ(https://github.com/AikidoSec/firewall-node) に星をつけてください。⭐

‍

はじめに

Prismaを使用してブログ用Webアプリを構築しているとします。提供された電子メールとパスワードに基づいてユーザーを認証する簡単なクエリを記述します：

1const user = await prisma.user.findFirst({
2  where: { email, password },
3});

無害に見えるだろう？しかし、攻撃者が password = { "not": "" }?emailとpasswordが一致した場合のみUserオブジェクトを返すのではなく、emailのみが一致した場合は常にUserを返します。

この脆弱性は演算子インジェクションとして知られていますが、より一般的にはNoSQLインジェクションと呼ばれています。多くの開発者が気づいていないのは、厳密なモデルスキーマにもかかわらず、いくつかのORMは PostgreSQLのようなリレーショナルデータベースで使われているときでさえ演算子インジェクションに対して 脆弱であるということです。

この投稿では、演算子インジェクションがどのように機能するかを調べ、Prisma ORMでの悪用を実演し、それを防ぐ方法について説明します。

オペレーター・インジェクションを理解する

ORMの演算子インジェクションを理解するには、まずNoSQLの演算子インジェクションを見てみるのが面白い。MongoDBは、次のような演算子を使ってデータを問い合わせるAPIを開発者に紹介した。 eqドル, ドル そして ドル.ユーザー入力がMongoDBのクエリー関数にやみくもに渡されると、NoSQLインジェクションのリスクが存在する。

JavaScript用の人気のあるORMライブラリは、データをクエリするための同様のAPIを提供し始め、今ではほとんどすべての主要なORMが、MongoDBをサポートしていなくても、クエリ演算子のいくつかのバリエーションをサポートしている。Prisma、Sequelize、TypeORMはすべて、PostgreSQLのようなリレーショナルデータベース用のクエリ演算子を実装しています。

Prismaにおける演算子インジェクションの悪用

複数のレコードを操作するPrismaクエリ関数は、一般的にクエリ演算子をサポートしており、インジェクションの脆弱性があります。関数の例 最初を見つける, findMany, updateMany そして 削除多数.Prismaは実行時にクエリで参照されるモデル・フィールドを検証しますが、演算子はこれらの関数の有効な入力であるため、検証によって拒否されることはありません。

Prismaで演算子インジェクションが悪用されやすい理由の1つは、Prisma APIで提供されている文字列ベースの演算子です。 いくつかのORMライブラリは、文字列ベースのクエリ演算子のサポートを削除しています。これは、開発者が見落としやすく、悪用されやすいためです。その代わりに、開発者は演算子用のカスタムオブジェクトを参照することを余儀なくされます。これらのオブジェクトはユーザー入力から容易にデシリアライズできないため、これらのライブラリでは操作インジェクションのリスクが大幅に減少します。

Prismaのすべてのクエリ関数が演算子インジェクションの脆弱性を持つわけではありません。1つのデータベースレコードを選択または変更する関数は通常、演算子をサポートしておらず、Objectが指定されると実行時エラーがスローされます。findUnique 以外に、Prisma の update、delete、upsert 関数も where フィルタで演算子を受け付けません。

1  // This query throws a runtime error:
2  // Argument `email`: Invalid value provided. Expected String, provided Object.
3  const user = await prisma.user.findUnique({
4    where: { email: { not: "" } },
5  });

‍

オペレーター・インジェクションを防ぐためのベスト・プラクティス

1.ユーザー入力をプリミティブデータ型にキャストする

通常、文字列や数値のようなプリミティブなデータ型に入力をキャストすれば、攻撃者がオブジェクトを注入するのを防ぐのに十分である。元の例では、キャストは次のようになる：

1  const user = await prisma.user.findFirst({
2    where: { email: email.toString(), password: password.toString() },
3  });

2.ユーザー入力の検証

キャストは効果的ですが、入力がビジネスロジックの要件を満たしていることを確認するために、ユーザー入力を検証したい場合があります。

class-validator、zod、joiなど、サーバーサイドでユーザー入力を検証するライブラリはたくさんあります。NestJSやNextJSのようなWebアプリケーションフレームワークで開発している場合、コントローラでユーザー入力を検証する特定の方法を推奨していることが多いでしょう。

元の例では、ゾッドの検証は次のようになる：

1import { z } from "zod";
2
3const authInputSchema = z.object({
4  email: z.string().email(),
5  password: z.string().min(8)
6});
7
8const { email, password } = authInputSchema.parse({email: req.params.email, password: req.params.password});
9
10const user = await prisma.user.findFirst({
11  where: { email, password },
12});

3.ORMを常にアップデートする

アップデートを継続することで、セキュリティの改善や修正を受けることができます。たとえば、Sequelize はバージョン 4.12 からクエリー演算子の文字列エイリアスを無効にし、演算子インジェクションの影響を大幅に軽減しました。

結論

演算子インジェクションは、最新のORMを使用するアプリケーションにとって現実的な脅威である。この脆弱性はORMのAPI設計に起因するもので、使用するデータベースの種類とは関係ありません。実際、PostgreSQLと組み合わせたPrismaでさえ、演算子インジェクションに対して脆弱である可能性があります。Prismaは演算子インジェクションに対する組み込みの保護を提供していますが、開発者はアプリケーションのセキュリティを確保するために入力検証とサニタイズを実践しなければなりません。

付録ユーザーモデルのPrismaスキーマ

1// This is your Prisma schema file,
2// learn more about it in the docs: https://pris.ly/d/prisma-schema
3
4generator client {
5  provider = "prisma-client-js"
6}
7
8datasource db {
9  provider = "postgresql"
10  url      = env("DATABASE_URL")
11}
12
13// ...
14
15model User {
16  id       Int      @id @default(autoincrement())
17  email    String   @unique
18  password String
19  name     String?
20  posts    Post[]
21  profile  Profile?
22}

TL;DR: EUの新しいサイバーセキュリティ指令NIS2は、調達契約における脆弱性管理要件の厳格化を通じて、ソフトウェア・サプライヤーのビジネスのあり方をすでに変えつつある。このシフトは勢いを増しており、より多くの企業が適応する必要があります。Aikido 、このような新しい要求に応えるために、コンプライアンス・レポーティングと脆弱性追跡の自動化を支援します。無料のコンプライアンスの旅 こちらからまたは、あなたのビジネスにとってこれが何を意味するかを理解するためにお読みください。

NIS2パッチ不適合のリスク

思い浮かべてほしい：月曜日の午前8時33分。あなたはコーヒーを片手に受信トレイを整理し、9時からの週次ミーティングに備え、心の準備をしている。

Eメールを開き、お決まりの定型文をスクロールし、気がつくとこれらの言葉を読んでいる（そして読み直している）：

サービスを提供するために使用されるすべてのソフトウェア・コンポーネントは、脆弱性の重大性に応じて、以下の期間内にパッチを適用しなければならない：

- 重大：パッチの提供開始後48時間以内
- 高：パッチの提供開始後1週間以内
- 中：パッチの提供開始後1ヶ月以内
- 低：パッチの提供開始後3ヶ月以内

重要な脆弱性については48時間。営業日ではない。ベストエフォートでもない。48.時間。そんな感じで、月曜日はコンプライアンス・オリンピックになり、同時にすべての種目に出場することになる。

これらの新しいNIS2のパッチ適用要件は、単なるチェックボックスの一つではなく、運用上の重要な課題である。考えてみてほしい：

• チームはすでに手薄になっている
• 新しいCVEのたびに、セキュリティのモグラたたきをしているような気分になる
• 配備の窓は狭く、ますます狭くなっている
• そして今、このようなアグレッシブなスケジュールを遵守していることを文書化し、証明する必要があるのだろうか？

これらのSLAを逃すことは、単に監査に不合格になるだけでなく、主要な契約を失い、違約金に直面し、あるいはEU市場から完全に排除されることを意味する。

しかし、他のベンダーが大規模なコンプライアンス・プログラムを構築し、NIS2の専門チームを雇うために奔走している一方で、あなたはその必要はない。

NIS2に準拠するには

私たちは、この瞬間のために特別にAikido 構築しました。私たちのNIS2準拠は、このような調達の頭痛の種のためにイージーモードでゲームをプレイするようなものです。文字通り数分で

• 調達チームが実際に受け入れるコンプライアンス・レポートの作成
• 脆弱性SLAを自動的に追跡
• タイムラインに違反する前にアラートを受け取る
• 約束ではなく、実際のデータでコンプライアンスを証明する

これらの要件が何を意味するのか、また、2025年の計画全体を覆すことなく、どのように取り組むことができるのか、具体的に説明しよう。

Aikido登録に登録し、数分で無料のNIS2レポートを入手してください。

NIS2の条件は？

NIS2 は EU の最新のサイバーセキュリティ指令であり、企業の脆弱性管理の扱い方を大きく変えつつある。EU加盟国はNIS2を国内法に移管しており、多くの場合、ISO 27001のような標準規格を導入の基礎として参照している。

前作とは異なり、NIS2はより多くの業界をカバーし、特にサプライチェーンのセキュリティに関してより厳しい要件を課している。大手企業、特に重要なセクターの企業は、これらの要件を社内で実施するだけでなく、サプライチェーン内のすべてのベンダーに押し下げることが求められている。

読む： NIS2：誰が影響を受けるのか？

これは実際には何を意味するのでしょうか？EU企業にソフトウェアやサービスを販売している場合、上記の例のような調達要件に直面することが多くなるでしょう。具体的なパッチのタイムラインを要求し、脆弱性管理プロセスの詳細な文書化を期待し、定期的なコンプライアンス報告を求めるでしょう。これらは単なるチェックボックス要件ではなく、調達チームは積極的にコンプライアンスを検証し、これらのSLAを契約に組み込んでいる。

我々が目にする最も一般的な要件は以下の通りである：

• 深刻度に基づいて脆弱性にパッチを適用するためのSLAを定義した（冒頭の例は、実際の調達ドキュメントから引用したものです！）。
• 定期的な脆弱性スキャンとレポート
• 脆弱性管理プロセスの文書化
• 自動追跡によるコンプライアンスの証明
• 改善努力に関する定期的な状況報告

NIS2脆弱性パッチ適用要件

法律の専門用語は抜きにして、NIS2が脆弱性パッチの適用に関して実際に何を意味しているかに焦点を当てよう。NIS2自体は、特定のパッチ適用期限を規定していない。しかし、脆弱性の取り扱いと開示を含むリスク管理措置を義務付けており、これが、ソフトウェア購入者が記述されたSLAを課すことにつながっている。以下は、調達チームが求めているものである：

レスポンス・タイムフレーム

ほとんどの企業は、これらのパッチウィンドウを標準化している：

• 重大な脆弱性48時間
• 重症度：7日間
• 重大度中：30日
• 重症度が低い場合：90日

そして、これらのタイムラインは、あなたがそれを発見したときからではなく、パッチが利用可能になったときから始まります。つまり、スタック内のすべてのコンポーネントの脆弱性アナウンスを常に把握しておく必要があるということだ。

必要書類

3つのことを証明する必要がある：

1. それぞれの脆弱性を発見した時期
2. パッチが利用可能になったとき
3. 修正プログラムの導入時

自動化された追跡がなければ、これはすぐにセキュリティ・チームのフルタイムの仕事になる。

連続モニタリング

四半期に一度のセキュリティ・スキャンの時代は終わった。NIS2は期待している：

• 定期的な脆弱性スキャン（ほとんどの企業はこれを毎日と解釈している）
• CVEsによる新しいセキュリティ勧告の監視
• パッチ状況とSLA遵守の積極的な追跡

リスク管理

すべての脆弱性に対して、あなたは必要とする：

• 重症度評価を文書化する
• 改善の進捗状況を追跡
• パッチの遅れを正当化する
• 合意されたSLAの遵守状況を報告する

これが、Aikido NIS2レポートを構築した理由です。スプレッドシートを作成し、チケットを管理する代わりに、調達チームが見たいものすべてを追跡する単一のダッシュボードを得ることができます。

Aikido 実践する（実践編）

コンプライアンス・フレームワークは、実際のセキュリティ業務とは切り離された、事務的な作業の塊のようなものです。しかし、そうである必要はない。

例えば、調達チームがあなたの脆弱性管理プロセスについて質問してきたとしよう。文書作成に奔走する代わりに、あなたは単純にこう言う：

1. Aikido 開発パイプラインにつなげる
2. クラウドインフラとのリンク
3. NIS2コンプライアンスレポートを有効にする
4. 自動化されたパッチのタイムラインの証拠をエクスポートします。
5. 送り出す

それだけだ。終わりのない文書作成は必要ない。スプレッドシートを使うこともない。土壇場で慌てることもない。

すぐに得られるもの

• 9つのリスクベクトル（依存関係からランタイムセキュリティまで）にわたる継続的なスキャン
• 技術管理のための証拠収集の自動化
• 調達要件のコンプライアンス状況をリアルタイムで確認
• NIS2要件に直接対応するダイナミックレポート

最も優れている点は？CIパイプライン、コードリポジトリ、クラウド環境など、開発者がすでにいる場所で正確に機能することです。他のチームが ISO 27001 認証や NIS2 コンプライアンスのために手作業で証拠を集めている間に、あなたは実際のセキュリティデータからコンプライアンスレポートを自動的に作成しています。

次のステップ

NIS2コンプライアンスに関する問い合わせに対応するために、大規模なコンプライアンス・プログラムを構築したり、コンサルタントを雇ったりする必要はない。次のような戦略的アプローチをお勧めする。

1. 自分の立ち位置を明確に把握する（無料のAikido アカウントに登録することで）
2. 最初のNIS2コンプライアンス・レポートを実行する
3. 注意が必要な箇所を正確に把握する
4. レポーティングを自動化し、NIS2に対応していることを顧客に簡単に証明できる。

競合他社が手作業でパッチ文書を管理し続けている間に、自動化されたコンプライアンス・レポートを数分で立ち上げ、実行することができます。将来、NIS2要件に関する調達の問い合わせが来たときにも、コンプライアンス・インフラがしっかりと整備されていることを知っていれば、自信を持って対応することができます。

今度、件名に「NIS2要件」と書かれた調達メールを見かけたら？どうぞ、コーヒーをもう一口飲んでください。この件は、バッグの中、いや、マグカップの中と言うべきだろう。

この記事では、AI SASTツールのリーダー10社を紹介する。各ツールの中核機能と、セキュリティの発見、優先順位付け、修復を強化するためにAIを実装する独自の方法を探ります。  

SASTとは？

静的アプリケーションセキュリティテスト（SAST）は、アプリケーションのソースコード、バイトコード、または、バイナリを 分析し、ソフトウェア開発ライフサイクル（SDLC）の早い段階で、脆弱性とセキュリティ上の欠陥を特定するための方法論です。SAST は、ソースコード内の脆弱性を発見するため、多くの場合、安全でないコードに対する最初の防御となります。

詳細はこちら SAST vs DAST 知っておくべきこと

SASTはあなたのコードにどのような脆弱性を見つけましたか？

SASTが発見できる脆弱性には様々なものがあり、使用されているコーディング手法、技術スタック、フレームワークによって異なります。以下は、SASTツールが通常発見する最も一般的な脆弱性です。

SQLインジェクション

データベースの侵害につながる可能性のある、ユーザ入力の不適切なサニタイズを検出する。

インジェクション・コードの例

# Function to authenticate user
def authenticate_user(username, password):    
   query = f"SELECT * FROM users WHERE username = '{user}' AND password = '{password}'"
   print(f"Executing query: {query}")  # For debugging purposes    
   cursor.execute(query)    
   return cursor.fetchone()

クロスサイト・スクリプティング (XSS)

ユーザー入力が不正に検証またはエンコードされ、悪意のあるスクリプトのインジェクションを許している事例を特定する。

XSSに脆弱なコードの例

<script>
   const params = new URLSearchParams(window.location.search);
   const name = params.get('name');
   if (name) {
          // Directly inserting user input into HTML without sanitization
          document.getElementById('greeting').innerHTML = `Hello, ${name}!`;
   }
</script>

バッファオーバーフロー

メモリ割り当ての不適切な処理がデータ破損やシステムクラッシュにつながる可能性がある箇所を強調。

バッファオーバーフローに脆弱なコード例

1#include
2void vulnerableFunction() {
3    char buffer[10]; // A small buffer with space for 10 characters
4
5    printf("Enter some text: ");
6    gets(buffer); // Dangerous function: does not check input size
7
8    printf("You entered: %s\n", buffer);
9}
10
11int main() {
12    vulnerableFunction();
13    return 0;
14}

安全でない暗号の慣行

脆弱な暗号化アルゴリズム、不適切な鍵管理、ハードコードされた鍵を検出する。

import hashlib  

def store_password(password):    
    # Weak hashing algorithm (MD5 is broken and unsuitable for passwords)    
    hashed_password = hashlib.md5(password.encode()).hexdigest()    
    print(f"Storing hashed password: {hashed_password}")    
    return hashed_password

SASTツールは貴重な洞察を提供し、開発者は問題が致命的になる前に修正することができる。

AIがSASTツールをどのように強化するか

現在、AIの話題（そしてBullSh*t）から逃れることはできない。AIがセキュリティ・ツールにどのように実装されているかを正確に知ることは難しい。私たちは、AIを搭載したSASTのリーダー企業のいくつかを比較し、これらのツールがセキュリティを強化するためにAIを実装するさまざまな方法を説明したいと考えました。  

現在、SASTツールに関連するAIには3つのトレンドがある。

1. AIによる脆弱性検出の改善：既知の脆弱性に関する大規模なデータセットで訓練されたAIモデルは、誤検知を減らしながら、セキュリティ上の問題を特定する精度を向上させる。
2. AIによる自動優先順位付け： AIは、深刻度、悪用可能性、潜在的なビジネス上の影響に基づいて脆弱性をランク付けし、開発者が重要な問題に最初に集中できるようにします。
3. 自動修復を提供するAI：AIは、コンテキストに応じたコードの修正または提案を提供し、修正プロセスを迅速化し、開発者が安全なコーディングプラクティスを習得できるようにする。

AIを搭載したSASTツール・トップ10

ここでは、従来のSASTの能力を強化するためにさまざまな方法でAIを使用している10の業界リーダーを紹介する（アルファベット順）。

1.Aikido セキュリティSAST｜AI AutoFix

コアAI機能｜自動修正機能（ダッシュボード＋IDE）

AikidoSecurityは、SASTスキャナーで発見された脆弱性のコード修正プログラムを作成するためにAIを使用し、修正プロセスをスピードアップするために自動プルリクエストを生成することもできます。
他のツールとは異なり、Aikido サードパーティのAIモデルにあなたのコードを送信せず、あなたのコードがAIモデルを通して漏れないようにする独自の方法を持っています。Aikido 、あなたのコードのサンドボックス環境を作成し、目的に応じて調整されたLLMがそれをスキャンし、脆弱性について再度スキャンされた提案を作成します。提案された改善策が検証に合格すると、サンドボックス環境が破棄される前に、プルリクエストが自動的に作成される。Aikidos AutoFixはまた、AIが生成したコードを使用する際、開発者が十分な情報を得た上で判断できるよう、提案に対する信頼度スコアを与えることができる。

2.チェックマークス

コアAI機能｜オートレメディエーション （IDEのみ）

Checkmarx SASTツールは、IDE内でAIが生成したコーディング提案を開発者に提供することができます。ツールはChatGPTに接続し、開発者のコードをOpenAIモデルに送信し、提案を取得します。この方法は、ChatGPTへのクエリプロセスを簡単にしますが、独自のプロセスを追加しないため、現時点では機能が制限されます。

警告 - このユースケースは、独自のコードをOpenAIに送信するため、コンプライアンス基準を満たしていない可能性があります。

3.コードアントAI

コアAIの能力｜検出力の向上 （ダッシュボード）

CodeAntは 、コードの脆弱性の発見と修正提案に完全にAIを使用しているコード・セキュリティと品質ツールです。CodeAntは、AIモデルがどのように機能するかについてのドキュメントを提供していないが、一般的にAIをコア検出エンジンとして使用しているため、特に大企業では検出が遅くなる可能性がある。

4.コードスレット

コアAI機能｜自動優先順位付け （ダッシュボード）

CodeThreatはオンプレミスで静的コード解析を提供し、AI支援による修復戦略を提供する。主な違いは、CodeThreatは自社のオンプレミスAIモデルを自社のツールに統合できることだ。これは、データをサードパーティに送らないという利点があるが、現時点では遺伝子学習されたAIモデルしか提供できないことを意味し、ChatGPTのようなオンプレミスAI LLMを実行する必要がある。

5.フォーティファイ スタティック コード アナライザー

AIコア能力｜優先順位付けの改善（ダッシュボード）

Fortify Static Code Analyzerは、ソースコードの脆弱性をスキャンし、悪用の可能性などのアラートが出されたときに、ユーザーがしきい値を調整するオプションを提供します。Fortifies AI Autoassistantは、脆弱性に割り当てられた過去のしきい値をレビューし、他の脆弱性のしきい値をインテリジェントに予測します。

注：Fortify Static Code Analyzerは、脆弱性を発見したり、その修正を提案したりするためにAIを使用するのではなく、管理パネルで使用される管理設定を予測するためにAIを使用します。

6.GitHub アドバンスドセキュリティ｜CodeQL

AIコア機能｜自動修復 （IDE＋ダッシュボード）

GitHub CodeQLは、AIを使用してコード提案の形でインテリジェントな自動修復を作成する静的コードスキャナーです。開発者は、GitHub CodeSpacesのプルリクエストや自分のマシンから変更を受け入れたり、却下したりできる。GitHub Advanced Securityの一部だ。

7.Qwiet AI｜SASTコード

コアAI機能｜自動修正（ダッシュボード）
QwietAI SASTは、AIを活用してコードの脆弱性に対する修正アドバイスとコード修正を自動提案する、ルールベースの静的アプリケーション・セキュリティ・テスト・ツールです。Qwiet AI SASTの中核となるのは、問題の分析、修正案の提案、修正案の検証という3段階のAIエージェントです。

8.スニークコード｜DeepCode

AIの中核機能｜オートレメディエーション （IDE）

Snyk Codeは、開発者に特化したリアルタイムのSASTツールで、Snykが買収したDeepCode AIにより、IDE内から開発者にコード提案を提供することができる。DeepCode AIは複数のAIモデルを利用し、そのモデルの核となるセールスポイントは、トップクラスのセキュリティ専門家によってキュレートされたデータに基づいて学習されるため、AIの結果に対する信頼性が向上することだ。

9.Semgrepコード

コアAI機能｜検出の向上
SemGrepsのAIアシスタント(その名もアシスタント)は、潜在的な脆弱性を取り巻くコードのコンテキストを使用して、より正確な結果を提供し、推奨されるコード修正を提供します。また、SemGrepのルールを作成し、提供されたプロンプトに基づいて検出を強化するために使用することもできます。

10.ベラコード修正

コアAI機能｜自動修復
Veracode Fixは、開発者がVeracode IDEエクステンションまたはCLIツールを使用しているときに、コード内の脆弱性に基づいて変更を提案するためにAIを使用します。Veracode Fixの主な差別化点は、そのカスタム訓練されたモデルが、野生のコードではなく、データベース内の既知の脆弱性に対して訓練されていることである。この利点は、提案される修正に対する信頼性が高くなることだが、コードの修正を提案できるシナリオが限定されることだ。

SASTツールの選び方

AI）はセキュリティ市場に比較的新しく参入したものであり、業界のリーダーたちは革新的なアプリケーションを継続的に模索している。AIは、セキュリティ・システムを強化するためのツールとしてとらえるべきであり、むしろ唯一の真実の源としてとらえるべきである。注意すべき点は、AIは並みのツールを効果的なものに変えることはできないということだ。その可能性を最大限に引き出すために、AIはすでに強固な基盤と実績のあるツールと統合されるべきである。

Aikido SASTをチェックアウトする

アプリケーション・セキュリティ、あるいはSnykの代替製品をお探しですか？コード・セキュリティ・プラットフォームを初めて検討する場合でも、より良い選択肢を探しているベテラン・ユーザーでも、適切な場所にいます。

開発者や企業がその選択を評価するとき、しばしば2つの名前が上位に上がる：Aikido Securityと Snykだ。どちらのプラットフォームも、エンジニアリング・チームがアプリケーションをセキュアにするための包括的なツールを提供していますが、実際のところはどうなのでしょうか？意見に頼るのではなく、最も重要な声、つまり実際のユーザーの声に耳を傾けてみましょう。

検証済みの第三者機関のレビューに基づく

このガイドは、世界最大の信頼できるソフトウェア・マーケットプレイスである G2 から、検証済みのサードパーティレビューを直接まとめたものです。年間1億人以上のプロフェッショナルが G2 を利用し、信頼できるユーザーからのフィードバックをもとに、十分な情報に基づいたソフトウェアの意思決定を行っています。G2からの最新の検証済みユーザーデータに基づいて、機能、ユーザーエクスペリエンス、価格などを分析し、Aikido Security対Snykの詳細な内訳を提供します。

さらに、これらのユーザーレビューはG2でも直接読むことができます。以下は、Aikido Securityと SnykのG2リンクと、Snykの代替品としてAikido 比較した直接の比較レビューです。

Aikido 安全保障とは何か：

連続CTOウィレム・デルベールが率いる、 Aikidoは、開発者のための「うそのない」セキュリティ・プラットフォームです。他のアプリケーション・セキュリティ製品を長年使用してきたデルベアは、CTOと開発者のためのセキュリティを修正するためにAikido 設立しました。 実行

Aikido 開発者専用機能である集中スキャン、積極的な誤検知の削減、開発者ネイティブのUX、自動リスクトリアージ、リスクバンドル、3つの異なる問題タイプに対するLLMを利用した自動修正を含む簡単なステップバイステップのリスク修正により、エンジニアリングチームはより速く実行できる。

TL;DRAikido 、中小企業にとってシンプルで、開発者にとって実行可能なセキュリティを実現し、企業が顧客を獲得し、市場において成長し、コンプライアンスを確保できるようにします。

スニークとは何か：

Snykは、「開発者指向」のセキュリティ・ツールとして有名なセキュリティ企業で、チームがコードやオープンソースの依存関係、コンテナ・イメージの脆弱性を特定し、修正するためのツールとして位置づけられている。Snykは、「左遷」セキュリティ・ムーブメントにおける初期のプレーヤーであり、10年前にテルアビブとロンドンで設立され、現在は米国ボストンに本社を置いている。

Aikido スニークの比較

• Aikido セキュリティ
  
  • 評価 ⭐️：4.7
  • 市場セグメント 中小企業
  • エントリーレベル価格： 無料
• スニーク
  
  • 評価 ⭐️：4.5
  • 市場セグメント ミッドマーケットからエンタープライズまで
  • エントリーレベル価格： 無料

Aikido Securityは中小企業に、Snykは中堅企業、特に大企業に広く採用されている。両プラットフォームとも無料プランを提供しており、個人開発者や小規模チームにとって利用しやすいものとなっている。

カテゴリー別ランキングの概要

ユーザー・エクスペリエンス

使いやすさ

• Aikido セキュリティ9.5と評価されたAikido Securityは、直感的なインターフェースと合理化されたワークフローを高く評価しています。開発者ファーストのアプローチで設計されており、既存のCI/CDパイプラインに統合する際の摩擦を最小限に抑えます。
• Snyk：評価は8.7だが、ユーザーフレンドリーである一方、特にDevSecOpsツールに不慣れなチームにとっては、学習曲線が急であると指摘するレビュアーもいる。

セットアップの容易さ

• Aikido セキュリティスコアは9.5で、ユーザーはAikido迅速なオンボーディング・プロセスと最小限の設定要件が気に入っている。
• Snyk：9.0と評価されており、セットアップは簡単ですが、あまり一般的でないツールとの統合では、時折、問題が発生します。

管理の容易さ

• Aikido セキュリティScoring 9.3では、システム管理者はチーム、権限、統合を簡単に管理できます。
• スニーク評価は8.8。管理は効果的だが、大規模な組織では複雑になる可能性がある。

サポートと製品の方向性

サポートの質

• Aikido セキュリティ：9.6という印象的なスコアで、ユーザーは、応答性と知識豊富なサポートチームを頻繁に賞賛しています。ほとんどの証言では、Aikido チームと創設者からの迅速なサポートが最大のハイライトとして強調されています。
• Snyk：評価は8.6、サポートは問題なし、一般的に信頼できるが、フリー層のユーザーには遅いこともある。

製品の方向性

• Aikido セキュリティ革新的なロードマップと一貫した機能更新に対するユーザーの信頼を反映している。
• Snyk：評価8.7。オープンソースと開発者中心のツールに重点を置いている点は評価できるが、包括的な機能展開ではやや遅れをとっている。

Aikido スニークの代替機能の比較

Snyk に代わるプラットフォームをお探しの場合、各プラットフォームが提供する具体的な生産機能 に注目することが重要です。Snyk が SAST、IaC、ソフトウェア構成分析、および脆弱性スキャンを提供しているのに対し、Aikido オールインワン・プラットフォームでより多くの機能と特徴を提供しています。

Snykが4つの製品を提供しているのに対し、Aikido 1つのセキュリティ・スイートで、SAST、DAST、ソフトウェア構成分析、IaC、コンテナ・イメージ・スキャン、シークレット・スキャン、マルウェア・スキャン、APIスキャン、ライセンス・リスク・スキャン、ローカル・カスタム・スキャン、さらにクラウド（CSPM）セキュリティを含む11の製品を提供している。

静的アプリケーション・セキュリティ・テスト（SAST）

SASTとは？ SASTは、配備前にソースコードの脆弱性を特定する手法である。

• Aikido セキュリティ：評価8.7、ソースコードの脆弱性を特定し、実用的な洞察を提示することに優れている。
• Snyk：評価は7.7。効果的だが、競合他社に比べて偽陽性が多いとの批判が多い。

動的アプリケーション・セキュリティ・テスト（DAST）

DASTとは？ DASTは、実行中のアプリケーションをスキャンして実行時の脆弱性を検出する技術です。

• Aikido セキュリティ：8.9点を獲得し、最小限のコンフィギュレーションでランタイムの脆弱性を特定する能力を高く評価している。
• スニークDASTの能力を評価するには十分なデータがない。

コンテナ・セキュリティ

コンテナ・セキュリティとは？ コンテナ・セキュリティは、コンテナ化されたアプリケーションやイメージの脆弱性を特定するプロセスです。

• Aikido セキュリティ：8.4と評価され、レジストリ全体のコンテナ・イメージと脆弱性に対する深い洞察を提供している。
• Snyk：基本的なコンテナスキャンには強いが、高度なシナリオではあまり包括的でない。

ソフトウェア構成分析（SCA）

SCAとは？ SCAとは、オープンソースの依存関係やサードパーティのライブラリの脆弱性を検出することです。

• Aikido セキュリティ：8.9のスコアで、オープンソースの依存スキャンと強化されたマルウェア検出を組み合わせ、強固な保護を保証します。
• Snyk：評価8.0。オープンソースライブラリの既知の脆弱性の検出には効果的だが、悪意のあるパッケージの特定にはそれほど高度ではない。

アプリケーション・セキュリティ体制管理（ASPM）

ASPMとは？ ASPMは、アプリケーションのライフサイクル全体にわたって、そのセキュリティ態勢を管理・改善するためのフレームワークである。

• Aikido セキュリティ：8.4点を獲得。アプリケーション環境のセキュリティリスクを特定し、解決するためのプロアクティブなアプローチが評価された。
• スニークASPMの能力を評価するには十分なデータがない。

クラウド・セキュリティ・ポスチャ管理（CSPM）

CSPMとは？ CSPMは、誤設定やコンプライアンス上の問題を特定することで、クラウド環境を監視し、セキュリティを確保するためのツールセットである。

• 誤設定やコンプライアンス上の問題を特定することで、クラウド環境を監視し、セキュリティを確保する。
• Aikido セキュリティ：評価7.4、マルチクラウド環境にシームレスに統合し、明確な設定ミスのインサイトを提供します。Aikido CSPM機能は最近発表され、私たちのロードマップの大きなファセットです。
• スニークCSPM 機能を評価するのに十分なデータがない。現時点では、Snyk には CSPM 機能はありません。

脆弱性スキャナー

脆弱性スキャナとは 脆弱性スキャナは、システムやソフトウェアのセキュリティ脆弱性を特定し、評価します。

• Aikido セキュリティ：評価7.9。脆弱性をピンポイントで指摘し、明確な改善策を示す。
• Snyk：スコアは8.1。既知の脆弱性に関する広範なライブラリが評価されているが、結果にノイズが多いことが批判されている。

スニーク対Aikido お客様の声を検証：

Aikido スニークの両方を使用したことのある検証済みの人々からのレビュー。Aikido Snykの代替品としてどのように位置づけられるか聞きたい方は、以下をお読みください。

合気道は "効果的で適正価格のソリューション"

Snykのようなよく知られた競合他社に比べ、Aikido はるかに手頃な価格で、より完全で、最も重要なことは、実際にシステムに到達している脆弱性を提示するのに非常に優れているということだ。彼らは、あなたのコードをスキャンするために、プロプライエタリなものだけでなく、多くの一般的なオープンソースライブラリを使用しています。

Aikido "より安価なスニーク代替品"

Snykに代わる安価なソフトを探していましたが、Aikido その役割を見事に果たしてくれました。良いソフトウェア、簡単なUI、そして何よりもフィードバックがとても話しやすい。

セットアップはとても簡単で、チームメンバーへの導入も簡単だった。

このG2ユーザー・フィードバックの概要が、アプリケーション・セキュリティ・プラットフォーム探しの参考になれば幸いです。Aikidoテストにご興味のある方は、今すぐ始めてみませんか？

32秒で最初のスキャン結果を得ることができ、クレジットカードも 必要ありません。よりパーソナライズされたウォークスルーをご希望の場合は、人間と話すか、インカムで「こんにちは」とおっしゃってください。数秒で対応します。

       

       if(window.strchfSettings === undefined) window.strchfSettings = {};
   window.strchfSettings.stats = {url: "https://aikido-security.storychief.io/en/snyk-vs-aikido-security-g2-reviews-snyk-alternative?id=843344305&type=26",title: "Snyk vs Aikido Security | G2 Reviews Snyk Alternative",siteId: "5823",id: "f8908bf0-c824-4f3f-9bc9-22cac096e678"};
           (function(d, s, id) {
     var js, sjs = d.getElementsByTagName(s)[0];
     if (d.getElementById(id)) {window.strchf.update(); return;}
     js = d.createElement(s); js.id = id;
     js.src = "https://d37oebn0w9ir6a.cloudfront.net/scripts/v0/strchf.js";
     js.async = true;
     sjs.parentNode.insertBefore(js, sjs);
   }(document, 'script', 'storychief-jssdk'))