ブログへようこそ

ヘント、2023年11月14日

成長中のSaaS企業向けに開発者ファーストのソフトウェア・セキュリティ・アプリケーションを提供するAikido Securityは本日、Notion Capitalと Connect Venturesが共同主導するシード・ラウンドで500万ユーロを調達したことを発表した。パートナーであるRaif Jacobsと元Google CFOのPatrick Pichetteが率いるInovia CapitalPrecede Fund Iからの投資や、VantaのCEOであるChristina Cacioppoを含むエンジェル投資家の豪華な顔ぶれも加わった。

今回の投資は、ソフトウェアの機能開発、特にAikidoユーザー・エクスペリエンスと自動トリアージ機能をクラス最高のものにすること、製品をシンプルなものにすること、製品、開発、マーケティング、営業の各チームでスタッフを雇用すること、Aikido 顧客基盤をさらに拡大すること、特に欧州と北米ですでに強固な足場を固め、拡大することに重点を置くことに充てられる。

AikidoCEO兼CTOであるWillem Delbareが説明するように、「プラットフォームを構築しているSaaS企業は、多くの場合、散在するツールをインストールすることで、新しいソフトウェアを "セキュア "にします。これは、開発者にとって多くのノイズを発生させ、注意を払う必要はあるが本当の脅威にはならない無数の異なる『偽陽性』を投げかけることになります。このため、プラットフォームのセキュリティを管理するスタッフに大きな負担がかかる。この問題は、SaaSでは急速に成長する可能性がある成長によってさらに悪化し、セキュリティを担当するスタッフにとって大きな頭痛の種となる。

あるいは、新興企業がこれらのツールをインストールしないことを選択した場合、アプリケーション・セキュリティの一部の要素しかカバーしない高価なセキュリティ・ソフトウェア・ソリューションを採用することになるかもしれません 。その場合、企業は投資したにもかかわらず、ソフトウェアのセキュリティに大きなギャップを抱えることになります。コストがかかるため、脆弱性スキャナーはほとんどが大企業向けであり、中小企業や中堅企業は、成長するプラットフォームのセキュリティに対する実行可能なソリューションがないまま放置されている。

Aikido 、様々なアプリケーション・セキュリティ機能を統合したオールインワン・ツールにより、SaaSセキュリティを簡素化することを使命としている。バラバラのソリューションではなく、この統一されたアプローチにより、コントロールが強化され、誤検知が大幅に削減される。これまでのところ、同社は誤検知に費やされる開発者の作業日を1,500日以上削減している。Aikido 、脆弱性を重大度別にランク付けし、重要な問題が最初に対処されるようにしている。さらに、すべてのセキュリティ・データはプラットフォーム内に保存されるため、スタッフの変更に関係なく安全性が確保され、事業継続の助けとなる。

私はキャリアを通じて複数のSaaS新興企業を立ち上げましたが、新しいプラットフォームをセキュアにするために必要なツールのパッチワークをつなぎ合わせるのに何百 時間も費やしてきました。 Aikido立ち上げるにあたり、エンジニアの時間を浪費させる "非問題 "を減らしつつ、重要な違反を特定するためのより良い方法を見出しました。私たちはヨーロッパでこのようなことを行っている唯一の会社であり、ヨーロッパ大陸の新興企業に対する新たなエネルギーを示しています。私たちの顧客には現在、新興企業だけでなく、開発者が300人を超えるまでに成長した企業も含まれており、その結果、新しいSaaSソリューションの世界では珍しく、わずか1年でインストール総数が1000を超えました。今後は、ニーズに合った製品をまだ見つけていない人々に合わせたソリューションを提供することで、競合他社を圧倒していきたいと考えています。"

カミル・ミエシャコフスキノティオン・キャピタルのパートナーである カミル・ミエザコフスキは、次のように述べています。「中堅・中小企業にとって、サイバー耐性のレベルがますます高まる中、利用可能なセキュリティ・ツールは、断片化、複雑さ、コストを特徴とする課題を提示し続けています。Aikido 、コードとクラウドセキュリティのための強力かつ使いやすいエンド・ツー・エンドのソリューションを提供し、すべての開発者をセキュリティの専門家に変身させることができる単一のツールによって、あらゆる企業が自社とその顧客のセキュリティを確保できるようにします。設立からまだ1年しか経っていないにもかかわらず、同社はすでに急速に規模を拡大しており、Connect Venturesの友人や素晴らしいエンジェル投資家グループ、アドバイザーとともに、このエキサイティングな軌道を歩む同社を支援できることに興奮しています。"

ピエトロ・ベッツァコネクト・ベンチャーズの共同創業者兼マネージング・パートナーであるピエトロ・ベッツァは、次のように述べている。「この新しいB2Bソフトウェアの世界では、企業は、効率性、コストパフォーマンス、シンプルさ、集中力を兼ね備えたSaaS製品を求めています。私たちは今、グレート・バンドルの時代にいます。効率化のニーズに後押しされ、顧客はポイント・ソリューション・ソフトウェアをフルスタック・ソフトウェア・スイートに統合しています。ソフトウェア・セキュリティのオールインワン・プラットフォームであるAikido 、この新しい枠組みに非常によく適合しています。ウィレム、ローランド、フェリックスを支援し、あらゆる企業の規模や予算に最適なセキュリティ・ツールへのアクセスを民主化することに、これ以上の喜びはありません。"

Aikido 、成長中のSaaS企業が自社のプラットフォームを保護するための最速の方法を提供します。このアプリケーションは、解決すべき重要な脆弱性のすべてを瞬時に表示することで、顧客主導の迅速なオンボーディングを実現します。Aikido 、世界最高レベルのノイズリダクションにより、誤検知の数を大幅に減らすことができる。その目的は、コードにセキュリティ問題が入り込むのを防ぐことである。つまり、開発プロセスで何か問題が発生した場合、違反が発生したりコードが本番環境に到達したりする前に修正することができる。

SaaS企業向けに設計されたAikido 、SOC2、ISO 27001、CIS、HIPAA、および今後予定されている欧州のNIS 2指令など、業界の重要なコンプライアンス基準を満たすための重要なコンポーネントです。

Aikido Securityについて
Aikidoは、アプリケーション・セキュリティの複数の側面を1つの直感的なプラットフォームにまとめたオールインワン・ソリューションです。この包括的なアプローチは、エンドユーザーにより大きなコントロールを提供し、セキュリティチェック中の誤検知の数を劇的に減らします。Aikido 、Willem Delbare氏（TeamleaderとOfficientの元創設者）、Roeland Delrue氏（元Showpad）、Felix Garriau氏（元nexxworks）によって設立され、Notion Capital、Connect Ventures、Syndicate Oneによってベンチャー支援されています。

この度、Aikido セキュリティはISO27001:2022の認証を取得いたしました。これは私たちにとって大きな節目であり、情報セキュリティに対する私たちのコミットメントを証明するものです。

ISO 27001:2022とは？

ISO 27001は、情報セキュリティマネジメントシステム(ISMS)の確立と認証に関する世界的に認知された規格です。この認証の2022年バージョンは、Aikido セキュリティが情報セキュリティ管理の現在のベストプラクティスに沿ったものであることを保証します。この新しいバージョンは、安全なコーディング、脅威の検出などに重点を置いているためです。これらの項目は、ソフトウェア会社にとって重要かつ関連性が高いと私たちが考えるものです。

ISO27001:2022への準拠は、Aikido Securityにとって重要な成果です。お客様に安全で信頼性の高いソリューションを提供するという我々の献身を強調するものです。
WillemDelbare, CEO ofAikido Security.

Aikido ISO27001認証を取得しようと思ったきっかけは何ですか？

私たちはセキュリティ分野のチャレンジャーであり、新規のお客さまに最初にお願いすることのひとつは、コードベースへの読み取りアクセスを許可していただくことです。これは大変なことです。そして私たちは、それが大変なことであることを理解し、同意しています。

お客様に安心してコードベースを任せていただくためには、私たちを会社として信頼し、製品を信頼していただく必要があります。ISO27001に準拠することは、その信頼を築き、証明する上で大きな飛躍となります。

ISO27001準拠への道程で学んだこと

今後のブログ記事で、私の主な学びを紹介するつもりだが、この機会に私たちの旅についての簡単な洞察を共有したい。

ISO27001:2022への道のり

私たちは約半年ですべてのプロセスを完了しました。以前、SOC 2を実施したことがあったので、すでに多くの方針、文書、ベストプラクティスがありました。そのため、その多くを再利用し、ISOに適用することができました。

私たちは、その仕事に適したツールを使用することを固く信じているので、最新のアプローチを取る機会を得て、ISO 27001の取得に必要な作業の多くを自動化するVantaを使用しました。

ISO 27001:2022を達成するには、忍耐とコミットメントが必要です。信頼できるパートナーに囲まれ、事前に知識を収集することが不可欠です。
Aikido SecurityのCOO兼CROであるRoeland Delrue氏。

ハイレベル・プロセス

1.内部監査（事前監査）

内部監査は、「本番」の監査を行う準備が整っていることを確認するための「総リハーサル」または「模擬監査」と考えることができる。内部監査では、後の段階で是正できないような明らかなことを見逃していないことを確認する。

簡単なヒント： 優れた内部または外部の事前監査人を使うこと。これは、正しくセットアップするのに非常に役立ちます。あなたがISOに関連し、実績のある経験を持っていない限り、おそらく外部の事前監査人を雇うのが最善でしょう。彼らの経験を活用すれば、本当に価値があることがわかります。

2.ステージ1監査

ステージ1は、主に「卓上監査」または文書レビューである
この監査は、広範な文書レビューで構成される。外部のISO 27001監査人が方針と手順をレビューし、それらがISO規格の要求事項と組織独自の情報セキュリティマネジメントシステム（ISMS）を満たしていることを確認します。

3.第2段階監査

ステージ2は、多くの統制テストを伴う本格的なシステム監査です。
監査人は、情報セキュリティマネジメントシステム（ISMS）が適切に設計され、実施され、正しく機能していることを確認するためのテストを実施します。監査人はまた、組織の統制の公正さと適合性を評価し、ISO 27001規格の要求事項を満たすために統制が実施され、効果的に機能しているかどうかを判断します。

4.認証

不適合事項の是正またはアクションプランの策定が完了したら、バリデーションの準備が整います。ISO 27001の不適合は、軽微なもの、重大なもの、改善の機会（OFI）に分類されます。もちろん、改善したことを示すか、すべての重大な不適合を改善する道筋を明確に示すことが重要です。

そして...証明書を手にする時が来た🎉🥳。

ISO 27001に準拠するにはどれくらいの時間がかかりますか？

2カ月以内では無理だ。ペンテストや監査役など、すべての準備が整っていることが前提だ。

それでも、十分な情報セキュリティ・イベントが発生するようにするには、数カ月が必要かもしれない。あるイベントが発生したときにしか実施できないプロセスもあるからだ（従業員の入社や退社など）。

また、不適合を是正できることを示し、証拠を収集できることを実証しなければなりません。このプロセスには、イベントを特定し、ログに記録して分類し、情報セキュリティイベントを徹底的に文書化することが含まれます。

ISO27001に準拠するには、どれくらいの費用がかかりますか？

事前監査とペンテストの綿密さにもよるが、通常、全プロセスで2万～5万米ドルの費用がかかる。
以下の費用が必要になる：

• プレ監査役
• ペンテスト（SOC 2のためのペンテストをすでに実施している場合など、他のコンプライアンス・トラックから活用することができます。）
• コンプライアンス・プラットフォーム・ライセンス（ぜひご利用ください）
• 監査役
• 脆弱性および/またはマルウェアスキャナーライセンス（Aikido Securityなど）

費用は複数の要因に大きく左右されるが、主なものは以下の通り：

• 会社の規模（従業員、プロセス、オフィス、開発者などが多い場合、監査費用は劇的に増加します。）
• ペンテストの費用（3～3万米ドル、ペンテストの種類や実施者によって異なる）
• 監査の深さ
• コンプライアンス・プラットフォーム（Vantaなど）

ISO 27001:2022 技術的脆弱性管理

ISO27001:2022認証取得を目指す方へAikido セキュリティは、ISO27001:2022アプリケーションのためのすべての技術的な脆弱性管理のニーズを満たします。また、コンプライアンス・モニタリング・プラットフォーム（Vantaなど）と同期し、脆弱性情報が常に最新であることを保証します。つまり、正確なリスク評価と効率的な修復が可能になります。

レポートを請求する

当社のISO 27001:2022レポートをトラストセンターで直接ご請求ください。

あなたの素晴らしい新スタートアップのコードに悪質業者が潜入していることを想像して眠れなくなっていませんか？もうそんなことはありません！Aikido セキュリティは、手頃な価格で効率的な、CTOのニーズを満たすためにスタートアップのセキュリティを設計しました。Aikido StoryChiefのセキュリティ体制をどのように変えたか見てみよう。

私たちは、お客様やパートナーの経験、特に新興企業のセキュリティに関する話を聞くのが大好きです。我々は最近、StoryChiefの共同設立者兼CTOであるGregory Claeyssensと話をし、Aikido Securityを使用した彼のサクセスストーリーを聞くことに興奮しました。この顧客事例では、その会話を分解して、Aikido StoryChiefのセキュリティ態勢をどのように改善したかを紹介します。そして、その結果、グレゴリー氏のワークライフバランスが改善され、夜もぐっすり眠れるようになったことをご紹介します！(CTOの皆さん、それは素晴らしいことでしょう！）。

💡 このブログ記事の最後にある、StoryChief/Aikido カスタマーケースのダウンロードをお忘れなく。

StoryChiefとは？

2017年に設立され、ベルギーのゲントに本社を置くStoryChiefは、ユーザーフレンドリーなオールインワンのコンテンツマーケティングソリューションを提供する新興企業である。StoryChiefは、マーケティングエージェンシーやコンテンツチームがコンテンツ制作と管理を効率化できるよう支援する。あるいは、StoryChiefが言うように、「コンテンツの混沌を終わらせる」。

StoryChiefのコラボレーティブで直感的なプラットフォームには、コンテンツ計画、配信、スケジュール管理、AIライティングツールが含まれています。大きな注目を集めている。特に、StoryChiefは570万ドルの資金を調達している。これは、包括的なコンテンツ・マーケティング・ソリューションを提供する革新的なアプローチの証だ。現在、StoryChiefには大規模な専属開発チームがある。そして、魅力的なことに、彼らのロゴは好感の持てるナマケモノだ！

💡 StoryChiefとそのサービスについての詳細は、ウェブサイトhttps://www.storychief.io。

スタートアップ・セキュリティの課題

StoryChiefが成長するにつれ、コードベース、リポジトリ、インフラのセキュリティ管理はますます複雑になっていきました。グレゴリーと彼のチームは、潜在的なセキュリティの脆弱性に先手を打つという困難な立場に立たされていることに気づいた。

セキュリティの遅れ： セキュリティ態勢の管理がますます心配になった。グレゴリーは、何か重要なことを見逃しているのではないか、見落としているのではないかと心配した。それが不必要なストレスや懸念につながった。

不完全で高価なセキュリティツールの使用：StoryChiefは、ある程度の安心感を与えるセキュリティ・ツールを使用していた。しかし、これには主に2つの障害があった。それらはGregory氏のセキュリティ要件一式を満たしておらず、CTOのニーズをターゲットにしていなかった。さらに、主要なセキュリティ・ツール・プロバイダが予期せぬ価格変更を行ったこともあった。

通知過多： 通知は有用かつ適切であるべきだ。しかし、複数のセキュリティツールを使用することは、通知の過多を招いた。その結果、3つのことが起こった：

1. いくつかの通知は、文脈情報と正確さに欠けていた、
2. 圧倒的な数の通知はホワイトノイズとなり、したがって無視できる（単に価値がない）。

一言で言えば、非効率が貴重なリソースと時間を浪費していたのだ。しかし、このような逆風にもかかわらず、グレゴリーはセキュリティを効果的に管理し、大きなセキュリティ・インシデントを経験することはなかった。しかし、彼は既存のツールの限界とコストに不安を感じていた。その結果、彼はより良い解決策を探すようになった。

Aikido セキュリティがStoryChiefのセキュリティ態勢をどのように改善したか

StoryChiefは、より良いセキュリティ態勢への旅路の中で、Aikido Securityに辿り着きました。

嫌な価格設定はありません： スタートアップのセキュリティは手頃であるべきで、Aikido スタートアップに優しい価格設定をしている。そのため、StoryChiefは費用対効果の高いソリューションを提供することができた。同時に、Aikido 次の2つの利点により、自社のセキュリティ体制に対する自信を高めた。

私はCTOであり、セキュリティ・エンジニアではない： StoryChiefがこれまで使用してきた様々なツールは、主にセキュリティ・エンジニアを対象としていました。しかし、それらのツールとは異なり、Aikido CTOや開発者の特定のニーズに合わせて機能やルールを調整している。Aikido また、CTOを支援するために特別に設計された新しいルールや機能を継続的に提供している。

重要で適切なときに教えてください： Aikido主な強みでありUSPの1つは、誤検知を減らすことです。Aikidoターゲット化されたアラートは、StoryChiefに圧倒的で無視しやすい通知ではなく、現実的で実用的な洞察を提供します。

オーナーシップの共有： それだけでなく、Aikido通知はSlackを通じて開発チームと自動的に共有され、セキュリティの透明性と責任の共有が促進される。このように、Aikido チームワークの成果ももたらした。セキュリティ態勢を管理するために、よりチームに焦点を当てた取り組みを行うというGregory氏の目標に貢献した。

Story最高技術責任者（CTO）が語るAikidoインパクト

Aikido まさに私が長い間探していたものでした-機能のコンボ、スタートアップに特化していること、そしてエントリー価格です。Aikidoおかげで、チームはセキュリティ問題を意識するようになりました。Aikidoのおかげで、チームはセキュリティの問題を意識するようになりました。

Aikido 起業保障保険

Aikido セキュリティは、StoryChiefのセキュリティ保険のようなものです。合気道は予算と精度を提供します。Aikido また、グレゴリーと彼のチームにとって本当に重要なことに明確に焦点を当てることができます。Aikido導入により、StoryChief はセキュリティ態勢を改善しただけでなく、CTO のチームがオーナーシップを持ち、透明性のある仕事ができるようになりました。Aikido は、セキュリティ上の懸念に対処するために必要な情報の整理統合と優先順位付けを行っています。

最も重要なことは、グレゴリーに製品の安全性に対する高い信頼感を与えてくれたことだ：

「しかしAikido 、少なくとも私は知っている！合気道では、少なくとも私は知っています。

StoryChiefの導入事例をダウンロード

StoryChief XAikido Securityの導入事例をダウンロードできます：

CVE」とは、Common Vulnerabilities and Exposures（共通脆弱性・暴露）の略で、聞いたことがある人も多いだろう。CVEは、既知のコンピュータ・セキュリティ問題を追跡する巨大なデータベースにリストアップされます。これにより、簡単にアクセスして参照することができます。ですから、もし誰かがCVEについて、あるいはCVEレコードについて話しているのを耳にしたら、それはセキュリティ上の欠陥が知られていて、すでにカタログ化されていることを意味します。

既知のセキュリティ欠陥を共有し、カタログ化することで、サイバーセキュリティ担当者は脆弱性に優先順位をつけて対処し、クラウドやコード、その他のITシステムをより安全にすることができる。

基本的に、CVEシステムは共通の言語と参照ポイントを提供する。しかし--これが大きな「しかし」だが--私の問題があなたの問題ではないかもしれないことを心に留めておいてほしい！

CVEデータベースは誰が管理しているのですか？

CVEシステムを統括しているのはMITRE社で、CVEの記録はすべて一般市民が無料で検索・利用できる。サイバーセキュリティ・インフラストラクチャ安全保障局（CISA）は資金提供に協力している。CVEエントリーは簡潔で、深い技術的データはありません。CVEエントリーには、修正、リスク、影響についてのコメントもない。詳細については、他のデータベースに記録されている。その例としては、米国国家脆弱性データベース（NVD）やCERT/CC脆弱性ノート・データベースなどがある。

CVE IDとはどのようなものですか？

CVE IDはシリアル番号のようなものだ。CVEエントリーを見ると、次のようなCVE IDが表示される："cve-yyyy-###"となります。

CVE記録には何が含まれるのか？

CVEレコードには以下の情報が含まれる：

• CVE ID
• 説明
• 参考文献
• CNAの配置
• レコード作成日

CVE記録には、フェーズ、投票、コメント、提案など、新規エントリーには関係のないレガシーなものも含まれている。

どのようにして脆弱性や暴露を見つけるのか？

技術系企業から好奇心旺盛なユーザーまで、誰でも報告することができる。中には、これらの問題を発見し報告することで、報酬を提供するものさえある。オープンソースのソフトウェアであれば、コミュニティのサポートがすべてだ。

脆弱性が報告されると、CNAはその脆弱性にCVE IDを与え、簡単な説明を書き、参考文献を追加する。その後、CVEウェブサイトに掲載される。問題が公表される前にIDを取得することもある。悪者を寄せ付けない。

さて、すべての問題にCVEがつくわけではない。もちろん、ルールはある！主に3つの基準が適用される：

1. 独立して修正可能。これは、その欠陥が修正可能で、独立しており、他のバグとは無関係であることを意味する。
2. ベンダーが認めている。 これは、そのバグが存在し、セキュリティに悪影響を及ぼす可能性があることを、 ベンダーが認めていることを意味します。もう一つの選択肢は、バグの悪影響と、それがシステムのセキュリティポリシにどのように違反するかについての説明を含む、共有された脆弱性報告書を持つことです。
3. 一つのコードベースだけに影響する。 複数の製品に影響する場合は、別々のCVEを取得する。できるだけ分離してCVEレコードを作成することです。

CVEレコードはどのように見つけることができますか？

まず第一に、CVE情報は無料で公開されている。これは良いニュースだ。

最新の CVEを見つける最も簡単な方法は、Xで@CVEnewをフォローすることだ。このフィードは、毎日複数の新しいCVEに関するツイートで常に更新されている。昨日見ただけでも80以上の新しいCVEがあった！フォローすれば、フィードはそれらでいっぱいになるだろう！

過去のCVE記録をより詳細に検索する方法はどうでしょうか？1999年以降のすべての記録や特定の年の記録が欲しい場合、あるいはトピック別に検索したい場合は、CVE.org/Downloadsにアクセスすればよい。一括ファイルはJSON 5.0形式になり、GitHubリポジトリからダウンロードできるようになりました。(注：以前のファイリングシステムは2024年1月1日に利用できなくなります)

CVEdetails.comには、毎日更新されるデータベースの使いやすいオンライン版が ある！

ライブラリーを適切なCVEにマッチさせるには？

脆弱性を分析する際には、正しいCVEを取得したい。正しいCVEを持っていることを確認するには、バージョン番号とパッケージ名をチェックするのがベスト・プラクティスだ。Trivyのように、これを自動的にやってくれるツールはたくさんある。Aikido この機能の一部にTrivyを活用している）。

共通脆弱性評価システム - CVSS

NVD などは Common Vulnerability Scoring System（CVSS）を使って、脆弱性や暴露の深刻度を判定している。これはセキュリティ問題の成績表のようなもので、0.0（大したことない）から10.0（大問題）まであります。つまり、各CVEエントリにはCVSSスコアがあります。

CVSSスコアはどのように計算されるのか？

CVSSスコアは、脆弱性ベースのメトリクスに基づく計算式で算出される。CVSSスコアは、以下の3つの分野のスコアから構成される：Base、Temporal、Environmental。ベース・スコアは必須であり、出発点であり、影響度と悪用可能性のサブスコアを持っています。次に、Temporal スコアが Base から計算されます。次に、Temporal スコアから Environmental スコアを計算することができる。これらの計算が総合的な CVSS スコアにつながる。

数式マニアのための何か！スコアリングシステムとCVSS計算機がどのように機能するかをチェックしてください。どのような計算が行われ、どのような正確なメトリクスが各スコアを生み出しているのかをご確認ください。攻撃ベクトル複雑さをアタッチする！盛りだくさんの内容です！

CVSSスコアリングスケールとは何ですか？

現行（v3.1）のCVSSスコアリング・スケールには5つのカテゴリーがある：

• 9.0～10.0＝クリティカル
• 7.0～8.9=高
• 4.0 - 6.9 = 中程度
• 0.1 - 3.9 = 低
• 0.0 = なし

CVSSスコアリングシステム・ユーザーズガイドをダウンロードしてください。

CVEレコードのCVSSスコアを調べるには？

これは簡単です！オンラインデータベースの各CVEレコードページには、NVDのCVSSスコアへのリンクがあります。クリックするだけです！例えば、この投稿の前に出てきたCVE-2023-40033を使って、「CVSSスコア」（レコードの右上隅）をクリックすると、この脆弱性のスコアが7.1（高）であることがわかります。

CWEとは？

CWE（Common Weakness Enumeration）は、一般的なソフトウェアとハードウェアの弱点のリストである。CWEはコミュニティによって開発されたリソースであり、弱点の種類と範囲の標準化を提供する。

MITREの言葉を引用すると、「CWEの主な目標は、脆弱性をソースで止めることです...製品が提供される前に最も一般的な間違いを排除することです」。CWEはまた、脆弱性データベース（CVEなど）にマッピングしながら、セキュリティの脅威に対する議論と対策のフレームワークを開発者に提供します。

CVEとの違いは？CWEは脆弱性につながる可能性のある根本的な弱点に焦点を当てています。一方、CVEは実際の脆弱性を記述します。CVEと同様、CWEにもCWSSと CWRAFによる深刻度スコアリングがあります。

2023年、最も危険なCWEトップ25をご覧ください。

強固なセキュリティ態勢を維持するためにはどうすればいいのか？

セキュリティの優先順位を決めるのに、やみくもにCVSSスコアに従わないこと

すべてのCVEが問題なのか？いいえ。これらは情報ですが、多くの情報と同じように、すべてのCVEがあなたのコンテキストに関連するとは限りません。また、関連性があるように見えるものでも、CVSSスコアが高いCVEであっても、あなたにとって関連性がなかったり、リスクにならなかったりする状況はたくさんあります：

1. ビジネスへの影響度：脆弱性は、CVSSスコアが高いにもかかわらず、組織の特定の業務、顧客データ、または重要なシステムに重大なリスクをもたらさない。あるいは、リスクアセスメントやその他のツールにより、他の要因（例えば、ある機能が到達できないなど）がCVSSスコアを上回る重要性を持つと判断される。
2. 独自のシステム：カスタムまたは独自のソフトウェアを使用する場合、CVSSスコアは、特定のシステムの脆弱性に関連する実際のリスクを正確に反映しない可能性がある。
3. リソースの限界：高スコアのCVSS脆弱性をすべて修正したいところだが、現実的でなければならない。費用対効果の低いものに大量のリソースを注ぎ込む前に、優先順位をつけよう。
4. すでにカバー：すでに強固な防御策を講じているかもしれない。たとえ脆弱性のスコアが高くても、それを抑える安全策がすでにあれば、大騒ぎするほどのことではないと判断するかもしれない。
5. CWEへの認識： 配信内容に影響を与える可能性のあるCWEを常に意識すること。

脆弱性スキャナーを入手する

また、新たなトレンドを発見するのに役立つ新しいプラットフォームも登場している。認識スピードと脅威のコンテキスト化に特化したFletchをチェックしてみよう。Nessusは59,000以上のCVEをスキャンします。Nexposeは独自のスコアリング・システムを使用しており、脆弱性の年代や、すでに適用されているパッチや対処法を考慮に入れている。Nmapと OpenVASはオープンソースの脆弱性スキャナーだ。

一方、Aikido Securityをテストして、全体的なセキュリティ態勢を監視し、改善してみてはいかがでしょうか？ Aikido無料でお試しください！

CurVEを先取りする

CVEについて言えることは、CVEは過去、つまりすでに起こった脆弱性や暴露について書かれているということだ。つまり、悪質な行為者は、あなたが対応する前に損害を与える時間を持つことがあるということです。脆弱性スキャナーを使うだけでなく、リスクを管理するための手段を講じるようにしてください。これには、パッチが最新であることを確認したり、侵入テストを実施したりすることが含まれる。

TL;DR secでは、ソフトウェアのサプライチェーンと、さらに重要なこととして、各段階でのセキュリティ確保方法について詳しく説明している。

さらに、私たちは、Aikido ユーザー（無料および有料）とLinkedInのフォロワーに、関連するLIの投稿でループを維持したいと考えています。例えば、CVE-2023-4911（Looney Tunablesの（あまり笑えない）バグ）に関する最近の投稿です。

最も一般的なエクスプロイトについてコードをチェックする

OWASP トップ 10とCIS コンプライアンス・ベンチマークを使用して、コードをチェックしてください。これらの標準的なツールは、最も一般的な弱点（OWASP）とサイバーセキュリティの基本設定（CIS）に対処するのに役立ちます。

Aikido直接得点する方法をチェック：CISレポート/OWASPトップ10レポート

サイバー脅威が高度化する中、企業は今日、古くなったソフトウェアやハードウェアから生じるリスクに対処するという喫緊の課題に直面している。使用済み（EOL）システムを発見し、対処することは、セキュリティを維持する上でますます重要になっている。

製造中止の検出は、ベンダーがサポートしなくなったソフトウェアやハードウェアを特定し、セキュリティ脆弱性の影響を受けやすくします。これらの古くなったコンポーネントを無視すると、深刻なセキュリティ侵害、コンプライアンスの問題、運用の中断につながる可能性があります。

幸いなことに、現在では先進的なツールがEOL検出を効率化し、組織が強固なセキュリティを維持するのに役立っている。2025年に向けて、EOL管理の複雑さを解決してくれるEOL検出ツールのトップを探ってみよう。

終末期（EOL）検出を理解する

製造中止の検出は、ベンダーがサポートしなくなったソフトウェアやハードウェアを特定することに重点を置いている。ベンダーのアップデートがなければ、これらのシステムは新たなセキュリティ脅威や非互換性に対して脆弱になる。

ITインフラのセキュリティとコンプライアンスを維持するには、効果的な製造中止の検知が必要です。古くなったコンポーネントは、既知の脆弱性に対処するアップデートの欠落により、重大なセキュリティ・リスクとなる可能性があります。攻撃者はしばしばこうしたシステムを標的にし、欠陥を悪用して不正アクセスを行ったり、業務を妨害したりします。

さらに、多くの規制が最新のシステムを要求しているため、サポートされていないソフトウェアやハードウェアを使用することは、コンプライアンス違反につながる可能性がある。製造中止のコンポーネントを無視すれば、罰金や風評被害、信頼の失墜につながりかねない。

効果的なEOL検出には以下が含まれる：

• 包括的な資産の発見：オンプレミス、クラウド、エンドポイントデバイスを含む、組織全体のすべてのソフトウェアとハードウェアを特定します。
• 継続的なモニタリング：サポート終了日はベンダーや製品によって異なるため、古いコンポーネントやサポートされていないコンポーネントがないか定期的にスキャンする。
• リスク評価：重要度やデータの機密性などの要素を考慮し、EOL コンポーネントがセキュリティに与える影響を評価する。
• 修復計画EOLシステムの移行、アップグレード、廃止の戦略を策定し、リスクとビジネスニーズに基づいて優先順位をつける。

しっかりとした製造中止検知戦略を導入することで、組織は古くなったコンポーネントによるリスクを管理し、セキュリティを強化し、コンプライアンスを確保することができます。Aikido Securityのようなツールは、自動EOL検出を提供し、既存のセキュリティ・システムと統合して継続的な保護を提供します。

2025年、トップ・オブ・ライフ検出ツール

適切なライフサイクル終了検出ツールを選択するには、堅牢な資産管理とソフトウェア・ライフサイクルのステータスに関する洞察を提供するソリューションを特定する必要があります。以下のツールは、旧式のテクノロジーによるリスクを最小限に抑えながら、プロセスを合理化します。

1.Aikido セキュリティ

Aikido Securityは、開発パイプラインとシームレスに統合し、コードとコンテナの正確なスキャンを提供することで、寿命が近い、または寿命に達したコンポーネントを特定します。クラウドネイティブ環境向けに設計され、混乱を最小限に抑え、ライフサイクルの重要な洞察を提供します。

2.Tenable.io

Tenable.ioは、包括的な資産監視を提供し、ITインフラストラクチャに古いソフトウェアがないか継続的にチェックします。ソフトウェアのライフサイクルを一元的に把握できるため、サポート対象外の資産を事前に管理することができます。このツールは、広範なオンプレミスおよびクラウド環境を持つ組織に効果的です。

3.ニンジャワンRMM

NinjaOne RMMは、使用済みOSやサードパーティ製アプリケーションの検出を自動化します。そのプラットフォームはIT資産管理を一元化し、古くなったコンポーネントの特定と対処の効率を向上させます。直感的なレポート機能により、ライフサイクル管理を簡素化します。

4.クオリス

Qualysは、サポート対象外のシステムやアプリケーションを特定するためのクラウドベースのアプローチを提供します。そのスキャン機能により、包括的なカバレッジを確保し、改善のための実用的な洞察を提供します。既存のセキュリティフレームワークにスムーズに統合し、ライフサイクル管理を強化します。

オープンソースのEOL検出ツール

OpenVASのようなオープンソースのソリューションは、ソフトウェアのライフサイクルに関する貴重な洞察を提供し、さまざまなシステムでサポートされていないコンポーネントを特定します。その適応性は、ユニークなニーズを持つ組織にとって貴重な資産となる。

endoflife.dateは、様々なソフトウェア製品のEOLの日付とサポートライフサイクルをコンパイルし、簡単に統合できるAPIを備え、ライフサイクル情報へのタイムリーなアクセスを保証します。

これらのツールを活用することで、企業はエンド・オブ・ライフの検出を正確に管理できるようになります。適切なツールを選択することで、セキュリティを強化し、コンプライアンスを維持し、お客様の環境を時代遅れの技術リスクから守ります。

正しいEOL検出ツールの選び方

適切な終息検知ツールを選ぶには、組織のニーズとインフラを理解する必要があります。ネットワークの規模と複雑さを考慮してください。大規模なシステムでは、複雑な資産追跡のための包括的なソリューションが必要かもしれませんが、小規模なネットワークでは、的を絞った精度の高い合理的なツールが有効かもしれません。

既存のセキュリティシステムやIT管理システムと統合し、スムーズな情報の流れを確保し、現在のセキュリティ対策を強化するツールを優先する。柔軟なAPI構成をサポートするツールは、運用要件に合わせたソリューションを可能にする。

自動化は極めて重要である。サポートされていないコンポーネントの検出を自動化し、迅速な修復を可能にするツールは、運用効率を高め、手作業による介入を減らして、セキュリティチームが戦略的イニシアティブに集中できるようにする。

EOL検出ツールを評価するための主な要因

ツールを評価する際には、包括的なカバレッジと効果的な管理のために、これらの側面を考慮する：

• 全体的な資産の可視化：オンプレミス、クラウド、エンドポイントシステムなど、さまざまなプラットフォームを監視するツールを選択し、すべてのコンポーネントがライフサイクル管理に含まれるようにする。
• 識別の精度：製造中止となったシステムやソフトウェアを正確に識別し、誤検知を減らし、真の脆弱性に焦点を当てるソリューションを選択する。
• 包括的なリスク分析：サポートされていないコンポーネントと関連するリスクに関する詳細な洞察を提供するツールを選択し、脆弱性の効率的な優先順位付けを促進する。

これらの基準を重視することで、当面のニーズを満たし、将来の成長にも適応できるソリューションを選択することができ、テクノロジーの進化に伴い、持続的なセキュリティとコンプライアンスを確保することができる。

効果的なEOL検出戦略の実施

健全なEOL検出戦略の策定は、ITインフラを保護するための鍵である。すべてのテクノロジー資産の詳細なカタログを作成し、定期的に更新して、ライフサイクルの課題を効果的に管理することから始めましょう。

サポートされていないコンポーネントを特定するために、技術的な状況を常に評価する。包括的なカバレッジを確保するために、自動化された評価のスケジュールを組み、タイムリーな介入を行うために、現在サポートされている要素と、近々サポートされなくなる要素の両方を特定することに重点を置く。

EOLリスク管理のベストプラクティス

EOLリスクを管理するには、アップグレードやリプレースのためのタイムラインやリソースを考慮した、旧式システムからの移行に関する詳細な計画が必要である。

サポート対象外であるにもかかわらず稼動し続けなければならないシステムについては、恒久的な解決策が実行可能になるまで、アクセス制限や一時的なセキュリティ強化の適用といった暫定的な手段によってセキュリティを強化する。

EOL 管理の成功は、IT チームとセキュリティ・チームの連携にもかかっている。各システムの脆弱性と重要性に基づいてリスクを評価し、対処するための努力を調整し、タイムリーで効果的な是正を確保する。

終末期医療の未来

寿命末期検知の未来は、人工知能と予測アルゴリズムの影響を大きく受けるだろう。これらのテクノロジーは、陳腐化間近の部品の事前特定を強化し、組織がそれに応じて準備できるような洞察を提供する。AIは潜在的なライフサイクルリスクを示す傾向を予測することができ、従来の方法よりも優位に立つことができる。

デジタル・インフラが複雑化するにつれて、自動修復が極めて重要になる。これは、製造中止となったコンポーネントの特定を合理化し、シームレスな更新や交換を可能にすることで、ITチームが広大なネットワークを効率的に管理できるようにする。

クラウド・ネイティブな方法論は、EOL検出を最新のITスタックに適応させ、ライフサイクル管理にクラウドのスケーラビリティと適応性を活用する。組織がクラウド技術をますます使用するようになるにつれ、EOL検出をこれらの環境に統合することが重要な利点となる。

終末期医療の新たな動向

開発の早い段階でEOL評価を組み込むことが標準になりつつあり、ライフサイクル評価をDevOpsやCI/CDプロセスに組み込み、ソフトウェア作成中のリスクに対処する。リアルタイムのリスク評価も不可欠になりつつあり、高度なモニタリングを使ってIT資産を継続的に把握し、ライフサイクルの問題に迅速に対処する。

エンド・オブ・ライフの検出と包括的なリスク管理を組み合わせた統合プラットフォームが人気を集めている。これらのソリューションは、ライフサイクル管理とリスク軽減を組み合わせることでプロセスを合理化し、セキュリティを強化する。

EOL検出の課題を克服する

シャドーITやレガシーシステムが監視されずに運用され、セキュリティギャップを生み出しているため、組織はしばしば使用済み検知の管理に苦労している。明確な可視性がなければ、隠れたコンポーネントが検出を回避し、脆弱性の露出を増加させる可能性があります。

現代のIT環境の動的な性質は、EOLリスクの優先順位付けを複雑にしている。大企業は、絶えず変化する資産目録を管理しなければならず、重要な脆弱性に焦点を当てることが難しくなる。リスクに効果的に優先順位をつけるには、戦略的なフレームワークが必要である。

リソースの制約は、EOL 検出と他のセキュリティ・タスクとのバランスをさらに複雑にする。セキュリティチームは、しばしば手薄になるため、他の優先事項とともに EOL 検出を管理しなければならず、効率的なリソース配分が必要になる。

規模に応じた効果的なEOL検出のための戦略

このような課題に対処するために、組織はEOL検出の効率を向上させる戦略を用いることができる。自動化によってスキャンとレポートが効率化され、セキュリティ担当者は戦略的なタスクに集中できるようになり、徹底した監視が可能になります。

EOLの洞察を既存のITサービス管理とチケッティングのフレームワークに組み込むことで、一貫したライフサイクル管理アプローチが構築され、リスクへのタイムリーな対応とアカウンタビリティの強化が促進されます。

マネージド・セキュリティ・サービス・プロバイダを活用することで、複雑なライフサイクルの問題に対するカスタムソリューションのための専門的な専門知識とリソースを提供し、EOLリスク管理を強化することができる。外部の専門知識を活用することで、社内の能力が強化され、包括的なライフサイクル終了時検出戦略が保証される。

テクノロジーが進化し続ける中、効果的な使用済み製品の検出は、依然として重要なセキュリティ・コンポーネントです。適切なツールとベストプラクティスを使用することで、組織は複雑なEOLを管理し、ITインフラのセキュリティとコンプライアンスを確保することができます。今すぐAikido無料トライアルでセキュリティを簡素化し、EOL検出を合理化し、優れたソフトウェアの構築に集中しましょう。

私たちは、Aikido ユーザが直面する、重大なウェブアプリケーションのセキュリティ脆弱性のトップ 3 を特定しました。このガイドでは、これらの脆弱性が何であるか、なぜ一般的であるか、そしてどのように修正するかについて概説します。

早期に効果的に対処することで、ウェブアプリケーションをサイバー犯罪に対して安全に保つための戦いにおいて、すでに先手を打つことができるだろう。

1.最も一般的で重大なコードの脆弱性（SAST）

静的アプリケーション・セキュリティテスト（SAST）は、開発サイクルの早い段階で、ソースコードに脆弱性がない かスキャンするテスト手法です。アプリケーションの動作がテスト者に知られているため、ホワイトボックス手法と呼ばれています。

NoSQLインジェクション攻撃（コードの脆弱性：SAST）

NoSQL インジェクションは、データの漏えい、データベースの破損、さらにはシステムの完全な侵害につながる可能性があります。悲しいことに、これは重大なウェブ・アプリケーション・セキュリティの脆弱性であり、私たちは多くのAikido ユーザー・アカウントがこの脆弱性にさらされているのを見てきました。

NoSQLインジェクションとは？

NoSQLインジェクションは、ハッカーが悪意のあるコードを使用してNoSQLデータベースを操作したり、不正にアクセスしたりする攻撃の一種です。SQLデータベースを標的とするSQLインジェクションとは異なり、NoSQLインジェクションはMongoDBのようなNoSQLデータベースの脆弱性を悪用します。データ漏洩、破損、あるいはデータベースの完全な制御を引き起こす可能性がある。

なぜこのような脆弱性が多発するのか？

NoSQLデータベース、特にMongoDBの人気が高まっていることもあり、NoSQLインジェクションが一般的になっている。これらのデータベースはパフォーマンス上の利点がありますが、セキュリティ上のユニークな課題があります。

その上、NoSQLデータベースはXMLやJSONのような様々なフォーマットを受け入れるという点で柔軟性がある。この柔軟性は素晴らしいものですが、標準的なセキュリティチェックではこれらの形式に合わせた悪意のある入力を検出できない可能性があるため、ウェブアプリケーションのセキュリティ脆弱性につながる可能性があります。

また、膨大な数のNoSQLデータベースがあり、それぞれが独自の構文と構造を持つため、普遍的な安全策を作ることも難しくなっている。セキュリティ専門家は、各データベースの具体的な詳細を理解する必要があり、それが防止プロセスに複雑さを加えている。

さらに悪いことに、従来のSQLインジェクションとは異なり、NoSQLインジェクションはアプリケーションのさまざまな部分で発生する可能性があります。そのため、検出はさらに難しくなります。

どうすればこの脆弱性を簡単に修正できるのか？

入力検証とパラメータ化されたクエリを使用する。入力バリデーションは、ユーザの入力が期待される型やフォーマットと一致することを保証し、安全でない値を拒否します。パラメータ化されたクエリは、検証されていない入力の埋め込みを防ぎます。

一般的に、認証や暗号化などのデータベース・セキュリティ機能を常に実装すること。常に最新のパッチを適用すること。そして、コードや設定の定期的な監査を実施し、この脆弱性やその他の脆弱性を特定して修正するようにしてください。

次点コード内に危険なデバッグ関数を残す（コードの脆弱性：SAST）

公開されたデバッグ関数は、攻撃者がシステムを悪用するための偵察を可能にする。

危険なデバッグ関数とは？

phpinfo() のようなデバッグ関数は、サーバーや環境に関する機密情報を公開する可能性があります。これには、PHP のバージョンや OS の詳細、サーバーの情報、 そして秘密鍵を含む環境変数までが含まれます (そもそも、秘密鍵をそこに置くことはお勧めしませんが!)。

その結果、これらのデバッグ関数を使用してファイルシステムの構造を検出すると、 サイトが脆弱な場合にハッカーがディレクトリトラバーサル攻撃を行う可能性があります。phpinfo() を単独で公開することは、必ずしもリスクが高いわけではありませんが、 攻撃者にとっては若干容易になります。原則は明確で、ハッカーがあなたのシステムに関する具体的な情報を持っていないほうがよいということです。

なぜこのような脆弱性が多発するのか？

このウェブ・アプリケーション・セキュリティの脆弱性は、開発者がこれらの関数をデバッグのために使い、時には、トラブル シューティングのために、本番環境にも適用してしまうために、しばしば発生します。急ぎのリリース、コードレビューの不足、リスクの過小評価、これらすべてが、これらの関数を露出したままにする一因です。

どうすればこの脆弱性を簡単に修正できるのか？

• コードレビュー：本番環境にデプロイする前に、定期的にコードをチェックし、デバッグ関数を特定して削除する。
• 自動脆弱性スキャンツール：危険なデバッグ関数を検出できるAikidoようなツールを使う。
• 環境固有の設定：本番環境ではデバッグ機能を無効にしてください。

2.最も一般的で重要な DAST の脆弱性

動的アプリケーション・セキュリティテスト（DAST）は、実行中のアプリケーションの脆弱性を特定するテスト技 術です。観察可能な動作だけに焦点を当てるので、ブラックボックス手法と呼ばれます。DAST は、攻撃者にとって、システムがどのように見えるかを示します。

主要なセキュリティヘッダを忘れる：HSTSとCSP（クラウドの脆弱性：DAST）

HSTSとCSPが適切に実装されていないため、ウェブアプリケーションはXSSや情報漏えいといった主要な攻撃に対して脆弱なままとなる。

CSPとは？

コンテンツ・セキュリティ・ポリシー（CSP）は、クロスサイト・スクリプティングやクリックジャッキングのような、様々なブラウザベースの攻撃を打ち負かすのに役立つセキュリティ・メカニズムである。インラインJavaScriptや安全でないeval()関数など、ウェブページにおける危険な動作を制限することでこれを実現します。CSPは、コンテンツの完全性と機密性を維持するために、より安全なデフォルトを強制します。主な利点は、スクリプトの悪意のあるインジェクションから保護することです。

このDASTの脆弱性はなぜ一般的なのか？

HSTSとCSP、特にCSPを軽視することはよくあることで、開発者はこれらのヘッダーよりも機能を優先することが多い。

CSPは開発の早い段階で計画すべきだが、見過ごされることが多い。そして、開発者が後からCSPを実装したり、後付けしようとすると、コンフリクトを引き起こすため、CSPを完全にスキップして他の作業に取り掛かる。このため、アプリは無防備なまま放置され、さまざまなウェブ・アプリケーション・セキュリティの脆弱性にさらされることになる。

DASTの脆弱性を簡単に修正するには？

• HSTSを導入してHTTPSのみの接続を強制する。設定ファイルまたはWAFを使用してサーバー上で有効にする。
• インライン・スクリプトのような安全でないプラクティスを制限することで、アプリに合わせた厳格なCSPを定義し、適用する。互換性を慎重にテストする。
• アプリの進化に合わせてヘッダーを継続的に監視・更新し、保護を維持する。

3.最も一般的で重要なクラウドの脆弱性（CSPM）

クラウド・セキュリティ・ポスチャ管理（CSPM）ツールは、クラウド・ベースの環境を継続的に監視し、セキュリティ標準とベスト・プラクティスへの準拠を保証する。CSPMツールは、セキュリティの設定ミスを探し、リスクを軽減することを目的としている。

EC2のIAMロールがSSRF攻撃に脆弱なままになっている（クラウド：CSPM）

オープンなEC2のIAMロールは、攻撃者がクラウド環境を横方向に移動し、不正にアクセスすることを頻繁に可能にする。この種の攻撃の潜在的な影響は壊滅的なものになる可能性がある。

EC2 IAMロールとは？

Amazon Web Services（AWS）のEC2 IAM（Identity and Access Management）ロールは、特定のリソースに対して許可されるアクションを決定する権限を委譲する。これにより、EC2インスタンスは、インスタンス自体に認証情報を直接保存することなく、他のAWSサービスと安全にやり取りできるようになる。

SSRF攻撃とは？

サーバー・サイド・リクエスト・フォージェリ（SSRF）攻撃とは、攻撃者がサーバーに、あたかもサーバー自身が要求しているかのように、内部リソースへのリクエストを行わせるものです。攻撃者は、この方法で権限のないシステムにアクセスしたり、制御をバイパスしたり、コマンドを実行したりする可能性があります。単純なメール送信フォームからSSRF攻撃がスタートアップのクラウドを乗っ取った恐ろしい例をご覧ください。

なぜこのCSPMの脆弱性が一般的なのか？

EC2 IAMロールは通常、セキュリティの設定ミスや過度に寛容なロールのために、SSRF攻撃に対して脆弱なままになっている。複雑なクラウドのパーミッションを調整するのは難しく、開発者の中にはリスクを十分に理解していない人もいるだろう。その上、サービスを円滑に連携させたいがために、本当に必要なアクセス権よりも多くのアクセス権を付与してしまうこともある。

どうすればこのCSPMの脆弱性を簡単に修正できるのか？

EC2のロールに取り組み、SSRFのウェブ・アプリケーション・セキュリティの脆弱性を軽減するための確実な方法がいくつかある。まず第一に、最小特権の原則に忠実であること - 絶対に必要なアクセスだけを許可し、それ以上は許可しないこと。過度に寛容なロールはトラブルの元だ。

次に、セキュリティグループやネットワークACLのようなAWSのビルトインツールを利用して、トラフィックをロックダウンし、SSRF攻撃の潜在的な隙を減らす。アクセスを制限できればできるほど良い。

また、定期的にロールを見直し、監査することで、時間の経過とともに変化する不要なアクセスを発見することも重要です。常に把握しておくこと。

そして最後に、SSRF 攻撃が被害をもたらす前に検知し防止することに特化した AWS セキュリティツールを導入する。保護のレイヤーが多ければ多いほど、安全性は高まります。

次点：時代遅れのクラウド・ラムダ・ランタイム（クラウド：CSPM）

これらの実行環境が古くなると、ラムダ関数が攻撃者にさらされる可能性がある。

時代遅れのラムダ・ランタイムとは？

時代遅れのラムダ・ランタイムとは、サーバーレス関数（ラムダ）で古いバージョンのプログラミング言語や環境を使用することを指す。これらの古いランタイムは、最新のセキュリティパッチや機能アップデートが適用されていない可能性があり、アプリケーションを既知のWebアプリケーションセキュリティの脆弱性にさらす可能性があります。

なぜこのCSPMの脆弱性が一般的なのか？

この脆弱性は、しばしば「セット・アンド・フェザー（セットして忘れる）」という考え方から生じる。開発者は、特定のランタイムでラムダをデプロイし、新しいバージョンがリリースされたときにそれらをアップデートすることを怠るかもしれない。また、クラウド・プロバイダーがすべてのメンテナンスを行ってくれると思い込んでしまうこともある。AWSやGoogle Cloud Functionsは、OSのマイナーパッチでランタイムをメンテナンスしてくれるが、主要な言語のアップグレードはしてくれない。その上、複数のラムダを管理する複雑さから、古くなったランタイムが抜け落ちやすくなり、余計なリスクが発生する。

どうすればこのCSPMの脆弱性を簡単に修正できるのか？

3つのシンプルなルールに従うことで、リスクを軽減することができる：

• 使用されているランタイムを定期的に確認し、アップデートがないかチェックする。
• セキュリティパッチが適用された最新のサポートバージョンにアップグレードする。
• 可能であれば、自動化ツールを使用してランタイムを管理・更新する。

Webアプリケーション・セキュリティの脆弱性とベストプラクティス

これらのウェブ・アプリケーション・セキュリティの脆弱性を理解することは、システム・セキュリティのために不可欠ですが、ベスト・セキュリティ・プラクティスに従うことを忘れないでください。最新の状態を維持し、適切な修正プログラムを適用し、定期的な監視を行うことで、安全でセキュアな環境を維持しましょう。

今すぐAikido あなたの環境をスキャンして、これらの脆弱性にさらされていないか調べてみましょう。

Aikido「2024 SaaS CTOセキュリティ・チェックリスト」で、人材、プロセス、コード、インフラなど、セキュリティ向上のための40以上の方法について簡潔なアドバイスをご覧ください。