ブログへようこそ

IBMとポネモンによると、データ漏洩の平均コストは435万ドル（約4億7000万円）にも上る！企業がサイバーセキュリティに多額の投資をする必要性を感じるのも無理はない。毎日大量の顧客データを扱うリーガルテック企業にとって、そのリスクはさらに高い。データ侵害は、直接的な金銭的影響だけでなく、深刻な風評被害を引き起こす可能性があり、その修復ははるかに困難であることが多いため、サイバーセキュリティは法律専門家にとって最優先事項となっています。デジタルの世界が進化するにつれ、機密情報を保護するための戦略も、ますます高度化する脅威に対応する必要があります。

欧州リーガルテック協会（ELTA）は、今日のサイバーセキュリティの第一人者をデジタル会議室に集めた。Aikido Securityの共同設立者兼CROであるRoeland Delrue氏、Amberloの共同設立者兼製品責任者であるAidas Kavalis氏、Henchmanの共同設立者兼CTOであるWouter Van Respaille氏、Henchmanの成長責任者であるMichiel Denis氏が、リーガルテック企業に強固なサイバーセキュリティの枠組みを導入する方法について、それぞれの専門知識と見識を披露した。

高まるサイバーセキュリティの重要性

すべてのリーガルテック・アプリケーションが満たすべき基本的なサイバーセキュリティ基準とは何か、そしてこれらの基準は新たな脅威とともにどのように進化してきたのか。Aikido Securityの共同設立者兼CROであるRoeland Delrue氏は、安全なリーガルテック・アプリケーションの開発はコードから始まると強調する。

1. プログラマーはコードでアプリを書いている。セキュリティの最初のレイヤーは、コード自体が安全であることを保証することだ。
2. コードの準備が整うと、通常はコンテナで出荷される。コンテナはスキャンと監視が必要な第二のレイヤーとなる。
3. 第3のレイヤーは、アプリケーションがデプロイされる クラウド環境だ。

第4のレイヤーは、ユーザがアプリケーションにアクセスするためのドメイン（login.comやapp.com）である。

コンプライアンスと継続的モニタリング

Henchman社の共同設立者兼CTOであるWouter Van Respaille氏は、ISO 27001や SOC 2といった業界標準への準拠の重要性を強調した。これらの認証は単なるチェックボックスではなく、ベンダーがセキュリティに真剣に取り組んでいることを示す指標となる。同氏は、これらの認証を取得していない企業は、必要なリソースやセキュリティへのコミットメントが不足している可能性があると指摘した。

コンプライアンスにとどまらず、継続的な監視とバグ報奨金プログラムのような独創的なアプローチは極めて重要である。これらのプログラムには、システムを継続的にテストする倫理的なハッカーが参加しており、従来のスキャン・ツールを超えるセキュリティの追加レイヤーを提供している。ヴァン・レスパイユ氏は、Henchman社のアプローチを次のように語っている。「Aikido 当社のインフラとコードの両方を継続的にスキャンしています。さらに、バグ賞金稼ぎのためにIntigritiを使用しています。これは、ソーシャルハッカーの集団が当社のシステムを創造的に調査・探索するものです。従来のスキャン・ツールに比べ、このアプローチははるかに革新的です。また、Phishedを使って全従業員にフィッシング・シミュレーションを送信し、ゲーミフィケーションの要素を加えながら、フィッシングやセキュリティに対する意識を高めています。終わりのない機密データを扱う企業として、すべてを自社で行うのではなく、このようなパートナーシップを持つことが重要です。"

サイバーセキュリティは複雑な問題であるため、Amberlo社の共同設立者兼製品責任者であるアイダス・カバリス氏は、ベンダーを評価するために第三者を入れることが賢明であると指摘する。「その分野の専門家であれば、自分では思いもつかなかったような発見をすることができます。ISO27001やSOC 2規格が導入されていても、その証明書が現実と一致しているかどうか、どうすれば確認できるのでしょうか？専門家は、適切な質問をし、適切な事項が前もってチェックされていることを確認するのに役立ちます。"

法的データは非常に機密性が高く、貴重である

パネリストは、リーガルテック・アプリケーションは他のウェブ・アプリケーションと比較してユニークなサイバーセキュリティの課題に直面しており、金融機関とともにハッカーの最重要ターゲットであることに同意している。法務データは、金融データと同様、非常に機密性が高く、貴重なものです。「金融機関が金銭を扱うのに対して、法律事務所は顧客情報を管理しており、侵害された場合、より大きな被害をもたらす可能性があるという違いがあります。最近、法律事務所がハッキングされ、そのクライアントを標的にした攻撃がいくつかありました。したがって、法律事務所は間違いなく最もリスクの高いセクターのひとつだと思います」とカバリスは言う。

Delrue氏は、取り扱うデータの価値は、必要とされるセキュリティのレベルに影響するため、留意するよう促している：「例えば、契約書を保管せずにレビューするだけのリーガルテック業者と、多数のクライアントの実際の契約書を保管している業者とでは、大きな違いがあります。保有する機密データが多ければ多いほど、ランサムウェアやデータの売却によって金銭を脅し取ろうとするハッカーにとって、魅力的なターゲットになります。したがって、あなたがリーガルテックのベンダーであろうと消費者であろうと、潜在的な悪意のある行為者にとってのあなたのデータの機密性と価値を評価する必要があります。データの価値が高い場合は、一般企業よりも厳格なサイバーセキュリティ対策を実施することが極めて重要である。"

リーガルテック・セキュリティの評価

リーガルテック製品のセキュリティを評価する際、法律事務所は扱うデータの機密性と量も考慮し、アプリケーションに必要なセキュリティ対策が施されていることを確認する必要がある。

リーガルテックのプロバイダーとして、カバリスは顧客から3つのことを求められる：

1. ISOまたはSOC 2認証、GDPRコンプライアンス調査票。
2. 外部のサイバーセキュリティ評価：大規模な法律事務所では、外部の専門家を招き、アンバーロに適切なテクノロジーとポリシーが導入されているかどうかを深く掘り下げる技術セッションを依頼することが多い。
3. そして時折、セキュリティ・インシデントの歴史がある。「幸いなことに、これまで大きなセキュリティ・インシデントは発生していません。2017年にアンバーロを立ち上げて以来、有名なハッカーの拠点から我々のシステムに侵入しようとする試みを毎日のように目にしてきました」とカヴァリスは言う。

簡単にチェックできるのは、企業がISO 27001やSOC 2に準拠しているかどうかだ。しかし、Delrue氏は、これらの認証の内容を理解することの重要性を強調する。Delrue氏は、ISO27001やSOC 2は、長いセキュリティ・アンケートに答えるための近道であり、⅔のボックスに自動的にチェックが入るものだと考えている。しかし、SOC2ではカバーされないマルウェアスキャンなど、認証ではカバーされないものもあります。そのため、場合によっては標準的なISO認証では不十分で、より深い質問を追加した方がよいかもしれません。

オンプレミスかクラウドか？

GPTやその他のAI技術がもたらす急速な進歩に伴い、法律事務所におけるテクノロジーの評価はますます重要になってきている。しかし、オンプレミスかクラウドホスティングかという議論は常に存在する。これが何を意味するのか、まず見てみよう：

• オンプレミス型ソフトウェア：顧客が物理的にサーバーを所有し、そこでアプリケーションをホストする。
• プライベート・クラウド：マイクロソフト・アジュール、グーグル・クラウド・プラットフォーム、AWSを採用し、自社のネットワーク内ですべてのアプリケーションを実行する。
• クラウド：アプリケーションは完全にクラウド上で実行され、顧客はその技術を適応させる。

「車にはねられたくないから、ずっと家にいる。あるいは、実際にどこかに行って、道を渡るときはまず左右を見て安全を確認する。"

ヴァン・レスパイユはこの例えを使って、オンプレミスとクラウドを比較している。彼の見解では、オンプレミスに留まることは時代遅れである。「それは、多くのイノベーションから排除されることを意味します。すべての法律事務所にアドバイスしたいのは、クラウドを全面的に受け入れつつも、思慮深くアプローチすることです。セキュリティ・チェックリストがあることも知っておいてください。これらのチェックリストは、過度に複雑であったり、リソースを必要とするものである必要はなく、採用したいツールを評価するための基本的なアンケートで十分です。このアプローチにより、セキュリティの初期レイヤーが構築され、実際に何を購入するのかを明確に理解することができる。要約すると、「フルクラウド化を進めるが、どのツールを採用するかは知っておこう！」ということだ。

一定の基準を満たせば、デルル氏はオンプレミスも正当な選択肢だと考えている：「一流のオンプレミス・プログラムがあり、オンプレミスの管理方法を熟知した専任のセキュリティ担当者がいるのであれば、オンプレミスは間違いなく有効な選択肢です。しかし、質の高いオンプレミスのセキュリティは稀だと彼は考えている。「非常に専門性の高いクラウド・プロバイダーを相手にしていて、オンプレミスを管理する社内リソースがないのであれば、クラウド版を利用した方が安全でしょう。つまり、基本的にはリスクアセスメントなのだ。リスクをどこに置き、誰にそのリスクを管理させるか。

「オンプレミスは単一障害点になることが非常に多い。「一つの境界が突破されると、他のシステムにも簡単にアクセスできてしまう。オンプレミスのサイバーセキュリティにおいて、各アプリケーションが別々のセキュリティゾーンに隔離されているようなレイヤーアプローチはほとんど見たことがありません。

着想から展開まで

もちろん、リーガルテックのベンダーは、製品を作る前から、セキュリティの基準と対策を統合しておくべきである。

「ソフトウェア開発者のノートパソコンから始まる。開発者がコードを書き、そこで最初のチェックができる。それがAikido 仕事です」とDelrueは言う。「コードであれ、コンテナであれ、クラウドであれ、ドメインであれ、開発ライフサイクルのあらゆる部分で、Aikido セキュリティ・チェックを行うことができます」。しかし、厳しすぎると、開発プロセスが非常に遅くなります。Delrue氏が、脆弱性とセキュリティ問題のリスク分類（低、中、高、重要）を賢く使うようアドバイスするのはそのためだ。もし、「中」でブロックし始めると、開発が遅くなります。修正すべきセキュリティ・チェックがあるために、すべてのステップで止まってしまうからです。クリティカルな問題」だけをブロックして、「ハイな問題」は後で集中的に修正する方が少し楽な場合もある。

開発ライフサイクル全体を通じて、適切なセキュリティ態勢をとるために、さまざまなチェックを行うことができる。セキュリティ製品の世界では、これを「左遷」と呼ぶ。「これは、サイクルの早い段階で誰かを捕まえることを意味します。その時点でダメージは終わっているのですから」。とDelrueは言う。

データ漏えいで数百万ドルの損害が発生し、評判が糸でつながれたような時代では、サイバーセキュリティはリーガルテック企業にとってもはやオプションではなく、必要不可欠なものであることは明らかです。クラウドかオンプレミスか、あるいは新しい技術ソリューションを評価するにしても、デジタル時代において、サイバーセキュリティに投資するよりも高くつくのは、投資しないことだということを忘れないでください。

Aikido SecurityがDrata Integrationのマーケットプレイスに登場した！というのも、今日のサイバーセキュリティ規制の状況をナビゲートするのは、ハリケーンの中を綱渡りするようなものだからだ。サイバー脅威が進化するにつれ、それを抑制するための規制も進化しています。企業は現在、増え続けるコンプライアンス要件のリストと格闘している。

このブログポストでは、Aikido Drataの統合が、SOC 2とISO 27001:2022のコンプライアンスに取り組む上でどのように役立つかを説明します。

Aikido ドラタは何をするのか？

まず、これら2つのセキュリティ・プラットフォームについてよく理解しよう。

Aikido 何をするのか？

Aikido 、開発者のためのやり遂げるセキュリティ・プラットフォームです。Aikido 、すべての必要なコードとクラウドセキュリティスキャナを一箇所に集中させます。実用的なエンジニアによって作られたAikidoは、オープンソースのソリューションと開発者の体験を第一に考えています。何が重要かを見極めることに重点を置いているため、重要でないものに悩まされることはありません。顧客を獲得し、市場で成長し、コンプライアンスに打ち勝つ。

Aikido 、中小企業にとってセキュリティをシンプルにし、開発者にとっては業界の専門用語やお役所仕事、そして率直に言ってBSを使わずに実行可能にする。

ドラタは何をしているのか？

Drataは、企業のセキュリティ管理を継続的に監視し、エビデンスを収集すると同時に、コンプライアンスワークフローをエンドツーエンドで合理化し、監査に対応できるようにするセキュリティおよびコンプライアンス自動化プラットフォームです。Drataチームは、SOC 2やISO 27001:2022の準備など、あらゆる規模の企業がコンプライアンスを達成・維持できるよう、自動化を得意としています。

Aikido ドラタの統合はどのように機能するのですか？

AikidoDrata統合は、API統合を通じて、SOC 2とISO 27001:2022のエビデンスをDrataに直接自動的にプッシュします。Aikido 毎日PDFレポートを作成し、これを「外部エビデンス」としてDrataに同期します（方法はこちら）。Aikido また、「AIKIDO」というコードでコントロールを作成し、関連するSOC2とISO27001:2022の要件にリンクします。重要なのは、Aikido 脆弱性情報が常に最新であることを保証するということです。これにより、正確なリスク評価と効率的な修復が可能になります。

どのAikido パッケージでも、Drataと統合することができます。しかしもちろん、Drataの監査準備サービスを利用するには、Drataのライセンスも必要だ。

インテグレーションはどこにありますか？

AikidoDrataとの統合はここにある！一方、Drataの統合リストでは、"Vulnerability Scanning"、"CSPM" (Cloud Security Posture Management)、"Security Questionnaire "でAikido 見つけることができる。Drataのダッシュボードから直接、 Aikido 脆弱性スキャナとして接続することができる。

コンプライアンスに必要な技術的脆弱性管理要件を網羅

SOC 2やISO 27001:2022に準拠する使命があるにせよ、技術的な脆弱性管理対策を実施する必要があります。それには何が必要でしょうか？コードベースに対する真の脆弱性を特定すること。そして、優先順位をつけて対処すること。

ステップ1：コードベースのリスク評価を行う

システムを分析します。Aikido アプリケーションをスキャンさせることで、攻撃者が悪用する可能性のある弱点や脆弱性を特定します。

ステップ2：脆弱性の優先順位付け

特定した脆弱性について、深刻度とシステムへの潜在的な影響を考慮してランク付けを行う。最も影響の大きいものから優先的に対処する。

ステップ3：脆弱性への対処

パッチの適用ソフトウェアをアップグレードする。システムの設定を変更する。

ステップ4：有効性のテスト

脆弱性に対処した後は、その解決策がうまくいったかどうかをチェックしなければならない。最良の方法は、ペンテストを実行することだ。必要に応じてステップ3に戻る。注：ペンテストは、SOC 2またはISO27001:2022のいずれにおいても必須ではありません。

ステップ5：継続的モニタリング

上記のステップは、1回で完了するものではない。健全なシステムを維持し、新たな脅威や脆弱性を特定するためには、継続的な監視が不可欠である。そのために重要なのは、脆弱性管理プログラムを使ってコードベースを定期的にスキャンすることです。

Aikido 脆弱性管理プロセスを自動化します。

手作業でプロセスを実施するのは骨が折れるが、可能だ。その代わりに、Aikidoような使いやすい脆弱性管理プラットフォームを使うことをお勧めする。上記の5つのステップについて、Aikido どのように行うかを見てみよう。

ステップ1：防御をチェックする - コードベースのリスク評価を行う

Aikido お客様のコードとクラウドインフラにプラグインし、自動的にリスク評価を行います。システムを徹底的に分析し、攻撃者に悪用される可能性のある潜在的な脆弱性を特定します。Aikido エージェントレスなので、30秒で全容を把握することができる。高価なソフトウェアのインストールや、無料のオープンソースツールの設定やメンテナンスに費やす無駄な時間がなくなります。

ステップ2：真の脅威を特定する - 脆弱性に優先順位をつける

リスクアセスメントが完了すると、Aikido 脆弱性に優先順位をつけることで、あなたの脳を休ませます。システム内のすべての脆弱性の本当に長いリストを取得することは、圧倒される可能性があります！その代わり、Aikido 脆弱性を重複排除して自動分類し、本当に重要で悪用可能な脆弱性を提供します。今、あなたは最も重要な脆弱性に最初に集中することができます。

ステップ3：相手を倒す - 脆弱性に挑む

脆弱性への対処は手作業になりがちだが、Aikido プレッシャーを取り除き、これまで以上に簡単にできる。ワンクリックでPRしたいですか？Aikido自動修正機能を使えば、それが可能になります！さらに、Aikido 、パッチの実装、ソフトウェアのアップグレード、設定の変更など、すでに使用しているツールと完全に統合されています。

ステップ4：黒帯の取得-効果測定

私たちのアドバイスは、実施した修正の有効性を確認するためにペンテストを行うことです。これはなぜ重要なのでしょうか？セキュリティ対策の有効性を検証し、潜在的な攻撃に対するシステムの堅牢性を確保するためです。SOC 2もISO 27001:2022もペンテストを義務付けてはいませんが、推奨しています。Aikido 複数のペンテスト機関と提携していますが、どのコンサルタントを選ぶかは自由です。

ステップ5：安全の維持 - 継続的なモニタリング

安全なシステムを維持するには？もちろんAikido 継続的なモニタリングによって防御を維持します！24時間ごとにお客様の環境をスキャンし、新たな脆弱性やリスクをAikido します。SOC 2やISO 27001:2022に向けた準備や、日々の業務を通常通り行う上でも、脆弱性や脅威の発見と対処を積極的に行うAikidoで、安心感を得ることができます。

Aikido素晴らしい機能により、企業はSOC 2およびISO 27001:2022準拠のための技術的脆弱性管理要件を満たすことができます。そうすることで、データとインフラを保護する安全な環境を確立することができます。

利点：Aikido Drataを統合することで、効率が向上し、経費が節約できる。

Aikidoフォローアップ・プロセスを自動化

Aikido 、技術的な脆弱性管理を変革する自動操縦システムです。バックグラウンドでシームレスに動作しながら、継続的に監視を行います。重要な問題が見つかると、通知が届きます。

偽陽性に別れを告げる

従来のセキュリティ・プラットフォームでは、検出された脆弱性ごとに過剰な負荷がかかることが多い。それらがDrataに送られたとしても、誤検知を選別して排除しなければならない。しかし、Aikidoミッションは最初から、侵入してくる偽陽性を排除することだ。そのため、Aikido高度なオートトライエイジングエンジンは、効果的にノイズをフィルタリングし、正当な脆弱性だけをDrataに送信する。これにより、本物の脅威に集中し、貴重な時間を節約することができる。

警備費のコスト削減

セキュリティ分野は、複雑で強引な価格戦略に苦しむことが多く、セキュリティ・ソリューションを必要とする企業も同様に苦しんでいる。ユーザー数に応じて課金されるシステムもあり、開発者がアカウントを共有することでセキュリティが損なわれる可能性がある。また、大規模なチームでは、あっという間に料金がかさむこともある！また、コード量に応じた価格設定をするシステムもあるが、これもすぐにコストがかさむ。

Aikido 、このような常識にとらわれない、明確な定額制の価格モデルを採用しています。1組織あたり月額わずか314ドルからスタートするAikido価格戦略は、既存のソリューションと比較して約50％のコスト削減を可能にする。

Aikido ＋ドラータ＝大勝利

現実を直視しましょう。SOC 2またはISO 27001:2022を実施するには、技術的な脆弱性管理以上のことを行う必要があります。そう単純であればいいのですが、そうではありません！総合的なセキュリティ・コンプライアンス・ソフトウェア・ソリューションが必要なのです。Drataのようなプラットフォームは、複雑で時間のかかるコンプライアンスプロセスを自動化し、監査への準備を確実にします。

しかし、Aikido 脆弱性管理を行い、我々の統合を通じてDrataに証拠を提供することで、時間を節約することができる！これにより、技術的な脆弱性管理のあらゆる側面が非常に簡単になります。

お待たせしました。今すぐAikido 無料でお試しください（オンボーディングは30秒で完了します）。

あなたは自分の開発能力に自信を持っており、自分が作ったアプリにセキュリティや設定の欠陥が全くないわけではないことを知っています。あなたはまた、利用可能なスキャンツールの深いエコシステムを調査し、おそらく選択肢の多さに圧倒されたことでしょう。依存関係、Infrastructure as Code（IaC）構成、コンテナなどの脆弱性を特定するための、オープンソースのアプリ・セキュリティ・ツールの適切な「ポートフォリオ」とは何でしょうか？

正しい軌道に乗るために、コード・スキャンとセキュリティ・ツールの重要な10のカテゴリーを取り上げ、9つのOSSプロジェクトを推薦する：

• そのスキャンがアプリのセキュリティにどのように役立つのか。
• どのオープンソースプロジェクトをインストールし、どのように実行するか。
• 利用可能な場合は）いくつかの選択肢から選ぶことができる。

これによって、コードとクラウド構成に重大なセキュリティ問題がないか、アプリをスキャンするためのノーBSパスが手に入る。これほど素晴らしいことはない。

まあ、コンフィギュレーションと管理の部分はバラ色ではないが、それは後で説明しよう。

必要なもの

デスクトップでもラップトップでも、macOSでもWindowsでもLinuxでも構いません。

開発者環境はオプションだが、推奨される。このオープンソースのスキャンツール群を動かすには、ベースとなるOSにインストールしたくないソフトウェアをたくさんインストールする必要があり、大きなアップデートが必要になったり、オートコンプリートを汚染したり、すべてのプロジェクトで動作しないかもしれない特定のツールに固定されたりする。開発者環境は、すべての開発専用ツールをコンテナ化し、OSの他の部分からある程度隔離します。

幸いなことに、素晴らしいオープンソースのツールから選ぶことができる：

1. と Dockerという名前の新しいベアボーンコンテナをスピンアップすることができる。 デーヴン01 このように docker run --name devenv-01 -it ubuntu:24.04 sh
2. と デイトナこれは、開発ワークフローに必要な多くの「バッテリー込み」である： デイトナ・クリエイト -コード
3. また、Distroboxを使えば、あらゆるLinuxディストリビューションをターミナル内に組み込み、ソフトウェアをインストールすることができる。

開発者環境の素晴らしいところは、特定の「スタック」を使い終わったら、ワークステーションに影響を与えることなくコンテナを安全に削除できることだ。

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

CSPMはアプリのセキュリティにどのように役立つのか？

CSPMは、クラウド環境のセキュリティとコンプライアンスの強化を支援します。CSPM ツールは、アプリケーションとそのアップストリーム・サービスを業界のベスト・プラクティスや社内ポリシーに照らして継続的に監視することで、問題を評価し、その重要性に基づいて優先順位を付け、修復のための推奨事項を提示します。CSPM を使用することで、ベースラインとガードレールのオーナーシップを高め、自分自身や他者が脆弱なアプリケーションを本番環境に移行するのを防ぐと同時に、誤った設定や過度に寛容なユーザー・ロールを根絶することができます。

OSS CSPM プロジェクトをインストールして実行する：CloudSploit

CloudSploitをインストールするには、まずNode.jsが必要で、依存関係をダウンロードしてエンジンを実行する。

git clone https://github.com/aquasecurity/cloudsploit.git
cd cloudsploit
npm install

次に、CloudSploitにクラウドアカウントへの読み取り権限を設定する必要があります。 AWS, Azure, GCPそして オラクル.クラウドプロバイダーの指示に従って、レポの config_example.js ファイル をテンプレートとして作成します。 config.js ファイルに、最初の完全な診断を実行し、JSONで結果を得るために必要なすべての詳細を記述する。

./index.js --collection=file.json config.js

#2:オープンソースの依存関係のソフトウェア構成分析(SCA)

SCAはアプリのセキュリティにどう役立つのか？

あなたのアプリは、UIフレームワークから、メールアドレスのバリデータのような1つのLOCで使用するヘルパーライブラリに至るまで、あなたが現在依存しているオープンソースの依存関係の大きなツリーを必然的に持っています。SCAは、あなたのコードの拡張ファミリーのバックグラウンドチェックのようなもので、セキュリティの脆弱性やライセンスの問題を一度だけでなく、継続的に特定します。SCAツールは、新しい脆弱性と改善策を通知してくれるので、オープンソースのサプライチェーンが生産性の妨げではなく、助けであり続けるという確信を持つことができます。

OSS SCAプロジェクトのインストールと実行：Syft + Grype

ローカルでSCAを実行するには、Syftでソフトウェア部品表（SBOM）を作成し、GrypeでSBOMの既知の脆弱性を分析する必要がある。SyftとGrypeは同じチームが作っているので、多くのインストール方法をサポートしていますが、それぞれのワンライナーを推奨します：

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

ローカルワークステーションに Syft をインストールした状態で、コンテナ用の SBOM を作成することができる。 <YOUR-IMAGE> を、設定されたコンテナ・レジストリまたはローカル・ディレクトリにあるイメージと置き換える。

syft <YOUR-IMAGE> -o syft-json=sbom.syft.json

を手にすることになる。 sbom.syft.json を作業ディレクトリにコピーし、それをGrypeに入力する。

grype sbom:path/to/syft.json -o json

Grypeは、深刻度の詳細や既知の修正に関する情報を含む脆弱性の概要を以下のフォーマットで出力します。

{
"vulnerability": {
   ...
 },
"relatedVulnerabilities": [
   ...
 ],
"matchDetails": [
   ...
 ],
"artifact": {
   ...
 }
}

代替案と注意点

Trivyは、SCAのための堅実なOSS代替品である。全面的に1対1の機能パリティを提供するわけではないが、始めるには十分すぎるだろう。

#その3：秘密探知

秘密検知はアプリのセキュリティにどう役立つのか？

シークレット検出ツールは、公開したくないクレデンシャルについて、コードと設定をスキャンする。これらの秘密には、API キーやサードパーティプロバイダーへのアクセストークン、アップストリームデータベースのパスワード、証明書、暗号化キーなどが含まれます。いったんこれらの情報が公開リポジトリにプッシュされてしまうと、Git の履歴から削除するために骨の折れる作業をしなければならなくなります。

OSS秘密検知プロジェクトのインストールと実行Gitleaks

Gitleaks は、Git ログを解析することで、過去または現在にハードコードされた秘密が存在しないかリポジトリをスキャンします。その 見つける ビヘイビアは、すでにコミットされた秘密を特定する。 守る ビヘイビアはコミットされていない変更をスキャンし、ミスを未然に防ぐ。

最大限の制御を行うには、ソースからGitleaksをインストールすることをお勧めします。

git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build

Gitleaks の初回実行時には、基本レポートを作成し、新規の秘密暴露の結果のみを表示することができます。

gitleaks detect --report-path gitleaks-report.json

を参照する必要があります。 gitleaks-report.json ファイルを使って Git ログをスキャンし、ベースラインレポートを作成した後に追加されたシークレットだけを探します。

gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json

あなたの 所見.json ファイルには、各リーク候補のコミットハッシュと作者に関する詳細が含まれており、修正に集中するのに役立つ。

代替案と注意点

残念ながら、Gitleaks以外の選択肢はあまりない。他のオープンソースのシークレット検出プロジェクトは、最後のコミットから何年も経っている。もしあなたがサービス・プロバイダーなら、GitHubのシークレットスキャン・パートナープログラムに登録すれば、あなたのユーザーが誤ってあなたのシークレットトークンのフォーマットを彼らのリポジトリにコミットしてしまった場合に、それを特定することができます。

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

SASTはどのように役立つのか？

SASTは、アプリ・セキュリティ・ツールの目の細かい櫛のようなもので、コードベースを一行ずつ分析し、アプリを脆弱にする可能性のある構文、構造、ロジックに欠陥がないかをチェックします。SQLインジェクション攻撃、クロスサイト・スクリプティング（XSS）、バッファオーバーフローなどを想定してください。既知のCVEの一般的なデータベースと照合することで、確かなSASTツールは、大きなセキュリティ上の欠陥をテーブルの上に放置していないという確信を与えてくれます。

OSS SASTプロジェクトをインストールして実行する：セムグレップ

Semgrepはコードをスキャンし、バグを見つけ、30以上の言語をサポートし、呼び出すたびに確立されたコード標準を実施します。簡単に説明するため、Semgrep CLIに焦点を当てますが、これは複雑な製品のエコシステムの一部に過ぎません。

Semgrep CLIをインストールする最も一般的な方法は、Python/pipを使用することです。

python3 -m pip install semgrep

最初のスキャンを実行して、コードレベルの欠陥と脆弱性のレポートをJSONファイルとして作成する。

semgrep scan --json --json-output=semgrep.json

代替案と注意点

SASTの世界はチャンスにあふれている。もしSemgrepがうまくいかない場合は、Bandit（Python）、Gosec（Go）、Brakeman（Ruby on Rails）のような言語固有の代替手段をチェックして、自分自身で始めてみよう。

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

DASTはアプリのセキュリティにどのように役立ちますか？

SASTとは異なり、DASTはお客様のアプリに対して一般的に悪用される脆弱性をライブ環境でシミュレートします。あなたが書いたコードの構文や構造よりも、攻撃者があなたの本番環境に対して取るかもしれないアプローチを再現することに重点を置いています。DASTツールは、あなたが使用しているフレームワークやライブラリの既知のCVEをダブルチェックし、ログインしているユーザーがパーミッションの破損によって機密データにアクセスできるかどうか、またはあなたのアプリをはるかに悪い結果に導く複数の脆弱性の「有害な組み合わせ」をテストします。

OSS DASTプロジェクトをインストールして実行する：核

Nucleiはコミュニティ主導の脆弱性スキャナで、ローカル環境で実行されているセキュアにしたいアプリにリクエストを送るためにテンプレートを使います。YAMLを使ってカスタムテンプレートを書くこともできますが、Nucleiコミュニティには、あなたのアプリに対してテストするための設定済みテンプレートの広範なライブラリもあります。

Nucleiをインストールするには、ローカルのワークステーションにGoが必要です。

go install -vgithub.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

そこからNucleiを実行する最もシンプルな方法は、単一のターゲット（開発者環境でローカルに実行するアプリ）を指定し、Nucleiがデフォルトで有効化するテンプレート・ライブラリを活用することだ。

nuclei -u localhost:5678 -je nuclei-report.json

代替案と注意点

Zed Attack Proxy(ZAP)は、セキュリティ専門家と開発者のグローバルチームによって活発にメンテナンスされている素晴らしいスキャナーだ。しかし、このリストの他のものとは異なり、ZAPはデフォルトでグラフィカルなアプリだ。ターミナルを使うオプションもあるが、ここまでたどってきた他のプロセスと比べると、開発者フレンドリーとは言い難い。

#その6：インフラストラクチャー・アズ・コード（IaC）スキャン

IaCスキャンはアプリのセキュリティにどのように役立つのか？

今日、ほとんどのチームはTerraform、CloudFormation、そして "基本 "Kubernetes HelmチャートのようなIaCツールを使って、宣言的でバージョン管理された再現可能な方法でクラウドサービスをプロビジョニングしている。IaCスキャナは、これらのJSONまたはYAMLブループリントの脆弱性を特定し、安全でない状態を本番環境にデプロイすることを防ぎます。

OSS IaCスキャンプロジェクトをインストールして実行する：チェックオフ

Checkovは、Terraform設定、Helmチャート、Dockerファイルなど、多くのタイプのIaCコードをスキャンし、一般的な設定ミスや潜在的なセキュリティ脆弱性を検出します。AWS、GCP、Azure用の1,000以上のポリシーチェックが組み込まれており、このツールは、クラウド展開の現在のリスクと機会を数分で迅速に理解するのに役立ちます。

チームは、Pythonのパッケージマネージャーを使ってローカルにCheckovをインストールすることを推奨している。

python -m pip install checkov

そして、作業ディレクトリ（またはIaCファイルを保存している別のディレクトリ）に対してCheckovを実行し、出力としてJSONファイルを得ることができる。

checkov --directory .-o json

#7位：コンテナ画像スキャン

コンテナ・イメージのスキャンは、アプリのセキュリティにどのように役立つのか？

コンテナは非常に多くの複雑さを抽象化してくれるので、私たちはコンテナが大好きです。しかし、コンテナイメージを構築するときはいつでも、そのベースイメージやパッケージの依存関係から脆弱性を継承する可能性があります。コンテナ・イメージ・スキャナは、ベース・イメージやDockerfileの脆弱性を発見し、依存関係ツリーがどんなに深くても、悪用可能なアプリを無意識のうちにデプロイしてしまうことを防ぎます。

コンテナ・イメージの脆弱性はこうして生まれたのだ。

OSSコンテナ・イメージ・スキャン・プロジェクトをインストールし、実行する：Trivy

Trivyは、コンテナ・イメージを解析して、CVE、IaCの問題や設定ミス、シークレットの存在など、既知の脆弱性を調べることができる多機能なセキュリティ・スキャナーだ。オープンソースのTrivyプロジェクトを支えるAqua Securityチームは、10以上のデータソースから収集した脆弱性情報の公開データベースを維持している。

これまで推奨してきた他のインストール方法と同様に、最新のGitHubリリースから直接インストールする場合は、Trivyのスクリプトを使うことをお勧めします。

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.51.1

デフォルトでは、Trivyは指定したコンテナ・イメージに対して、脆弱性、設定ミス、秘密をスキャンし、その結果を標準のJSON形式で表示する。

trivy image --format json --output trivy-result.json <YOUR-IMAGE>

代替案と注意点

Grypeは、Syftが作成したSBOMを持つコンテナ・イメージをスキャンするのに最適なツールだ。AWSを利用しているのであれば、これもAmazon Inspectorが「一石二鳥」で重宝するところだ。

Amazon Inspectorも選択肢の1つだが、2つの大きな注意点がある。1つ目は、AWSのデプロイメントでしか動作しないこと、2つ目は、他のおすすめ製品のようにオープンソースのソフトウェアではないため、月額費用がかかることだ。

#8位：オープンソースのライセンススキャン

オープンソースのライセンススキャンはアプリのセキュリティにどう役立つのか？

商用製品にオープンソースソフトウェアを使用することの合法性は、法務チームやコンプライアンスチームに一度確認して忘れるようなものではない。OSS プロジェクトは、あなたが理解している以上に頻繁にライセンスを変更するため、エンタープライズ版にお金を払うか、代替案を探すか、プライベートコードの一部をオープンソース化する必要があります。ライセンス・スキャナは、変更を特定し、すぐに使えるソフトウェア部品表（SBOM）でセキュリティ監査を乗り切るのに役立ちます。

OSSライセンススキャンプロジェクトをインストールして実行します：Syft

最後のステップのGrypeと同様に、ローカルワークステーションにはすでにSyftがインストールされており、GrypeとのSCA統合を設定したときに既存のSBOMがあるかもしれません。まだない場合は、設定されたレジストリからコンテナイメージを参照するか、ローカルワークステーション上のパスを参照することで、すぐに新しいものを作成できます。

syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
syft /path/to/image -o syft-json=sbom.syft.json

画像の複雑さと依存関係の深さによっては、数千行に及ぶSBOMファイルが得られるかもしれない。すべてのJSON出力の中で、あなたは 出土品 の配列である。 ライセンス コンテナ・イメージが依存する各パッケージと依存関係の値を指定します。

{
"artifacts":[
   {
"id":"cdd2655fffa41c69",
"name":"alpine-baselayout",
"version":"3.4.3-r2",
"type":"apk",
"foundBy":"apk-db-cataloger",
"locations":[
       …
     ],
"licenses":[
       {
"value":"GPL-2.0-only",
"spdxExpression":"GPL-2.0-only",
"Type":"declared",
         …

単一のSBOMにこれらの詳細があれば、下流で行う必要のある変更や、準備を始めるべき移行について、ライセンシングの義務をスキャンすることができるようになります。また、次にセキュリティ監査が行われるときにも、頼りになるリソースを手に入れることができます。

代替案と注意点

前節で最初に紹介したTrivyには、ライセンススキャン機能があり、オープンソースの依存関係ツリーにあるプロジェクトに関連するリスクについて、意見付きの結果を提示してくれる。

#9位：マルウェア検知

マルウェア検知はアプリのセキュリティにどう役立つのか？

マルウェアスキャナーは、近年急増している脅威、つまり攻撃者によって依存パッケージに注入されたマルウェアを特定するのに役立つ。最近のzxバックドアの試みは、素晴らしい、そして恐ろしい例です。マルウェアスキャナは、コードをマージする前にこのようなソフトウェアサプライチェーン攻撃を検出し、CVEが公開された後に時間やコストのかかる修正が必要になるのを防ぎます。

OSSマルウェア検出プロジェクトをインストールして実行する：Phylum

PhylumのCLIツールにより、依存性解析のためにロックファイルをAPIに提出することができる。これは、ここで推奨する他のオープンソースツールとは少し異なり、解析はローカルのワークステーションでは行われない。その代わり、彼らのサービスで認証するためにPhylumにアカウントを登録する必要がある。

Phylumをローカルにインストールすることから始める。

curl https://sh.phylum.io | sh

それからアカウントを登録し、最初の分析を実行する。

phylum auth register
phylum auth login
phylum init
phylum analyze --json

Phylumの分析は、以下のような包括的なアウトプットを提供する。 真の または 擬似 の結果は、あなたのプロジェクトが Phylum のマルウェアチェックをパスしたかどうかに基づいています。各依存関係の拒否配列の下には、脆弱性の詳細な説明と OSS コミュニティからの修正アドバイスが表示されます。これにより、SAST、DAST、SCAテストの結果を集計し、どの脆弱性が依存関係に起因し、どの脆弱性が自分が書いたコードに直接埋め込まれているかを理解することができます。

{
"is_failure": true,
"incomplete_packages_count": 2,
"help": "...",
"dependencies": [
   {
"purl": "pkg:npm/next@13.5.6",
"registry": "npm",
"name": "next",
"version": "13.5.6",
"rejections": [
       {
"title": "next@13.5.6 is vulnerable to Next.js Server-Side Request Forgery",
"source": {
"type": "Issue",
"tag": "HV00003FBE",
"domain": "vulnerability",
"severity": "high",
         ...

#10: ランタイム・エンド・オブ・ライフ（EOL）の検出

EOLランタイムの検出は、アプリのセキュリティにどのように役立つのか？

アプリに含めるフレームワーク、ライブラリ、ランタイムが多ければ多いほど、古いバージョンやメンテナンスされていない依存関係に危険なレバレッジをかけられる機会が増えます。これは、公衆インターネットに直接公開されるランタイムにとって特に重要です。 EOL ランタイム検出機能は、コンテナ内のものであっても、ロックファイルを通して依存関係ツリーを読み取り、アップデートや移行に備えることができるように、かなり前に警告を発します。

OSSプロジェクトのインストールと実行： endoflife.date

endoflife.dateは、300以上のツールやプラットフォームに関するEOL情報のデータベースで、その多くはあなたのアプリの動作やセキュリティに不可欠なものです。特定のバージョンの依存関係がいつメンテナンスされなくなるかを知るために、曖昧なドキュメントサイトを探検したり、メーリングリストを探し回ったりする代わりに、必要なアップグレードの日付を素早く表示し、今後の努力の優先順位をつけることができます。

EOLデータを発見する最も簡単な方法は、プログラミング言語、データベース、フレームワーク、デプロイツール、クラウドサービスのCLIに特に注意を払いながら、サイトを探索することだ。

開発者としては、主要なランタイムやライブラリのEOLデータを調べるのに、よりCLI中心のアプローチを望むかもしれない。endoflife.dateには、JSONデータを出力するシンプルなAPIがあり、将来参照するためにローカルファイルに追加することもできる。

curl --request GET ୧
--url https://endoflife.date/api/nginx.json ୧
--header 'Accept: application/json' ୧
>> eol.json

新たな問題：コードスキャンとアプリのセキュリティデータの管理

ここまでたどってきたなら、オープンソースのコードと設定のスキャンツールの便利なツールキットを構築したことになる。ローカルに保存されたプロジェクトやブランチに対して、これらを実行し、コミット前のセキュリティ保証をはるかに向上させる準備が整いました。これを持って、左にシフトしてください！

しかし、あなたの未来がすぐに完璧になるわけではない。この新しいツールキットには大きな注意事項がある。

あなたはまだ、この先も責任がある：

1. 各ツールを個別に設定する。例えば、本番環境のセキュリ ティには関係ないので、わざわざスキャンしたくない特定のディレクトリや依存関係を許可リスト に入れるような、単純なオプションを考えてみましょう。各 CLI ツールの引数を、ドキュメントを読んだり、テストしたりすることで学ぶ必要があります。
   
2. 各リポジトリとブランチに対して各スキャナを実行する.単一のレポと2つのブランチがある場合でもメイン そして デヴ -つまり、脆弱性をスキャンするのに20回近く操作することになる。理想的なのは、リモートに変更をプッシュする前にこれらのスキャナーを実行することだ。
   
   もちろん、これを単純化する方法もあります。これらのオープンソーススキャナをチェーンして手動で実行するスクリプトを書いたり、コミット前の Git フックとして実行したりすることもできます。ターミナルにかかる時間は節約できますが、JSON の出力が速くなるだけです。 何をプッシュし、プルリクエストを作成する。
   
3. 膨大なJSON配列を調べ、洞察を得る。これらのツールは、多くの場合、数千行の出力を生成する。包括的であることは良いことですが、何十、何百もの潜在的なセキュリティ問題を調査し、その重大性を理解するために、1つ1つの問題を十分に理解することを望んでいる時間がある人はいないでしょう。
   
   時間が経つにつれて、Google Sheetsにインポートしたり、結果を表示するための単純なアプリを構築したりするように、JSONのフォーマットされていない行よりも直感的な結果を読み取る方法が必要になるでしょう。
   
4. 走行中に何が変わったかを理解する.セキュリティ・スキャンには2つの目的がある。第一に、あなたのコードとコンフィギュレーションに存在する問題を特定するのを助けること。2つ目は、構築時に新しい脆弱性を持ち込まないようにすることです。もしあなたが、ある脆弱性を修正したかどうかをすぐに理解できなかったり、新しい脆弱性があなたのコードに紛れ込んだときに通知されなかったりしたら、この取り組み全体が無駄な時間になってしまいます。
   
   1つのオプションは、出力JSONファイルをインクリメントまたはタイムスタンプし、CLIツールを使用してそれらを比較することです。 diff file1.json file2.json は素晴らしいスタンドアローンツールである。 git diff --no-index file1.json file2.json Git リポジトリにコミットされていないファイル。
   
5. 長期的な分析のためにデータを集約、保存、共有する。前にも述べたように、セキュリティ・スキャンは継続的な作業であり、TODOリストの単発項目ではない。さらに、あなたのスキャンの努力の結果は、あなたのローカル・ワークステーションに閉じ込めておくべきではありません。あなたの仲間は、たとえ同じようなツールキットを現在実行していなくても、自分が構築したものに最も関連する脆弱性について知りたがるでしょう。
   
   あなたは、これらの情報を1つの場所にまとめるデータ・プラットフォームを探索する必要があります。
   
6. Jira または GitHub でチケットを作成する。あなた、あるいは、同僚は、特定された各脆弱性を、必要なすべてのコンテキストと可能な改善策を含む関連チケットにエスカレーションしなければなりません。これが、セキュリティの透明性を確保し、仲間に協力してもらい、コンプライアンス基準で要求される監査ログを作成する唯一の方法です。これらのツールはいずれも、チケット・プラットフォームとの統合をサポートしていないため、チケットを手作業で作成する必要があります。
   
7. チケットの優先順位を重要度に基づいて決めるリポジトリがチケットで溢れるのは、プロジェクト管理の悪夢だ。これはアラート疲れの違うバージョンですが、同じように辛いものです：どのチケットに最初に焦点を当てるべきか、誰がどうやって判断するのでしょうか？もしOSSツールが重大度について助けてくれないのであれば、自分でその判断に時間をかけなければならない。
   
8. 各OSSツールのライフサイクルを管理する。ツールを最新に保つことであれ、自動化を構築することであれ、実行と結果をCI/CDパイプラインにループさせることであれ、ツールキットの長期的な有効性については、あなたが責任を負うことになる。あなたは、以前よりも優れたセキュリティの態勢を持つかもしれないが、現実の態勢にどのような代償を払うことになるのだろうか？
   
9. プロジェクトがメンテナを失ったらどうなるのだろうと、心配したり不安になったりする。依存関係やランタイムがEOLになり、問題が発生する可能性があるなら、ローカルの開発環境が依存しているツールやプラットフォームも同様です。残念なことに、オープンソースプロジェクトは、長期的に持続可能ではない資金調達やメンテナモデルに基づいて構築されていることが多い。しかし、アプリのセキュリティを改善しようとするとき、新しい脆弱性や攻撃方法を発見する助けにはなりません。

開発者ツールの現在の話題は、「開発者エクスペリエンス（DX）」という1つのコンセプトの周りに渦巻いている。DXが優れていればいるほど、ツールが統合され、使用され、大切にされ、支持される可能性は高くなる。そして正直に言おう、このローカルで運営されているOSSスキャンツールキットのDXは、特に素晴らしいものではない。プロセスやデータは完全に自分のものだが、並外れたコストと時間がかかる。高度なアプリ・セキュリティのためにいくら払うつもりですか？

オープンソースのセキュリティ・ツールは素晴らしいものです。私たちは、Node.jsアプリを一般的かつ重要な攻撃から自律的に保護するためのウェブ・アプリケーション・ファイアウォールさえ構築しました。この素晴らしいOSS基盤の上に構築されたものでさえも。

新しいアプリ・セキュリティ・ソリューション：Aikido

Aikido 、これらすべてのオープンソースプロジェクトと、さらに多くのものを統合している。

最新の変更をコミットする準備のたびに10以上のツールを実行する代わりに、リポジトリ、Dockerイメージ、クラウドプロバイダをAikido 一度追加するだけで包括的なスキャンを行うことができます。Aikido 、継続的なスキャニングのためにバックグラウンドで、またはプルリクエストごとにターゲットを絞った推奨のためにCI/CDパイプラインで自動的に実行され、新しい脆弱性からあなたを守ると同時に、数ヶ月または数年間あなたのコードベースに潜んでいた既存の脆弱性を指摘します。

JSONの解析や複数のデータソースのマージ、真実のソースを作成するための高価なデータ管理プラットフォームへの出費を心配する必要はありません。さらに、これらのオープンソース・プロジェクトの間にカスタム・ルールと特別な「接着剤」を構築し、社内に専門のセキュリティ・リサーチャーがいなければできないような相関関係や結果を明らかにしています。

Aikido また、GitHubやSlackのようなタスク管理やメッセージングプラットフォームと統合し、事前に優先順位付けされたチケットを作成します。すべてのコンテキスト、ドキュメント、および自動修正提案により、チームの誰もが問題をピックアップし、迅速かつ包括的に改善することができます。

もしこれらのオープンソースツールや他の多くのツールがなかったら、アプリのセキュリティははるかに悪化していただろう。それは紛れもない事実だ。しかし、開発者向けツールがローカル・ワークステーション上で、ターミナル内で動作するということは、無限の柔軟性と本質的な隔離性を併せ持つことを意味する。私のマシンでは動いた」というミームは、言い方が違うだけで、ここでもまだ当てはまる：

もしあなたが、このオープンソースのツールキットを構築するすべての負担を、同じプロジェクトの上にすでに構築されているプラットフォームに置き換える別の方法を探しているなら、 Aikido 無料で試してみることを検討してほしい。

しかし、新しいツールや依存関係をワークフローに組み込む一方で、AikidoWeb Application Firewallに、あなたのNode.jsアプリを最も悪質な脆弱性からも自律的かつ継続的に保護させるべきです。結局のところ、最高のDXは、ツールが本当にあなたのためにすべての難しい仕事をするときです。

AICPA SOC 2認証をご検討中でしょうか。Aikido 最近、当社のシステムとセキュリティ管理の設計がAICPAのSOC 2要件を満たしていることを確認するために審査を受けました。私たちは監査中にSOC 2基準について多くのことを学んだので、同じプロセスを開始する人に役立つと思われる洞察のいくつかを共有したいと思います。

ISO27001/2022に準拠するための ISO 27001:2022に準拠するために.

タイプ1とタイプ2の比較

最初に理解しておくべきことは、SOC 2認証には2つの異なるタイプがあるということである：SOC 2 Type 1とSOC Type 2である。SOC認証について考え始めたばかりであれば、タイプ1が最初の一歩として良いかもしれません。取得が早く、要件もそれほど厳しくない。また、タイプ1はタイプ2よりも安価です。

しかし、その違いは、長期間にわたる監視を対象としていないことである。SOC 2タイプ1の監査では、サイバーセキュリティ対策はある特定の時期にチェックされるだけです。対照的に、SOC Type 2 の認証プロセスでは、一定期間にわたってセキュリティ管理策がテストされます。事実上、タイプ1ではセキュリティ対策の設計がテストされますが、タイプ2では運用の有効性もテストされます。

注：ISAE3402タイプI報告書についてもお読みください。これは欧州の代替案であるが、実際にはほとんどの業界では気にする必要はない。欧州の報告書が必要だと分かっているのでなければ、SOC 2をお勧めします。

SOC 2信託サービスの基準

SOC監査人は通常、5つの信託サービス基準を用いてSOC 2準拠の企業を評価する：

• セキュリティ：不正アクセスからデータとシステムを保護する。
• 可用性：必要なときに顧客データにアクセスできるようにする。
• 守秘義務：機密情報が十分に保護されていることを確認する。
• プライバシー：個人情報を保護する。
• 処理の完全性：システムがデータを正確かつ確実に処理すること。

すべての企業が5つの基準すべてを含める必要はない。SOC 2監査の準備の一部は、顧客がどの基準を要求するかを決定することである。

さらに業界特有の基準も存在する。例えば、クラウド・サービス・プロバイダーは、クライアントのデータ暗号化要件がより厳しく、ヘルスケア・プロバイダーは健康情報を保護する必要がある。

SOC 2認証取得のヒントトップ5

1.SOC2に "準拠 "することはできない。

ISO 27001とは異なり、SOC 2準拠の状態に到達することはできません。これは、潜在的な顧客が企業のセキュリティ体制を評価するために要求できるレポートです。顧客は、その企業がビジネスを行うのに十分安全かどうかを自分で判断しなければなりません。

指定された基準への準拠を証明するSOC 2報告書は取得できるが、それは非準拠から準拠になることを意味しない。だからといって、ビジネスパートナーにとっての価値が下がるわけではありません。ビジネスパートナーは何が必要かを知っており、SOC 2監査報告書を要求することが多い。

例えば、SOC 2では必ずしもペンテストを実施する必要はありませんが、ISO 27001ではペンテストの実施が強く推奨されています。SOC 2コンプライアンス・モニタリング・プラットフォームのトップ企業の1つであるVantaは、SOC 2を本質的なセキュリティ基準に達しているとみなされるために乗り越える必要のあるハードルとして扱うことを推奨しています。しかし、そのハードルを乗り越えた後、さらに1マイルを進むかもしれませんし、顧客はおそらく、さらなる安心感を評価するでしょう。

その意味で、SOC 2準拠報告書は、貴社がSOC 2信託サービスの基準を満たしていることを監査人に納得させたことを意味します。

2.タイプ2はコンプライアンス観察期間に基づく

SOC 2 タイプ 2 レポートは、監査ウィンドウと呼ばれる観察期間にわたって、セキュリティ体制をチェックする。監査期間は 3 か月から 1 年の間で選択できる。これは、SOC 2 Type 1よりもはるかに徹底したものであり、利害関係者や見込み顧客は、セキュリティ・システムとデータ・セキュリティについてさらなる安心感を得ることができる。

監査窓口を選択するには、監査人と相談する必要がある。監査期限は、規制上の要件、顧客の期待、セキュリティのフレームワークや管理策を開発した時期などの要因によって異なります。

3.SOC 2とISO 27001の比較：潜在顧客が米国にいる場合は、SOC 2が適している！

一般的に、米国の企業はSOC 2報告書を依頼することが多いが、欧州の企業はISO 27001に依存する傾向が強い。これは、SOC 2がアメリカの規格であるためです。できることなら両方取得しましょう。私たちも2023年にISO 27001に準拠しました。両方ができない場合は、顧客や見込み客がどこに拠点を置いているかに基づいて選択する。

貴社の顧客が米国にいる場合、SOC 2報告書を探している可能性が高い。

4.米国内の監査法人に依頼することをお勧めします。

欧州を拠点とする場合、SOC監査人はたくさんいる。彼らはおそらく非常に優秀ですが、米国企業に報告書を信頼してもらいたいのであれば、米国の第三者SOC 2監査人に依頼するのが理にかなっています。

5.顧客がSOC 2報告書を要求できる安全なシステムを使用する。

顧客がSOC 2報告書を簡単に請求できるようにする必要がありますが、簡単にしすぎてはいけません。ハッカーがセキュリティの弱点を特定するために利用するかもしれません。

電子メールは使わず、ダウンロード後にレポートがどうなったかを追跡できるツールを使いましょう。誰が要求したのか、いつ要求されたのかを追跡し、透かしやパスワードによる保護も検討すべきです。最善の方法はNDAの使用である。

Aikido 継続的なSOC 2コンプライアンス

現在、Aikido セキュリティは、SOC 2のすべての基準を満たしています。また、コンプライアンス・モニタリング・プラットフォーム（Vanta、Drata、Secureframe、Thoropassなど）と提携し、現在のセキュリティ管理に関するデータを定期的に同期し、Aikido当社のお客様が強固なセキュリティ体制を維持できるようにしています。

SOC 2 タイプ2レポートを請求する

Aikido2 Type 2証明書は、セキュリティ・トラスト・センターにてご請求いただけます。

また、SOC 2認証を検討中で、まだ質問がある場合は、LinkedInで私とつながれば、そのプロセスについてより詳しくご説明させていただきます。

あなたは、最新のウェブアプリケーションがあらゆる攻撃に対して本質的に脆弱であることを知っています。また、アプリケーションのセキュリティが完璧であることはあり得ないが、昨日よりも明日、より良くすることは可能であることもご存知でしょう。

問題は、エンタープライズ・グレードの（つまり高価で複雑な）セキュリティ・ツールを使っているにせよ、オープンソースのプロジェクトをCI/CDパイプラインやGitコミット・フックに寄せ集めてベストを尽くしているにせよ、ツールキットでは何も見えてこないということだ：

• あなたのアプリは、あまり理想的でないプログラミングプラクティスや、安全でない依存関係などによって、どのように 脆弱になる可能性があるのか。
• どこで 脆弱性が潜んでいる可能性は高い。 package.json ファイル。
• 特定の脆弱性をすぐに修正すべき理由と 、他の脆弱性の優先順位が低い理由。

Aikido 、適切な セキュリティ修正を迅速に適用し、コードの出荷に戻る必要がある開発者にとって、アプリのセキュリティを適切かつ効率的にするために存在します。私たちが開発者中心のセキュリティ・プラットフォームで行っているように、一般的な脆弱性にまつわるノイズを減らし、3つの重要な詳細に焦点を当てます：

• TL;DRは、あなたが恐れるに足るだけのことを教えてくれる...そして、あなたの教育的検索を続けるための正しいキーワード。
• これは私に影響しますか」という質問に対する簡潔な答えで、イエスかノー（✅かᑕ）かを明確にし、簡潔に説明すること。
• 高価なツールや高価なリファクターを必要としない「どうすれば直りますか？

#1位：SQLインジェクションとNoSQLインジェクション

TL;DR: この古典的な脆弱性は、未サニタイズ、未認証のユーザー入力によって実現され、攻撃者はあなたのデータベースに対して直接クエリを実行することができます。攻撃者はそこからデータを抽出したり、レコードを変更したり、削除したりすることができます。

これは私に影響しますか？

• アプリがSQLやNoSQLデータベースとやりとりしている場合。インジェクション攻撃は何十年も前から存在しており、自動化された攻撃はすぐに一般的なエクスプロイトでエンドポイントを調査し始めます。
• データベース・レコードに基づく動的コンテンツがない場合、 🙅。これは、完全にクライアントサイドであるか、静的サイトジェネレータ(SSG)を使用しているか、データベースを使用してサーバーサイドレンダリングを行っているが、ユーザーからの入力を受け入れないためです。

どうすれば直るのか？ 何よりもまず、すべてのユーザー入力をサニタイズし、検証して、不要な文字や文字列を排除する。パラメータ化されたクエリを可能にするオープンソースのライブラリやフレームワークを活用し、ユーザ入力をデータベースのクエリに決して連結しないでください。Node.jsを使用している場合は、SQL/NoSQLインジェクション攻撃などから自律的にプロジェクトを実行する、オープンソースのセキュリティエンジンRuntimeをご検討ください。

#その2：クロスサイト・スクリプティング（XSS）

TL;DR： XSSもインジェクション攻撃の1つで、攻撃者が悪意のあるスクリプトを他者に送信し、認証情報や機密データを収集する可能性があります。

これは私に影響しますか？

• ✅ アプリがユーザーの入力を受け入れ、動的コンテンツとして別の場所に出力する場合。
• ユーザーの入力を全く受け入れない場合は 🙅。

どうすれば直りますか？ SQL/NoSQLインジェクション攻撃と同じように、ユーザー入力を href = "/stock/stock_detail.html? アンカー・タグの属性で、プロトコルが ジャバスクリプト.のような JavaScript メソッドを使用する場合は注意してください。 インナーHTML またはリアクトの dangerouslySetInnerHTMLこれは、出力中に文字列に埋め込まれた任意のコードを実行することができます。どのようなアプローチをとるにせよ、HTML出力をサニタイズするには、次のようなオープンソースのサニタイザーを使用する。 DOMピュリファイ を使用して、クリーンで実行不可能なHTMLのみをユーザーに送信します。

#その3：サーバーサイドリクエストフォージェリ（SSRF）

TL;DR： SSRF攻撃は、悪意のある行為者があなたのアプリを悪用してその基礎となるネットワークと相互作用させ、潜在的により脆弱なサービスや有利なサービスにジャンプするプロキシのように操作することで発生します。

これは私に影響しますか？

• あなたのアプリが、ユーザーデータを使って特定の操作を行う他のサービスやAPIとインターフェイスしている場合 ✅ たとえ許可リストを使って、既知の信頼できるエンドポイント間でのみトラフィックを制限していたとしても。
• 本当に静的なら、🙅。

どうすれば修正できますか？ IPアドレスやホスト名を正規表現で検証するのは良い方法ですが、通常、8進エンコーディングのようなバイパスが起こりがちです。より確実な2つの解決策は、allowlistとあなたのプラットフォームのネイティブURLパーサーを使用して、安全で既知のホストのみに入力を制限することと、フェッチリクエストでリダイレクトを無効にすることです。フレームワークによっては、Node.jsのssrf-req-filterのようなオープンソースのプロジェクトを自由に活用して、内部ホストへのリクエストを適切に拒否することもできます。

#その4：パス・トラバーサル

TL;DR： このセキュリティ上の欠陥により、攻撃者は、ウェブサーバ上のファイルやディレクトリにアクセスする際に ../ シーケンスや絶対パスでさえも。ダブルエンコーディングのような卑劣な手口を使い、攻撃者はフレームワーク特有のフォルダ・ファイル階層や一般的なファイル名を使って貴重な情報を見つけることができる。

これは私に影響しますか？

• ✅.あなたのアプリはウェブサーバー上で実行され、ファイルシステムへの参照を含んでいます。

どうすれば直りますか？ 最初のステップは、ウェブサーバのルートディレクトリから、環境変数やシークレットを含むような機密性の高いファイルを削除することです。

環境変数や秘密を含むような機密性の高いファイルは、決してウェブサーバのルートディレクトリに保存しないようにしてください。また、これらのファイルを /静的 そして /パブリック フォルダー Next.jsプロジェクト.最後に ../ パス区切り文字とそのエンコードされた変種をユーザー入力から取得する。

ランタイムはパストラバーサルでも素晴らしい働きをする。

#5位：XML eXternal Entity (XXE) インジェクション

TL;DR： XXE攻撃は、XMLパーサーの弱点を利用し、文書型定義（DTD）によって参照される外部エンティティを、検証やサニタイズなしにフェッチし、処理することを可能にします。攻撃の種類と深刻度は、主に攻撃者のスキルと、インフラストラクチャ・プロバイダーからのOSレベルのセキュリティ/許可によって制限されます。

これは私に影響しますか？

• ✅ SAMLを使用したシングルサインオン認証フローなど、何らかの理由でXMLを解析する場合。
• アプリの中でXMLを扱う必要がないのであれば🙅！

どうすれば直りますか？ XMLパーサーで外部DTD解決を無効にします。XMLペイロードにはDTDが含まれているのが普通なので、DTDを完全に拒否することはできません。

#その6：デシリアライズ

TL;DR： 攻撃者は、アプリに組み込まれたデシリアライズ関数（たとえば unserialize() node-serializeから）リモートでコードを実行したり、サービス拒否を実行したり、あるいはリバースシェルを作成したりすることができる。

これは私に影響しますか？

• アプリがユーザーとの対話から直接、またはCookie、HTMLフォーム、サードパーティAPI、キャッシュなどのバックグラウンド機能/サービスを通じてデータをデシリアライズする場合。
• 上記のいずれでもなく、完全に静的なアプリを実行している場合は🙅。

どうすれば直りますか？ 一般的に、ユーザー入力（別名、信頼できない）データのデシリアライズは避けてください。どうしても必要な場合は、信頼できる署名、証明書、IDプロバイダーに基づいて、認証され許可されたユーザーからのデータのみを受け入れるようにしてください。

#7位：シェル・インジェクション／コマンド・インジェクション

TL;DR: ウェブサーバとアプリが実行されるOSの基礎となるシェルに直接ユーザ入力を渡すため、攻撃者は任意のコマンドを実行したり、ファイルシステムをトラバースしたりすることができます。

これは私に影響しますか？

• アプリがファイルシステムやシェルと直接やりとりする場合。 猫.
• 🙅 既にフレームワークのAPIやメソッドを使って、実行する必要のあるコマンドに引数を安全に渡したり、SSGのようにファイルシステム/シェルとやりとりする必要がない場合。

どうすれば直りますか？ ユーザー入力を直接コマンドに取り込んだり、直接コマンドを呼び出したりするのは避けましょう。代わりに、以下のようなフレームワークのAPI/メソッドを使います。 child_process.execFile() Node.jsでは、文字列のリストで引数を渡すことができます。このような保護があったとしても、攻撃者がウェブ・サーバを「エスケープ」して、次のようなアクセスをしてくるのを防ぐため、必要なビジネス・ロジックに必要な最小限の権限でアプリを実行するようにしてください。 ルート-フォルダとファイルのみ。

そうそう、もう1つ親切な注意喚起を追加するために戻ってきた。 ランタイム を1つのコマンド (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) を使って、一般的なシェル/コマンドインジェクション攻撃からアプリを即座に保護することができます。

#8位：ローカル・ファイル・インクルージョン（LFI）

TL;DR： LFI攻撃は、あなたのアプリを騙して、Webサーバーを実行しているシステム上のファイルを公開させたり、実行させたりします。パストラバーサル攻撃は攻撃者にファイルを読ませるだけですが、LFI攻撃はアプリ内でそれらのファイルを実行するため、リモートコード実行（RCE）のようなアプリセキュリティの脆弱性の羅列にさらされることになります。

これは私に影響しますか？

• アプリがユーザー入力としてファイルへのパスを使用する場合、 ✅。
• アプリがアクションを完了するためにユーザーがパスを提供する必要がない場合は、🙅。

どうすれば直りますか？ 常にユーザー入力をサニタイズして、上で説明したパストラバーサル手法を防いでください。ローカルファイルシステム上のファイルを、通常 "安全な" /パブリック または /静的 フォルダで、アプリが読み取りと実行を許可されるファイル名と場所を allowlist で指定する。

#9位：プロトタイプ汚染

TL;DR： これは JavaScript固有の脆弱性 を使うと、攻撃者はアプリのグローバル・オブジェクトを操作できる。 __proto__.新しいオブジェクトは、アプリ全体に継承され、機密データへのアクセスや、権限のさらなるエスカレーションを与える可能性がある。

これは私に影響しますか？

• JavaScriptを使用している場合は、✅。
• JavaScript以外を 使用している場合は、🙅！

どうすれば直りますか？ まず、allowlistやオープンソースのヘルパーライブラリを使って、ユーザー入力からキーをサニタイズすることから始めよう。保護機能を拡張するには Object.freeze() を使ってプロトタイプの変更を防ぐこともできる。 -disable-proto=削除 Node.jsで提供されているフラグです。

#10位：オープンリダイレクト

TL;DR： この一般的なフィッシングでは、攻撃者は次のようなカスタムURLを作成します。 https://www.example.com/abc/def?&success=true&redirectURL=https://example.phishing.com 攻撃者は、リダイレクトを他の脆弱性と連鎖させることができます。さらに、攻撃者はリダイレクトを他の脆弱性と連鎖させることで、より大きな影響を与え、アカウントの乗っ取りなどにつなげることができます。

これは私に影響しますか？

• アプリがアクションを完了した後、ユーザーを別のページ/ビューにリダイレクトする場合。 example.app/ダッシュボード 認証成功後
• もしあなたがまだ静的に生成された人生を生きているのなら、🙅。

どうすれば解決できますか？ まず、アプリからパラメータベースのリダイレクトを削除し、ユーザーが特定のアクションを行った後にリダイレクトできる、信頼できるドメインとパスの許可リストに基づいた固定リダイレクトに置き換えます。これは、ユーザーエクスペリエンスを若干低下させるかもしれませんが、より良いアプリのセキュリティのための有意義な妥協であり、クレジットカードの明細に記載された奇妙な出費をあなたのせいにするようなものではありません。

アプリのセキュリティの次は？

もしあなたが、攻撃の範囲やそれらから守るために必要なすべての作業に圧倒されていると感じているのなら、あなたは一人ではないことを知っておいてほしい。

これらのセキュリティ上の問題や脆弱性の可能性をすべて自分で解決できるとは誰も期待していない。SQLインジェクション攻撃だけでも何十年も前から存在し、洗練されたアプリやフレームワーク、ライブラリにあるCVEを、人々は今でも常に見つけている。だからといって、これらのセキュリティ問題を大目に見るべきだというわけではありません。もしあなたのプロジェクトが、これらのアプリのセキュリティ問題トップ10のいずれかに✅当てはまったら、対策を始めるべきです。

まず、 Aikido登録し、アプリのセキュリティに対する真の脅威に焦点を当てましょう。2分で、しかも無料で、リポジトリをスキャンし、アプリの特定のアーキテクチャや、実装した機能、関数、ヘルパーライブラリに基づいて、関連する詳細と、最も重要な脆弱性のためのガイド付き対策を得ることができます。Aikido使えば、重要な範囲に絞り込んでスマートな修正を迅速に実装し、最新のコミットで導入された新しいセキュリティ問題を即座に知ることができます。

次に、オープンソースの組み込みセキュリティエンジンであるRuntimeをNode.jsアプリに追加します。Runtimeは、様々なインジェクション、プロトタイプ汚染、パストラバーサル攻撃をサーバレベルでブロックすることにより、即座に自律的にアプリを保護しますが、Webアプリケーションファイアウォールやエージェントベースのアプリケーションセキュリティ管理プラットフォームのようなコストや複雑さは必要ありません。Runtimeは、アプリとユーザがこれらの一般的なセキュリティ問題から安全であることを確信させるだけでなく、リアルタイムデータをAikido フィードバックして、現在の攻撃ベクトルを可視化し、修正の優先順位付けに役立てることができます。

これで、あなたは正しいスタートを切ることができた：

• あなたのアプリは、 あなたがかつて考えていたよりも多くの点で脆弱である。
• 最も重要な問題を最初に解決するために、時間と注意をどこに 集中させるべきか。
• なぜアプリの セキュリティと脆弱性スキャンは一度だけの努力ではなく、継続的なプロセスなのか？ Aikido.
  

TL;DR 私たちは多くの資金を調達し、大きく羽ばたく準備ができた。

私たちは、開発者に "BSなし "のセキュリティを提供するために1,700万ドルを調達しました。Singular.vcの Henri Tilloy氏を取締役に迎え、Notion Capitalと Connect Venturesが加わりました。このラウンドは、シード資金として530万ドルを調達してからわずか6ヶ月後のことです。早いですね。

私たちがAikido 設立したのは、開発者が問題を抱えているからです。セキュリティとコンプライアンスの要件は、もはや大企業だけのものではなく、あらゆる規模の企業、特に顧客を獲得し、規模を拡大しようとしている中小企業にとって、必要性が高まっています。SOC2、ISO 27001、CIS、HIPAA、そして今後予定されている欧州のNIS 2指令のようなコンプライアンス基準は、ソフトウェア企業、特にヘルステックやフィンテックのような企業への販売や機密データを扱う企業にとって基本的な要件になりつつあります。

しかし、この増大するコンプライアンスの負担は、セキュリティの専門家としての機能を期待されている開発者の肩にかかることが多い。Aikido 、必要なコードとクラウドセキュリティスキャナを1つのシンプルで使いやすいインターフェイスにまとめ、最高のオープンソースを活用したオールインワンプラットフォームです。私たちはフリーミアムで、セルフサービスで、フードの下に何があるのか、いくらかかるのかをオープンにしています。

私たちは、業界のベテランが率いる米国やイスラエルの企業が長い間支配してきた、確立された緊密なセキュリティ業界におけるアウトサイダーの挑戦者です。確かに、30年前からセキュリティ・ツールはありましたが、私たちは全く異なる立場から出発しています。私たちは、購入者がユーザーであるセキュリティ・プラットフォームを構築しています。よくあることだが、CISOが買い手であるにもかかわらず、どこかの貧弱な開発者がユーザーになっている。

私たちは、以前、そのような貧しい開発者になったことがある。私たちは、時間とお金を浪費する不格好なレガシー・セキュリティ・ツールで作業することのフラストレーションを感じてきました。私たち自身もCTOとして、無関係なセキュリティ・アラートに何百時間も浪費しました。私たちは、これらのツールがF-16のコックピット内部のように見えることを知っています。複雑で誤ったアラートに振り回され、チェックするのをやめてしまう。私たちは、開発者がただ問題を修正し、楽しい機能の構築に進みたいと考えていることを理解しています。

アンリとSingularと一緒に仕事ができることに興奮しています。彼は、私たちが実際に製品を理解していると感じた最初の投資家の一人で、私たちを単なる表計算ソフトとして見ていませんでした。彼は、私たちが「 シンプルで、オープンソースを活用し、セットアップと使用が簡単でありながら、Aikido 企業のコンプライアンスとセキュリティ要件を一度に満たしてくれる 」という「セキュリティに対する信じられないほどユニークなアプローチ」を持っていると信じています。(私たちは、彼の素敵な引用と賛辞も気に入っています）。

立ち上げから1年足らずで、すでに3,000以上の組織と6,000人以上の個人開発者に利用されています。Vismaが、175社以上のポートフォリオをすべて確保するために当社を選択したことは重要であり、当社が正しい道を歩んでいることを確認しました（疑っていたわけではありません ;）。私たちの顧客の30％は米国におり、開発者や中小企業がセキュリティを確保できるよう、さらなる国際的な拡大を目指しています。

この新たな1,700万ドルのシリーズA資金調達により、我々はプラットフォームをさらに深化させ、Aikido グローバルなステージに押し上げ、中小企業にとってセキュリティをシンプルなものにし、開発者にとって業界の専門用語やお役所仕事、そして率直に言ってBSなしに実行可能なものにすることができる。

参加したいですか？