開発者ファーストのSASTツールがコードセキュリティの未来を担う理由
2021年4月28日
0 分で読めますアプリケーションセキュリティは、クラウドネイティブアプリケーションを開発し、リリースするチームにとって幅広い領域です。さまざまなプロセス、ツール、チームメンバーが関わり、セキュアなパイプラインの自動化（DevSecOpsの登場）からオープンソースセキュリティ、クラウドインフラのセキュリティテストまで、多岐にわたります。こうしたアプリケーションセキュリティテスト手法の一部は、コードセキュリティに重点を置き、正式には静的アプリケーションセキュリティテスト（SAST）ツールとして知られています。静的コード解析ツールと呼ばれることもあります。
技術用語としてのSASTになじみがない方のために、まず基本を紹介し、開発者ファーストのSASTツールがセキュリティ業界全体をどのように変えていくのかを見ていきましょう。
SASTツールとは？
SASTは、静的アプリケーションセキュリティテストツールです。ソースコードを解析し、潜在的なユーザー入力の起点から、機密性の高いアプリケーション・プログラミング・インターフェース（API）の処理に至るまで、データの流れを調べます。たとえば、検索ボックスに入力されたユーザーデータが、サニタイズされず、安全性を考慮せず、想定外の形でクエリを実行するデータベース関連の関数を呼び出す可能性を特定できます（これはSQLインジェクションというセキュリティ脆弱性です）。
従来のSASTツールと、その課題
静的アプリケーションセキュリティテストは、新しい概念ではありません。実際、この分野に数十年前から参入しているツールや企業は数多くあります。コードセキュリティの未来を考えるには、まず従来のSASTツールの仕組みと、期待したほど普及していない理由を見ていく必要があります。
従来のSASTツールは実行に時間がかかる
従来のセキュリティチームやDevOpsチームでは、「SASTに時間がかかりすぎる」「継続的インテグレーション？SASTが終わるのを延々待つだけだ！」といった声をよく耳にします。ソースコードリポジトリを解析するために、ビルドや継続的インテグレーション（CI）の段階でSASTツールを何時間、あるいは何日も実行するのが当たり前になっていました。
ソースコードの差分を解析したり、SASTのCIジョブを夜間や週末に実行するようスケジュールしたりと、結果をより早く提供するための工夫も行われてきました。しかし、こうした対応は、ツールが不十分で、現代の開発プロセスや期待に適応できていないことを示す回避策にすぎません。
SDLCでセキュリティが適切な位置に組み込まれていない
前述のフィードバックの遅れに対処するため、SASTツールは、時間のかかる評価で開発者の作業を妨げないよう、独立したCIプロセスとして導入されていました。しかし、SASTツールをCIに組み込むこの誤りは、当初の目的と大きく食い違っています。SASTはソースコードに焦点を当てるべきだからです。つまり、SASTはソフトウェアの開発中に活用すべきであり、CIの段階で初めて確認する後付けのものではありません。
ビルドと継続的インテグレーションの両方のプロセスにセキュリティツールを組み込むのは、セキュリティを取り入れる優れた方法です。ただし、開発者の生産性を損なわないよう、ツールは高速で、実用的なフィードバックを提供する必要があります。
誤検知によってSASTツールが使われなくなる
SAST導入の大きな課題として、精度、より具体的にはその低さも挙げられます。従来のSASTは誤検知が多く、不要な通知を大量に発生させがちです。セキュリティアラートには開発者の集中した対応が必要です。通知の多くが誤報であれば、実際の開発が遅れてしまいます。
誤検知は不満を招き、アプリケーションセキュリティチームとの関係を損ねます。その結果、開発者はセキュリティアラートを無視するようになり、ツールそのものも使わなくなってしまいます。
従来のSASTは問題を検出できても、修正できない
最後に、SASTツールの検出結果が正確であっても、問題の修正方法までは教えてくれません。この課題は、SASTツールの設計そのものに根ざしています。もともとSASTツールは、AppSecなどのセキュリティチームを念頭に構築されていました。そのため、実行フローの文脈が不足していたり、CWEコード（Common Weakness Enumeration、潜在的な脆弱性の説明）だけで問題を報告したりすることがありました。しかし、セキュリティの専門家でなければ、SASTだけでは問題の修復や脆弱性の修正に役立ちません。
セキュリティの問題に対処できるのは、熟練したアプリケーションセキュリティの専門家とそのコミュニティでした。そのため、セキュリティ対応の新たなボトルネックが生まれていました。また、SASTツールのスキャン結果を受け取っても問題を修正できない開発者の不満も、さらに高まっていました。
現代の開発者ファーストなSASTツールは、開発者の生産性を高める必要がある
SASTが最も重視するのは、コードセキュリティです。SASTツールは、機密データの露出、SQLインジェクション、コードインジェクションなど、さまざまな脆弱性を検出します。こうしたセキュリティ上の問題を持ち込むのは誰でしょうか？私たちのような開発者です。では、誰が修正すべきでしょうか？そのとおりです。開発者自身が修正すべきです。
開発者ファーストこそ、最高水準のSASTツールを支える秘訣であり、Snykがアプリケーションセキュリティの分野に革新をもたらしている理由です。Snykは、開発者ファーストの考え方を原点としています。
開発者にとって生産的なセキュリティ体験を実現するSASTに必要な要素を見ていきましょう
開発者のワークフローに組み込まれたコードセキュリティ
開発者がセキュリティ脆弱性の修正に欠かせない存在であるなら、SASTツールには、開発者にとって最も使いやすい形で統合できることが重要な機能となります。
開発者が多くの時間を過ごす場所はどこでしょうか（GoogleやStackOverflow以外で）？
IntelliJやVisual Studio CodeなどのIDE
Gitリポジトリの操作、コマンドの実行、デバッグ、プロジェクトのソースコードやルーチンの管理を行うコマンドラインインターフェース（CLI）
コードレビューの作業
SASTツールが定着するには、開発者が普段から使っているツール内で、セキュリティの問題を直接見つけて対処できるようにする必要があります。また、開発者がコード内のセキュリティ脆弱性を見つけて修正できるよう、結果には十分な文脈が含まれている必要があります。
IDEで作業する開発者向けに、シームレスに統合されたセキュリティツールの例として、Snyk CodeのSASTツールが動作する様子をご紹介します。
左側には、セキュアコーディングの不適切な実践によって生じる可能性のある脆弱性の一覧が表示されています。下部パネルの右側には、脆弱なデータフローがどのように発生し、悪用される可能性があるかを、行単位の文脈で示しています。
ターミナルのユーザーインターフェースで作業する時間が多い開発者には、コマンドラインインターフェースが適しています。この場合は、Snyk Code CLIをまさにその目的に活用できます。
たとえば、リンターやテストスイート、その他の自動化処理を実行するGitフックを使い、開発者がコードをコミットまたはプッシュする前にチェックしたい場合にも、Snyk CLIを活用できます。
同じプロジェクトに対してSnyk CLIでコードセキュリティテストを実行した結果は次のとおりです。
リアルタイムのセキュリティスキャン結果
SASTツールが前述の開発者ワークフローに対応するには、リアルタイムでセキュリティスキャンの結果を提供できる速度が必要です。高速であることは、開発の初期段階からセキュアコーディングを支援する特性です。開発者は、コードをプッシュした後にセキュリティチームやDevSecOpsの連携で問題が見つかるのを待つのではなく、コーディング中にセキュリティの問題を見つけて修正できます。後者の場合、コードのリファクタリングが必要になり、不要な手戻りが発生して変更のリリースプロセス全体が遅くなり、さらなる不満につながりかねません。
Snyk Codeは、セキュアコーディングをスムーズに支援するアプローチによって、静的コード解析セキュリティツールとして際立った価値を発揮します。Snyk Codeの速さを、ぜひお試しください。その目でお確かめいただけます。
高精度、低い誤検知率
ワークフローへの統合と迅速なフィードバックループは重要ですが、開発者体験の質を左右する要素として見落とされがちなのが、データそのものです。
開発者がツールを十分に活用し、ワークフローに取り入れるには、そのツールを信頼できる必要があります。SASTツールが報告するセキュリティデータの品質によって、開発者が喜んでツールをワークフローに統合するか、誤検知の多さにより使うのをやめるかが決まります。
業界をリードする精度を実現するため、Snyk CodeはGitHub上のあらゆるオープンソースプロジェクトから収集した実際のコードセキュリティ問題を学習した機械学習を活用しています。学習した知識を使って、独自のコード内のパターンを特定できます。こうした機械学習モデルのトレーニングをさらに支えるため、Snyk CodeのAIエンジンは、Snyk独自の専門家が精選した脆弱性データベースと修正コミットを学習データとして活用します。これらすべてが、誤検知の大幅な削減に役立っています。
開発者がコードセキュリティの問題を修正できるよう支援する
StackOverflowのスレッドは開発者にとって心強い味方ですよね。半分冗談ですが、開発者は、ほかの人がコーディングの問題をどう解決したかを示す、役立つサンプルを重宝します。セキュリティ関連の問題も同じではないでしょうか？
SASTツールが、CWE-78としてよく知られるコマンドインジェクションの脆弱性を検出したケースを見てみましょう。これは、OSコマンドで使用される特殊な要素の不適切な無害化（「OSコマンドインジェクション」）を指します。少し難しい説明ですよね。開発者は通常、セキュリティの専門知識がないため、CVEやCWE、その影響、さらにはセキュアコーディングの実践に沿った修正方法を理解できないことがあります。Snykが全社を挙げて解決に取り組んできたのは、まさにこの課題です。
開発者であっても、セキュリティの専門知識がなく、セキュリティ上安全でないNode.js APIのexec()を使っている86行目のコマンドインジェクションを修正できないこともあるでしょう。このようなセキュリティレポートを受け取ったら、どうしますか？
従来のSASTツールと比べてSnyk Codeが優れているのは、この点でもあります。検出したコードセキュリティの問題を解決できるよう支援します。IntelliJ IDEで撮影した次のスクリーンショットの右下を見ると、このNode.jsプロジェクトで検出されたコードインジェクションの問題に対処するため、複数のオープンソースプロジェクトのコミット差分をSnyk Codeが表示しているのがわかります。
この情報があれば、開発者は、同様のセキュリティ問題をほかの人がどのように修正したかを確認できます。修正案の背景にある幅広い情報をもとに、より十分な情報に基づいて修正方法を判断できます。
まとめ
つまり、開発者に必要なのは、自分たちのコードだけでなく、利用しているオープンソース依存関係のセキュリティ問題も検出できるSASTです。それに加えて、見つかった脆弱性に対して実行可能な修正案を提示できる必要があります。そして、開発者に活用してもらうには、高速で精度が高く、開発者のツールやワークフローに統合されたSASTが欠かせません。高いハードルに思えるかもしれませんが、効果を発揮する開発者ファーストのSASTには、これらの機能がすべて必要です。だからこそ、Snyk Codeはそのすべてを提供します。組織に最適なSASTツールを選ぶ際は、SAST購入ガイドをご覧ください。
ここまで読んで、SASTとDASTテストの関連性が気になった方はいませんか？
SASTテストとDASTテストとは？
SAST（静的アプリケーション・セキュリティ・テスト）は、アプリケーションのソースコードだけを使って、データのソースからシンクまでの流れを解析し、その流れから潜在的なセキュリティ脆弱性や弱点を特定する手法です。一方、DAST（動的アプリケーション・セキュリティ・テスト）では、アプリケーションが適切な環境で稼働している必要があります。ツールは通信を監視したり、Webページをクロールしたり、アプリケーションとのやり取りを自動化したりして、セキュリティ上の問題に対して脆弱かどうかを判定します。詳しくは、SASTとDASTの違いと、両者を組み合わせる方法をご覧ください。
Capture the Flagを始めよう
オンデマンドのバーチャル入門ワークショップを見て、Capture the Flagの課題の解き方を学びましょう。