開発スキルには自信があるものの、構築したアプリケーションがセキュリティや設定の欠陥から完全に解放されているわけではないことを認識されていることでしょう。利用可能なスキャンツールの広範なエコシステムを調査し、その選択肢の多さに圧倒されたかもしれません。依存関係、Infrastructure as Code (IaC) の設定、コンテナなどにおける脆弱性を特定するために、どのようなオープンソースのアプリケーションセキュリティツールを「ポートフォリオ」として選択するのが適切でしょうか？
正しい方向へ進むために、コードスキャンとセキュリティツールの10の重要なカテゴリを網羅し、9つのOSSプロジェクトを開始に必要な情報のみを添えて推奨します。
- そのスキャンがアプリのセキュリティにどのように役立つか。
- どのオープンソースプロジェクトをインストールできるか、そしてその実行方法。
- いくつかの代替案（利用可能な場合）から選択できます。
これにより、アプリケーションのコードやクラウド設定における重大なセキュリティ問題をスキャンするための、無駄のない直接的な方法が得られます。これほど素晴らしいことはありません。
設定と管理の部分はすべてが順調というわけではありませんが、それについては後ほど説明します。
必要なもの
デスクトップでもノートパソコンでも構いませんので、ローカルワークステーションをご用意ください。macOS、Windows、Linuxのいずれを使用しているかは問いません。
開発環境はオプションですが、推奨されます。このオープンソースのスキャンツールスイートを実行するには、ベースOSにインストールしたくない多くのソフトウェアをインストールする必要が生じる可能性があります。これにより、より大きなアップデートが必要となり、オートコンプリートに不要な項目が増え、すべてのプロジェクトで機能しない可能性のある特定のツールに縛られることになります。開発環境は、ある程度、開発に特化したすべてのツールをOSの他の部分からコンテナ化し、分離します。
幸いなことに、選択できる優れたオープンソースツールがいくつかあります。
- と Docker、という名前の新しい最小限のコンテナを起動できます。
devenv-01このように：docker run --name devenv-01 -it ubuntu:24.04 sh - と Daytona、開発ワークフロー向けに多くの「バッテリーが付属」しています。
daytona create --code - あるいは、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、および Oracle。リポジトリの config_example.js ファイル テンプレートとして、～を作成するために config.js 最初の完全な診断を実行し、JSON形式で結果を得るために必要なすべての詳細を含むファイル。
./index.js --collection=file.json config.js
#2: オープンソースの依存関係のソフトウェアコンポジション分析 (SCA)
SCAはアプリケーションセキュリティにどのように役立ちますか？
アプリには、UIフレームワークから、メールアドレスのバリデーターのような単一のLOCで使用するヘルパーライブラリに至るまで、現在依存しているオープンソースの依存関係が必然的に多数存在します。SCAは、コードの拡張されたファミリーに対する身元調査のようなもので、セキュリティ脆弱性やライセンスの問題を一度だけでなく、継続的に特定します。SCAツールが新しい脆弱性や修正について通知するため、オープンソースのサプライチェーンが生産性の妨げではなく、助けとなることを確信できます。
OSS SCAプロジェクトをインストールして実行します：Syft + Grype
ローカルでSCAを実行するには、ソフトウェア部品表（SBOM）を作成するためにSyftが必要であり、そのSBOMを既知の脆弱性について分析するためにGrypeが必要です。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: シークレット検出
シークレット検出はアプリケーションセキュリティにどのように役立ちますか？
A シークレット検出ツールは、公開したくない認証情報についてコードと設定をスキャンします。これらのシークレットには、APIキー、サードパーティプロバイダーへのアクセストークン、アップストリームデータベースへのパスワード、証明書、暗号化キーなどが含まれます。これらが公開リポジトリにプッシュされると、Git履歴からそれらを削除するために困難なプロセスを経る必要があります。コミットする前に早期に検出し、対策を講じる方が良いでしょう。
OSS Secrets検出プロジェクトをインストールして実行します：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
あなたの findings.json ファイルには、各潜在的なリークのコミットハッシュと作成者に関する詳細が含まれており、修正に集中するのに役立ちます。
代替案と注意事項
残念ながら、Gitleaks以外に多くの選択肢はありません。他のオープンソースのシークレット検出プロジェクトは、最後のコミットから何年も経過しており、今日開発しているアプリを保護するには、あまり信頼できるとは言えません。サービスプロバイダーの場合、GitHubシークレットスキャンパートナープログラムに登録できます。これにより、ユーザーが誤ってシークレットトークン形式をリポジトリにコミットした場合に特定されます。
#4: 静的アプリケーションセキュリティテスト (SAST)
SASTはどのように役立ちますか？
SASTは、アプリケーションセキュリティツールのきめ細かい櫛であり、コードベースを1行ずつ分析して、アプリケーションを脆弱な状態にする可能性のある欠陥のある構文、構造、またはロジックをチェックします。SQLインジェクション攻撃、クロスサイトスクリプティング (XSS) の機会、バッファオーバーフローなどを考えてみてください。既知のCVEの人気データベースと照合することで、堅牢なSASTツールは、大きなセキュリティ上の欠陥を見逃していないという自信を与え、中には迅速な修復のための自動修正提案を提供するものもあります。
OSS SASTプロジェクトをインストールして実行します：Semgrep
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
Nucleiは、コミュニティ主導の脆弱性スキャナーであり、テンプレートを使用してローカル環境で実行されている保護したいアプリにリクエストを送信します。YAMLを使用してカスタムテンプレートを作成できますが、Nucleiコミュニティには、アプリに対してテストするための広範な事前設定済みテンプレートライブラリもあります。
Nucleiをインストールするには、ローカルワークステーションにGoが必要です。
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
そこから、Nucleiを実行する最も簡単な方法は、単一のターゲット（開発環境でローカルに実行されているアプリケーション）を指定し、Nucleiがデフォルトでアクティブにするテンプレートライブラリを活用することです。
nuclei -u localhost:5678 -je nuclei-report.json
代替案と注意事項
Zed Attack Proxy (ZAP)は、世界中のセキュリティ専門家と開発者チームによって積極的にメンテナンスされている素晴らしいスキャナーです。しかし、このリストの他のツールとは異なり、ZAPはデフォルトでグラフィカルなアプリケーションです。ターミナルを使用するオプションもありますが、これまで実行してきた他のプロセスと比較すると、必ずしも開発者にとって最も使いやすいとは言えません。
#6: Infrastructure as Code (IaC) スキャン
IaCスキャンはアプリケーションセキュリティにどのように役立ちますか？
コードは本番環境への移行における方程式の半分に過ぎません。今日、ほとんどのチームはTerraform、CloudFormation、および「ベース」Kubernetes HelmチャートのようなIaCツールを使用して、宣言的、バージョン管理され、再現可能な方法でクラウドサービスをプロビジョニングしています。IaCスキャナーは、これらのJSONまたはYAMLブループリント内の脆弱性を特定し、不安全な状態が本番環境にデプロイされるのを防ぎます。
OSS IaCスキャンプロジェクトであるCheckovをインストールして実行します。
Checkovは、Terraform構成、Helmチャート、Dockerfileなど、さまざまな種類の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チームは、12以上のデータソースから収集された脆弱性情報の公開データベースを維持しています。
これまでに推奨されてきた他のインストールメカニズムと同様に、最新の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>
代替案と注意事項
これまで読み進めてきた方であれば、SCAに関する前のセクションで既にローカルワークステーションにGrypeがインストールされており、Syftによって作成されたSBOMを持つコンテナイメージのスキャンに非常に役立つことをご存知でしょう。AWSを利用している場合、Amazon Inspectorは「一石二鳥」で役立つもう一つの場面となります。
Amazon Inspectorも選択肢の一つですが、2つの大きな注意点があります。1つ目はAWSデプロイメントでのみ機能すること、2つ目は他の推奨ツールとは異なりオープンソースソフトウェアではないため、新たな月額費用が発生することです。
#8: オープンソースライセンススキャン
オープンソースライセンススキャンはアプリケーションセキュリティにどのように役立ちますか？
商用製品でオープンソースソフトウェアを使用することの合法性は、法務チームやコンプライアンスチームに一度確認して終わりというものではありません。OSSプロジェクトは、想像以上に頻繁にライセンスを変更するため、エンタープライズ版の支払い、代替案の模索、またはプライベートコードの一部をオープンソース化する必要が生じることがあります。ライセンススキャナーは変更を特定し、すぐに利用できるSBOM（ソフトウェア部品表）でセキュリティ監査をスムーズに通過できるよう支援します。
OSSライセンススキャンプロジェクトをインストールして実行する: Syft
前のステップのGrypeと同様に、Syftはすでにローカルワークステーションにインストールされており、GrypeとのSCA統合を設定した際に既存のSBOMがあるかもしれません。まだない場合は、構成済みのレジストリからのコンテナイメージを参照するか、ローカルワークステーション上のパスを参照することで、新しい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は使用しているロックファイルを識別するはずです。
phylum auth register
phylum auth login
phylum init
phylum analyze --json
Phylumの分析は、包括的な出力を提供し、 true または false Phylumのマルウェアチェックにプロジェクトが合格したかどうかに基づく結果です。各依存関係のrejections配列には、脆弱性の詳細な説明と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: End-of-life (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
新たな課題: すべてのコードスキャンおよびアプリケーションセキュリティデータの管理
ここまで読み進めてきたなら、オープンソースのコードおよび設定スキャンツールの便利なツールキットを構築したことになります。ローカルに保存されたプロジェクトやブランチに対してこれらを実行し、はるかに優れたプレコミットセキュリティ保証を得る準備ができています。シフトレフトを実現しましょう！
しかし、将来がすぐに完璧になるわけではありません。この新しいツールキットには大きな注意点があります。ツールは連携せず、アプリケーションの周辺のみを対象としています。
まだ以下の責任があります:
- 各ツールを個別に設定する。例えば、本番環境のセキュリティに関連しないため、スキャンする手間をかけたくない特定のディレクトリや依存関係の許可リストのような簡単なオプションを考えてみましょう。各CLIツールの引数をドキュメントを読んでテストすることで学ぶ必要があり、これは実際にやりたいこと、つまり修正を実装することから貴重な時間を奪ってしまいます。
- 各リポジトリとブランチに対して各スキャナーを実行します。たとえ単一のリポジトリと2つのブランチしかなくても—
mainそしてdev—それは脆弱性をスキャンするために約20もの操作が必要になります。理想的には、リモートに変更をプッシュする前にこれらのスキャナーを実行することになりますが、これは一日を通して多くの繰り返し作業を意味します。
もちろん、これを簡素化する方法はいくつかあります。これらのオープンソーススキャナーを連携させるスクリプトを作成し、手動で実行したり、Gitのpre-commitフックとして実行したりできます。これによりターミナルでの時間は節約されますが、JSON出力が速くなるだけであり、依然として理解する責任があります 何が変更されたか、そして変更をプッシュできるか、（最終的に）プルリクエストを作成できるか、です。 - 膨大なJSON配列から洞察を掘り出す。これらのツールは、しばしば数千行に及ぶ出力を生成します。網羅性は良いのですが、数十、数百もの潜在的なセキュリティ問題を一つ一つその深刻度を理解するのに十分なほど調査する時間があるでしょうか？
時間が経つにつれて、Google Sheetsへのインポートや結果表示用のシンプルなアプリの構築など、整形されていないJSONの行よりも直感的な方法で結果を読み取る必要が出てくるでしょう。 - 実行間の変更点を理解する。セキュリティスキャンには2つの目的があります。1つ目は、コードと設定における既存の問題を特定するのに役立つことです。2つ目は、構築中に新しい脆弱性を導入するのを防ぐことです。特定の脆弱性を修正したかどうかを迅速に理解できない場合や、新しい脆弱性がコードに紛れ込んだ際に通知されない場合、この取り組み全体は時間の無駄になります。
一つの選択肢は、出力JSONファイルにインクリメントまたはタイムスタンプを付与し、CLIツールを使用して比較することです。diff file1.json file2.jsonは優れたスタンドアロンツールであり、またはgit diff --no-index file1.json file2.jsonGitリポジトリにコミットされていないファイルに対して使用できます。 - 長期分析のためにデータを集約、保存、共有する。以前にも述べたように、セキュリティスキャンはTODOリストの一回限りの項目ではなく、継続的な運用です。さらに、スキャン結果をローカルワークステーションに閉じ込めておくべきではありません。同僚は、たとえ現時点で同様のツールキットを実行していなくても、彼らが構築したものに最も関連する脆弱性について知りたいと思うでしょう。
これらすべての情報を一箇所に集約するデータプラットフォームを検討する必要があります。これは、自己ホストするか、費用を支払う必要のあるもう一つのインフラストラクチャです。 - JiraまたはGitHubでチケットを作成します。あなたまたは同僚は、特定された各脆弱性を、必要なすべてのコンテキストと可能な修正策を含む関連チケットにエスカレートする必要があります。これが、セキュリティの透明性を確保し、同僚との協力を促し、コンプライアンス基準で要求される可能性のある監査ログを作成する唯一の方法です。これらのツールはいずれもチケットプラットフォームとの統合をサポートしていないため、これらのチケットを手動で作成する必要があります。そして、それは数十、場合によっては数百にも及ぶ可能性があります。
- チケットを重要度に基づいて優先順位付けする。リポジトリをチケットで溢れさせることは、プロジェクト管理上の悪夢です。それはアラート疲れの異なる、しかし同様に苦痛なバージョンです。誰もが最初にどれに集中すべきかを知るにはどうすればよいでしょうか？もしOSSツールが重要度の判断を助けてくれない場合、自分でそれらの決定を下すのに時間を費やす必要があり、それは単純に近道できない長年のセキュリティ知識を伴うかもしれません。
- 各OSSツールのライフサイクルを管理する: ツールの最新状態の維持、自動化の構築、または実行と結果のCI/CDパイプラインへの組み込みなど、ツールキットの長期的な有効性について責任を負うことになります。以前よりも優れたセキュリティ体制を築けるかもしれませんが、実際の運用体制にはどのようなコストがかかるでしょうか？
- プロジェクトがメンテナーを失った場合に何が起こるかについて懸念し、疑問に思う。依存関係やランタイムがEOLに達して問題を引き起こす可能性があるのと同様に、ローカル開発環境が依存するツールやプラットフォームも問題を引き起こす可能性があります。残念ながら、オープンソースプロジェクトは、長期的に持続可能ではない資金調達モデルやメンテナーモデルに基づいて構築されていることがよくあります。CLIで停滞または放棄されたプロジェクトを使い続けることはできますが、アプリケーションのセキュリティを向上させようとする場合、それらは新しい脆弱性や攻撃方法を発見するのに役立ちません。
開発者ツールにおける現在の議論は、開発者エクスペリエンス（DX）という単一の概念を中心に展開されています。DXが優れているほど、ツールは統合され、使用され、高く評価され、支持される可能性が高まります。正直に言うと、このローカルで実行されるOSSスキャンツールキットのDXは、特に優れているとは言えません。プロセスとデータを完全に所有できますが、その代償として並外れたコストと時間の投入が必要です。高度なアプリケーションセキュリティのために、どれだけの費用を支払う用意がありますか？
オープンソースのセキュリティツールは素晴らしいものです。私たちは、Node.jsアプリを一般的で重大な攻撃から自律的に保護するためのWebアプリケーションファイアウォールさえ構築しました。しかし、継続的なセキュリティスキャンと脆弱性修復には、別の方法が必要です。おそらく、この素晴らしいOSS基盤の上に構築されたものかもしれません。
新しいアプリセキュリティソリューション：Aikido
Aikidoは、それらのすべてのポイントオープンソースソリューションを1つのエンドツーエンドセキュリティプラットフォームで置き換えます。
最新の変更をコミットするたびに10以上のツールを実行する代わりに、リポジトリ、Dockerイメージ、およびクラウドプロバイダーを一度Aikidoに追加するだけで、包括的なスキャンが可能です。Aikidoは、継続的なスキャンのためにバックグラウンドで自動的に実行されるか、またはプルリクエストごとにターゲットを絞った推奨事項を提供するためにCI/CDパイプラインで実行され、新しい脆弱性から保護しつつ、コードベースに数ヶ月または数年間潜んでいた既存の脆弱性を指摘します。
さらに良いことに、すべての結果、コンテキスト、および可能な修復策は、Aikidoダッシュボードという一箇所に集約・保存されるため、JSONの解析、複数のデータソースのマージ、あるいは信頼できる情報源を作成するための高価なデータ管理プラットフォームへの出費について心配する必要がありません。これらのオープンソースプロジェクト間には、カスタムルールと特別な「接着剤」を構築しており、これにより、社内の専門セキュリティ研究者でなければ発見できないような相関関係や結果を明らかにすることができます。
AikidoはGitHubやSlackなどのタスク管理およびメッセージングプラットフォームとも統合され、事前にトリアージされ、優先順位付けされたチケットを作成します。すべてのコンテキスト、ドキュメント、および推奨される自動修正が提供されるため、チームの誰でもその問題を引き継ぎ、迅速かつ包括的に修正を完了できます。
これらのオープンソースツールやその他多くのツールがなければ、アプリケーションセキュリティははるかに悪い状況にあったでしょう。それは議論の余地がありません。しかし、開発ツールがローカルワークステーションやターミナル内で動作するという性質上、それらは無限の柔軟性を持つと同時に、本質的に分離されています。「私のマシンでは動作した」というミームは、表現は異なるものの、ここでも当てはまります。
このオープンソースツールキットを構築する負担をすべて解消し、同じプロジェクトを基盤として既に構築されているプラットフォームに置き換える別の方法をお探しでしたら、Aikidoを無料でお試しいただくことをご検討ください。
OSSルートを選択される場合、私たちはその選択に敬意を表します。しかし、新しいツールや依存関係をワークフローに組み込む際には、AikidoのWeb Application Firewallに、Node.jsアプリを最も悪質な脆弱性からも自律的かつ継続的に保護させるべきです。結局のところ、最高のDXとは、ツールがすべての困難な作業を真に代行してくれるときに実現されるものです。
