ようこそ
JFrog’s Blog

開発者である私たちはどのように設計し、コーディングし、デバッグし、結合するかにほとんどの時間を費やしています。思考はソースファイルに向けられ、バージョンコントロールシステムを構成するリポジトリやブランチに注目します。それが私たちの仕事であり、私たちの世界なのです。 しかし、DevOpsのプロフェッショナルになるためには、コードを実行する環境に持っていくために何が起こるかを考えなければなりません。DevOpsとはアプリケーションの開発から配布までを行うことです。 DevOpsを成功させるためには、ソフトウェアの構成要素であるアーティファクトに焦点を当てなければなりません。 配布されるアプリケーションはバイナリ、依存関係、イメージなどのアーティファクトで構成されており、それらは互いに接続されています。納品可能なソフトウェアアプリケーションを作るために必要なアーティファクトの多様なエコシステムを理解することは本番環境へのリリースを加速するための第一歩です。 アーティファクトのエコシステム 自然界では全ての生物と物理的環境が相互に影響し合って生態系を構成しています。それぞれがバランスを保ちながら他方を支えています。 継続的インテグレーション・パイプラインにおけるアーティファクトのエコシステムも、ほぼ同じです。アーティファクトは他のアーティファクトに依存し、あるプロセスで作られたアーティファクトは別のプロセス利用されます。 アーティファクトのエコシステム パッケージ アプリケーションはMaven、npm、PyPi、Conanなどのパッケージ管理技術によって配布されるオープンソースやプロプライエタリの依存関係に依存しています。これらのコンポーネントは直接依存と他動的依存間でアプリケーションコードの大部分を構成します。 ビルド デプロイ可能なアプリケーションはソースコード、依存関係、サポートファイルからビルドされ、WAR、ZIPまたはその他のアーカイブ形式になります。Artifactoryは「ビルド情報」メタデータによってビルドを記録し、すべてのコンポーネントを元に戻すことができます。 コンテナ アプリケーションをDockerやOCIイメージとしてパッケージ化してコンテナとして使用したり、Artifactoryのプライベートレジストリに保存したりすることができます。 設定ファイル アプリケーションにはKubernetesでオーケストレーションを行うためのHelmのような設定ファイルやChefやPuppetのようなInfrastructure-as-Codeファイルが必要になります。Artifactoryはこれらのリポジトリタイプをネイティブにサポートしているため、これらの重要なファイルを信頼できる唯一の情報源に保管することができます。 リリース 最新のアプリケーションは通常、相互に動作するマイクロサービスで構成されており、バージョン管理された一式を配布する必要があります。JFrog Distributionはアプリケーションのコンポーネントを署名付きのリリースバンドルにまとめ、トレースしているため、エッジサーバーに安全に配布することができます。 Artifactoryの信頼できる唯一の情報源 Artifactoryは全てのアーティファクトのためのユニバーサルリポジトリマネージャであり、多様なアーティファクトエコシステムのための信頼できる唯一の情報源を提供します。 約30種類のパッケージタイプをネイティブにサポート（Genericリポジトリを含む）しており、開発組織のアーティファクトエコシステム全体を保存、整理、追跡するための唯一の情報源となります。開発者は日常的に使用しているパッケージ管理サービスを利用し、パッケージやイメージをArtifactoryリポジトリに保存・取得することができます。 Artifactoryリポジトリタイプ Artifactoryのユニバーサルなバイナリ管理は組織内のすべての開発者に提供されます。Java、JavaScript、Python、Go、C++、C#、Swift、Rustなどでプログラムを開発しているかどうかにかかわらず、Artifactoryはすべてのパッケージとビルドの中心となります。 メタデータ Artifactoryはパッケージタイプや「ビルド情報」と呼ばれるメタデータを保持しているため、アーティファクトがどこから来たのか、どのように作成されたのか、どこに配置されたのかを知ることができます。この包括的なメタデータがあれば全てのアーティファクトがどこから来たのか、またどこで使用されたのかを追跡できます。 リモートリポジトリのプロキシ Artifactoryのリモートリポジトリは唯一の情報源にリモートリソースの依存関係をキャッシュするをローカルプロキシです。開発者はリモートリソースに直接アクセスすることなく、Artifactoryの依存関係を不変的なコピーをオンデマンドで使用してビルドします。 これにより、物理的な距離や不安定なサービス接続に起因するネットワークの遅延を解消し、ビルドを可能な限り高速に実行することができます。また、プロキシは接続の中断やリモートサイト自体が利用できなくなった場合の問題を防ぎます。 開発からDevOpsへ アーティファクトのエコシステムを理解し、継続的統合パイプラインでのフローを管理する方法を理解することは、開発からDevOpsへの移行の第一歩です。 すべてのアーティファクトがArtifactoryの唯一の情報源によって管理されていれば、企業全体が同じSDLCワークフローとベストプラクティスに沿って調整することができ、品質を保証し、リリース速度を加速することができます。これがArtifactoryがJFrog DevOps Platformを強化する完全に自動化されたソフトウェア配布パイプラインの中心的なコンポーネントである理由です。 可能性を追求するため、JFrogクラウドの無料アカウントでArtifactoryを始めましょう。  

NicheStack は、製造工場、発電・送電・配電、水処理などの重要なインフラを含む、世界中の何百万ものオペレーショナルテクノロジー（OT）機器で一般的に使用されている TCP/IPネットワークスタックです。 JFrogのセキュリティリサーチチーム（旧Vdoo）は、 Forescout Research Labs, と共同で、NicheStack TCP/IPスタックに影響を与える14の新しいセキュリティ脆弱性を発見しました。これらの脆弱性により、リモートでのコード実行、サービス拒否、情報漏洩、TCPスプーフィング、DNSキャッシュポイズニングが可能になります。 このブログ記事では、INFRA:HALTと名付けられたこれら14件の脆弱性の詳細と、それらを緩和するための推奨事項をご紹介します。 NicheStackとは？ NicheStackは、1996年にInterNiche Technologies社により開発された、一般的に使用されている、組み込みシステム用の独自のTCP/IPスタックです。2003年には、IPv6に対応しました。 NicheStackは、他のTCP/IPスタックの基礎となるもので、STMicroelectronics、Freescale (NXP)、Altera (Intel)、Microchip などのOEM向けに異なるバージョンが配布されました。 NicheStackプロトコルサポート 現在、NicheStackでサポートされているプロトコルです。 NicheStackディストリビューション NicheStackは、世界中のOT機器でよく使われています。例えば、PLC市場で最大のシェアを誇るSiemens S7 PLCに採用されています。また、当社の調査によると、産業用オートメーションのトップ企業を含む約200社のデバイスベンダーで使用されており、Shodan の検索結果では6,400デバイスのインスタンスでNicheStackを実行していることがわかりました。 新しい14件の NicheStack セキュリティ脆弱性 NicheStackの2つのバージョンを解析しました。バージョン4.0.1のバイナリサンプル（従来のInterNicheのウェブサイトで公開されています）とバージョン3のソースコード（組み込みプロジェクトのソースファイルを公開しているウェブサイトにあります）です。バイナリ版は、JFrogが静的および動的な独自技術を使用して手動および自動で分析しました。 以下の表は、新たに発見された14件の脆弱性すべての詳細です。NicheLiteを含む、最新のバージョン4.3以前のすべてのNicheStackのバージョンが影響を受けます。 CVE ID ベンダー ID 説明 影響を受けるコンポーネント 潜在的な影響 CVSSv3.1 スコア 2020-25928 HCCSEC-000002* HCCSEC-000010 DNS応答を解析するルーチンでは、個々のDNS応答の「応答データ長」フィールドをチェックしないため、OOB-R/Wが発生することがあります。 DNSv4 クライアント RCE  9.8 2021-31226 HCCSEC-000003 HTTP POSTリクエストを解析するコードに、サイズ検証が行われていないことによるヒープバッファオーバーフロー脆弱性が存在します。 HTTP サーバー RCE  9.1 2020-25767…

セキュリティをシフトレフトするということは 開発者がSDLCの早い段階で脆弱性とライセンス違反を認識して修正することを意味します。そのため、XrayはビルドによってArtifactoryにプッシュされたバイナリをスキャン し、依存関係に問題がある場合に警告します。 しかし、コードをチェックする前であっても、それらをより早く認識することはシフトレフトする開発者にとって重要なことです。そこで、Xrayの機能を拡張し、JFrog CLIからローカルファイルシステムのディレクトリにあるソースコードやバイナリをオンデマンドでスキャンできるようにしました。 これらのユースケースが必要とされる理由をご紹介します。 すべてのバイナリがArtifactoryに保存されているわけではない Artifactoryにアップロードする前にビルドの脆弱性とライセンス違反を発見することができる セキュリティ担当者は送られてきたバイナリをスキャンして確認する必要があるかもしれない 承認されたバイナリのみをArtifactoryに配置したい これらのJFrog CLIの機能により、開発者やセキュリティチームなどはアプリケーションがArtifactoryの信頼できる唯一の情報源の一部となる前に、脆弱性とライセンス違反を防ぐことができます。 Xray依存症スキャン XrayはJFrog CLIを使用し、ソースの依存関係にある脆弱性やライセンス違反をスキャンする機能を提供します。このコマンドラインツールはコンパイル、テスト、Artifactoryへのデプロイを必要とせず、いつでもどこでも実行できるソースディレクトリのスキャンを可能にし、問題に対処するための貴重な時間を節約します。 CLIを使用した場合、XrayはArtifactoryリポジトリと同じ方法で依存関係をスキャンします。このコマンドは依存関係で発見された脆弱性やライセンス違反を含む詳細なスキャンレポートを返します。この機能には次のようなメリットがあります。 Artifactoryにアップロードする前のビルドに脆弱性やライセンス違反を開発者がコードを書きながら確認できる Artifactoryにアップロードすることなく、アドホックなセキュリティスキャンを実行することができる バイナリやソースをArtifactoryにアップロードする前に承認する必要があるなど、組織の基準を遵守できる 現在、これらのJFrog CLIへの追加機能はMaven、Gradle、NPMパッケージのソーススキャンのみをサポートしています。 どのような仕組みになっているのか？ コマンドラインからスキャンを開始する為にソースファイルを含むトップレベルのディレクトリに変更する必要があります。その後、JFrog CLIコマンドを実行し、ファイルのXray依存性スキャンを行います。 一度に監査を実行できるのは1種類のプロジェクトのみです。ソースコードのMavenプロジェクトのスキャンを実行し、すべての脆弱性を報告する場合は以下になります。 $ jfrog xr audit-mvn また、Xrayでポリシーが適用されたウォッチ、プロジェクト、リポジトリのパスを指定し、Xrayのポリシールールをスキャンに適用することができます。例えば「watch1」で使用したポリシールールのセットをMavenプロジェクトのスキャンに適用する場合は以下になります。 $ jfrog xr audit-mvn --watches "watch1" 処理完了後、デフォルトではこれらのセキュリティとライセンスポリシーに違反する依存関係のレポートが作成されます。 JFrog CLIでは代わりにJSONファイルとしてレポートを作成することができるため、お好みのツールで処理することができます。 Xrayオンデマンド・バイナリスキャン コンパイル後に脆弱性を見つけて修正する必要がなく、時間の節約になるため、開発者個人または組織として開発中のソフトウェアをセキュアにコーディングしたいと思うかもしれません。前出の新しいスキャン機能と同様にオンデマンド・バイナリスキャンを行うためにJFrog CLIを使用します。 ローカルファイルシステムにあるバイナリを指定するだけで、そのバイナリの脆弱性とライセンス違反をレポートすることができます。JFrog CLIはXrayがArtifactoryでバイナリをスキャンするのと同様に、バイナリを抽出し、バイナリからコンポーネント・グラフを構成するロジックを含むクローズソース・コンポーネントをカプセル化しています。詳細についてはXray Security and Complianceを参照してください。CLIはバイナリで検出された脆弱性、違反、ライセンスの詳細なスキャン結果をレポートします。 現在、Dockerのバイナリスキャンはまもなくサポート予定ですが、その他すべてのパッケージタイプでサポートされています。 どのような仕組みになっているのか？ Xrayオンデマンド・バイナリスキャンを実行する手順はソースファイル・スキャンと非常によく似ています。例えば「watch1」で使用したポリシールールをローカルファイルシステムのバイナリに適用する場合は以下になります。 $ jfrog xr s "path/to/files/"…

ソフトウェアパッケージのリポジトリは、サプライチェーン攻撃の標的として注目されています。最近では、npm、PyPI、RubyGems などの人気リポジトリに対するマルウェアの攻撃に関するニュースがありました。開発者はリポジトリを盲目的に信頼し、安全であると仮定して、これらのソースからパッケージをインストールしています。時には、マルウェアパッケージのパッケージリポジトリへのアップロードが許可されることもあり、悪意のあるアクターは、リポジトリを利用してウイルスを配布し、パイプライン上の開発者と CI/CD マシンの両方に対して攻撃の機会を与えてしまいます。 JFrog セキュリティリサーチチーム (旧 Vdoo)による悪意のあるパッケージを自動的に識別する継続的な取り組みの一環として、PyPI にホストされているいくつかの Python パッケージを悪意のあるものとして報告しています。私たちは PyPI に悪意のあるパッケージの存在を警告し、PyPI は速やかにそれらを削除しました。 pepy.tech からのデータに基づき、私たちは悪意のあるパッケージが約 30,000 回ダウンロードされたものと考えています。これらの悪意のあるパッケージが使用されたことによる実際の影響についてのデータは現在のところありません。 今回のブログでは、これらのパッケージのテクニカル分析とその影響についてご紹介します。 報告されたパッケージ Package name Maintainer Payload noblesse xin1111 Discord のトークンを盗む、クレジットカード情報を盗む (Windowsベース) genesisbot xin1111 noblesse と同じ aryi xin1111 noblesse と同じ suffer suffer noblesse と同じで、PyArmor によって難読化されています noblesse2 suffer noblesse と同じ noblessev2 suffer noblesse と同じ pytagora leonora123 リモートコードインジェクション pytagora2 leonora123 pytagora と同じ…

RustはStackoverflowが実施した最も好きなプログラミング言語の調査で5年連続で首位を獲得しました。C/C++の次のステップとして注目されているこの言語は組込み機器の開発者やIoT向けの堅牢なシステムによって急速に普及しています。 JFrogではRustの開発者を歓迎し、堅牢なバイナリ管理と継続的インテグレーションにどのように貢献するかを紹介したいと思います。私たちはRustプログラミング言語のパッケージ管理システムであるCargoをArtifactoryでサポートするリポジトリに加えました。 86%以上の開発者が熱狂的に支持したRustの特徴とは？また、ソフトウェア開発のライフサイクルを加速するために、ArtifactoryのCargoリポジトリをどのように利用できるのでしょうか？ なぜRustなのか？ Mozilla ResearchはRustを「スピード、メモリの安全性、並列性に重点を置いたシステムプログラミング言語」と表現しています。これらの重要な機能はそのビジョンを支えるものです。 自動ガベージコレクション - RustはRAII (Resource Acquisition Is Initialization) を強制することでリソースリークバグを防ぎ、リソースを所有するオブジェクトがスコープ外に出たときには必ずリソースを解放します。 強力な並列処理のサポート - Rustは並列処理するマルチスレッドプログラミングを安全で効率的に扱えるように設計されています。強力な型、SendとSyncの特性は同期したスレッドセーフな動作を保証し、標準的なスレッドライブラリはRustコードの並列処理を可能にしています。 セーフティチェック - Rustのコンパイラはメモリーセーフティーなどのチェックを行い、クリーンで堅牢なコードを実現します。 再利用可能パッケージ - Rustは開発者が再利用可能なコードユニットをプロジェクト内でプライベートに共有したり、他の人とパブリックに共有することもできるクレートを作成できる強力なシステムを提供しています。 依存関係の管理 - Rust用のCargoパッケージマネージャはパッケージの依存関係をダウンロードしてコンパイルする機能を備えています。 これらの機能は他の人気のある構文機能（複雑なデータ型、mutable/immutableの借用、回復可能/回復不可能なエラー処理など）と合わせて開発者には喜ばしいことです。 リモートCargoリポジトリ フレンドリーで活発なRustコミュニティはオープンソースのパッケージを配布するためにcrates.ioパッケージレジストリを管理しています。Rustプログラマはアプリケーションのコアサービスの大半は、このパブリックライブラリを利用することになります。 チーム間でのRustビルドのスピードと一貫性を担保するために、Artifactoryのリモートリポジトリを使用してcrates.ioをプロキシします。 ArtifactoryのリモートリポジトリはリモートURLで管理されているリポジトリやレジストリのキャッシングプロキシとして機能します。リモートリポジトリのコンテンツとネイティブソースの間に違いはありません。 このDevOpsベストプラクティスを実践することで、あなたとチームは利益を得ることができます。 スピードのためのローカル化 -- プロキシは頻繁に使用するパッケージをクラウドでもオンプレミスでも、ビルドが行われる環境に保持することで、ネットワークのレイテンシーを最小限に抑えます。 接続保護 -- crates.ioプロキシは接続不良や中断によりcrates.ioサーバが利用できない場合やリモートサーバー自体に障害が発生した場合でも利用可能です。  不変性の確保 -- いったんパッケージのバージョンがプロキシの登録後、それは不変で、それを使用する全てのビルドで同じものになります。これによって、パブリックリポジトリへの不適切な強制プッシュによってビルドに何かが入り込むことを防ぎます。 crates.ioのリモートリポジトリプロキシを簡単に設定できます。 Artifactoryで新規のCargoリモートリポジトリを作成 リモートリポジトリに名前を付け、crates.ioのURLを割り当て アプリケーションパッケージのconfig.tomlマニフェストファイルでcrates.ioの代わりにArtifactoryのリモートリポジトリにリダイレクトするように[registry]のデフォルトを設定します。 （手順はArtifactブラウザの「Set Me Up」を参照してください） リモートリポジトリプロキシは読み取り専用ですが、ビルドのためにオープンソースの依存関係を取り込むという日常的な作業のほとんどにとっては当然のことです。crates.ioに公開する必要がある場合は[registries]で名前を定義し、公開する際に--registryオプションで使用することができます。（マニフェスト内のpackage.publishキーでレジストリ名を指定することでレジストリへの公開が可能になります） # Makes artifactory the default registry…

JFrog がソフトウェア脆弱性対策ソリューションを提供する Vdoo（ビドゥ） を買収した目的の1つは強靭なセキュリティを持つ Vdoo の技術をJFrog DevOps Platform に統合することです。 Vdoo のセキュリティ技術により、ソフトウェアおよびデバイスの脆弱性を検知し、さらにそれらの脆弱性の修正方法の提示、多数に及ぶ脆弱性の優先順位化、各種スタンダードとのセキュリティギャップを明確化できます。 これらのVdooの技術を JFrog DevOps Platform に統合することで、お客様のソフトウェア・ライフサイクル全体を踏まえた、「セキュアバイデザイン」「シフトレフト」といった効率的なセキュア開発プロセスが実現されます。 Vdoo のセキュリティ技術により、ソフトウェアおよびデバイスの脆弱性を検知し、さらにそれらの脆弱性の修正方法の提示、多数に及ぶ脆弱性の優先順位化、各種スタンダードとのセキュリティギャップを明確化できます。 どのような課題に対応するのでしょうか？ 特に、組み込み製品や IoT 製品では、出荷後にソフトウェアをアップデートすることは容易ではありません。またいかなるソフトウェアでも開発最終段階でセキュリティ問題が発見されると、その修正には膨大なコストがかかります。この大きな課題への対策は、セキュリティを考慮した開発プロセスを構築することです。 どのような脅威に対応するのでしょうか？ まず、既知の脆弱性を含んだソフトウェアを使用しないことです。OSS を使用することが当たり前である現在の環境下では、他者の作成したソフトウェアの脆弱性を短時間で検知するには、自動化された脆弱性検知ツールが必要です。また、自社作成のソフトウェアに潜在的な脆弱性がないかをセキュリティの見地から検査することも必要です。さらには OSS にはライセンス違反の脅威も常につきまといます。 Vdoo ソリューションによって、このような脅威を短時間で検知することが可能です。製品をセキュアにすることでユーザを守ることは企業信頼を高めます。セキュアバイデザインによりタイムリーな製品リリースを実現することは、マーケットで優位に立つ重要要素です。この二つを同時に実現することで、ビジネスの成功の必要条件を満たすことにつながります。   JFrogとVdooのリーダーが初めて共同で行ったウェビナーで、JFrogがVdooを買収した理由、プラットフォームのセキュリティとコンプライアンス 機能がどのように拡張されるのか、そして統合のスケジュールについて説明しました。 「私たちは将来にとても期待しています。私たちは、この機能をできるだけ早くお客様にお届けするために懸命に取り組んでいます。」とJFrogのCTO兼共同設立者であるYoav Landmanはウェビナー Vdoo & JFrog: Enhanced Security from Code to the Edgeの中で言っています。 開発、セキュリティ、運用の一体化 特に大規模な組織では開発、セキュリティ、運用チーム間に断絶や不信感が生じることがよくありますが、彼らを結びつけるものはランタイムバイナリです。開発者はこれを作り、セキュリティ担当者はこれをスキャンし、運用担当者はこれをデプロイして監視するのです。 「それが共通点です」とLandmanは言っています。この点がJFrogはVdooと相性が良いと判断した主な理由です。どちらもバイナリにフォーカスしているからです。 VdooのCEO兼共同設立者であるNati Davidiは「バイナリが全てだ」と述べています。「バイナリを見ることは何が重要かを理解する唯一の方法です。」 バイナリに焦点を当てたVdooは真のコンテキスト分析を行い、誤検知率を劇的に減少させ、優先すべき最も重要な問題をピンポイントで特定し、セキュリティやコンプライアンスのギャップを生む可能性のある設定ミスなどの死角を削減します。 同様に重要なのはバイナリに注目することがアタッカーを真に理解する唯一の方法だということです。 JFrogとVdooはソフトウェア・セキュリティの重要な側面をすべてカバーすることで、開発、セキュリティ、運用の各チームに組織のソフトウェア・セキュリティとコンプライアンスのニーズ全体に対する包括的なテストと分析のための単一ソリューションを提供します。 これによって組織は強調して統一された DevSecOps 戦略とアプローチを持つことができ、すべてのチームが一体となって働き、同じ具体的な証拠と指針に基づいて意思決定を行えるようになります。…

少人数の開発者チームが一つの部屋でアプリケーションを作っていた時代はとうに過ぎ去りました。今やエンタープライズソフトウェアの開発は世界中の複数の拠点に配置されているチームがパッケージを共有するという、高度な共同作業になっています。 エンタープライズ向けに、JFrog Artifactoryは様々なプッシュ/プルレプリケーションのトポロジーオプションによって、マルチサイトレプリケーションを可能にし、地理的に分散したチームはローカルリポジトリで最小限のレイテンシーで同じアーティファクト（バイナリとメタデータ）の利用が可能になっています。 最近では双方向ミラーリング技術であるJFrog Artifactoryフェデレーテッド・リポジトリを導入し、DevOpsチームにマルチサイトのチームやプロジェクトのための設定と管理が容易なオプションを提供しています。このリポジトリミラーリング技術は複数のサイト間のリポジトリのフェデレーテッド・セットを継続して同期します。 JFrog Artifactoryのフェデレーテッドリポジトリにより、企業は以下のことが可能になります。 地理的に分散したチーム間でソフトウェアを共同開発 頻繁に更新されるバイナリをサイト間で安全かつ効率的に同期が可能 グローバルに展開 共有されているすべてのアーティファクトとメタデータがどこでも最新バージョンであるのを確実に実施 ディザスタリカバリのためのレプリケーション フェデレーテッド・リポジトリでグローバルにスケールアップ JFrogのフェデレーテッド・リポジトリは地理的に分散したチームがアーティファクトとメタデータを一括して共有することで、マルチサイト開発を可能にします。 フェデレーションによって、1つのArtifactoryデプロイメント（例えばアムステルダム）のローカルリポジトリは他のArtifactoryデプロイメント（例えばバンコク）のローカルリポジトリと同期するように論理的に結合することができます。このように結合することでアムステルダムのリポジトリにプッシュされたアーティファクトやメタデータは自動的にバンコクのリポジトリにレプリケーションされます。また、このフェデレーションは双方向なため、バンコクのリポジトリにプッシュされたデータもアムステルダムにレプリケーションされます。 このように、フェデレーションに参加したArtifactoryリポジトリは各サイトに対し、グローバルな共有データにローカルでアクセス可能な統一されたリポジトリを提供します。 マルチサイトの同期 容易な管理 フェデレーテッド・リポジトリを使用することで、1つのサイトで承認された管理者が複数のJFrog Platformのローカルリポジトリを作成し、単一のマルチサイトフェデレーションに結合することができます。フェデレーショントポロジーを作成するために、タイムゾーンを越えた異なる物理的なサイトにいるプラットフォーム管理者間で設定を調整する必要はありません。 設定やメンテナンスは提携しているどの物理的なサイトからでも迅速かつ容易に行うことができます。設定やリポジトリの設定に対するすべての変更は全てのフェデレーションメンバー間で自動的に同期されます。 管理者ビュー エンタープライズな拡張性 Artifactoryのユニバーサルパッケージ管理でサポートされている30種類のリポジトリタイプ間でフェデレーションすることができます。もちろん、フェデレーション内のすべてのリポジトリは同じタイプでなければなりませんが、異なるパッケージタイプのために複数のフェデレーションを作成することができます。例えばnpmリポジトリのフェデレーション、Mavenリポジトリのフェデレーション、Dockerのフェデレーションなどが可能です。 リポジトリフェデレーションには同じリポジトリタイプのメンバー（リモートサイトにある異なるJFrog Platformデプロイメント（JPD）のローカルリポジトリ）を最大10個まで含めることができ、地理的に広い範囲をカバーすることができます。 セキュアな信頼関係 フェデレーテッド・リポジトリではバイナリプロバイダ・トークンを使用し、各サイトで証明書を設定することなく、メンバー間の信頼関係を確立します。JFrog Mission Controlは自動的に全てのJPDをセキュアなフェデレーションに対応させますが、セキュアなJFrog PlatformのURLを手動で指定することもできます。 各サイトの管理者は自サイトのJPDで管理しているパーミッショングループを通して、自サイトのユーザーによるフェデレーテッド・リポジトリへのアクセスを可能にしたり、制限したりすることができます。 フェデレーテッド・リポジトリの設定方法 フェデレーテッド・リポジトリを使用するために、JPD間でクロスインスタンス認証（Circle-of-Trust）を設定する必要があります。この設定完了後、プラットフォーム管理者は、事前に定義された権限セットに基づいて、リポジトリに対してCRUD（Create、Remove、Update、Delete）アクションを実行することができます。 1つのフェデレートリポジトリに対して行われた全てのアクションはリポジトリのコンテンツだけでなく、重要な設定変更も含めて自動的に同期され、すべてのフェデレーテッド・メンバーに反映されます。 フェデレーション内において、アーティファクトとメタデータの双方向のミラーリングが行われるのが直接的な接続を宣言したリポジトリ間のみであるということは重要なポイントです。ミラーリングは二次的に接続された他のリポジトリに自動的にカスケード接続されることはありません。 例えば以下の4つのJFrog Platformを導入したマルチサイトの例を考えてみます。 Amazon Web Services (AWS)のクラウドインスタンス フロリダ州オーランドにあるメインデータセンターのオンプレミスサイト カリフォルニア州サンタクララ本社のオンプレミスサイト マサチューセッツ州ウォルサム支社の開発オフィスのオンプレミスサイト これがどのように機能するか、いくつかのトポロジーの例を見てみます。 スター型トポロジー スター型トポロジーではJPD内のローカルリポジトリはフェデレーション内の他のJPDリポジトリに対するセントラルハブの役割を果たします。ハブとなるJPDリポジトリはアーティファクトとメタデータをフェデレーション内の全てと共有し、全てのアーティファクトをハブと共有します。しかし、他のサイトはお互いに共有していません。 この例ではアフィリエイトサイトに接続するためのセントラルハブとして、AWS上のクラウドインスタンスからフェデレーションを構成します。3つのオンプレミスサイトではフェデレーテッド・リポジトリの設定は行われません。 つまり、この例では AWSのリポジトリにプッシュされたアーティファクトはオーランド、サンタクララ、ウォルサムにミラーリングされる オーランドのリポジトリにプッシュされたアーティファクトはAWSにのみミラーリングされる サンタクララのリポジトリにプッシュされたアーティファクトはAWSにのみミラーリングされる ウォルサムのリポジトリにプッシュされたアーティファクトはAWSにのみミラーリングされる オーランド…

JFrogはバイナリやIoT/デバイスにルーツを持つイスラエルを拠点とするセキュリティ製品のリーディングカンパニーであるVdoo社の買収に合意したことを発表でき大変嬉しく思います。Vdoo社のチームと技術ポートフォリオ全体をJFrogに組込み、開発チームとセキュリティチームを完全に統合した包括的なセキュリティアプローチを実現するソリューションを提供します。 現在、大多数の企業で DevOpsプロセスによって連携される以前のソフトウェア開発パイプラインと同様の個々のシステムでセキュリティに対応しています。ソースコード分析、脆弱性の優先順位付け、ネットワークセキュリティ、Kubernetesセキュリティ、規制遵守、ポリシー厳守などのために、セキュリティツールとそのデータを維持・統合することは問題を「改修」する開発チームと問題の特定と解決するための最適なアプローチのために無数のデータソースとツールを扱うセキュリティチームとの間に摩擦を生じさせます。 なぜ買収を計画したのか？ Liquid Softwareのビジョンである「あらゆるソースからあらゆるデバイスへ、シームレスかつセキュアにソフトウェアが流れる」を実現するために、開発チームが最小限のノイズで、迅速かつ自動化された実用的な修復機能を備えていなければなりません。同様にセキュリティチームはアプリケーションのコンテキスト（ネットワーク構成、セキュリティ要件、オペレーティングシステムの設定など）を統合的に把握する必要があります。また、パートナーやベンダーがオープンソースや独自開発のコードに存在するゼロデイ脆弱性に対して、それがニュースになる前に発見してくれるものと信頼しています。 そのため、JFrog Xrayはコーディング、ビルド、プロモーション、デプロイなどの開発ワークフローに統合された業界最先端のスキャン機能を既に提供しています。私たちはVdooがJFrog Platformにもたらすセキュリティの包括的でインテリジェントなビューにより、これらの機能を拡張したいと考えました。これはバイナリやイメージだけではなく、バイナリが実行される環境も調査する包括的なアプローチとして、コンテキスト脅威分析や重要なセキュリティギャップに優先順位をつけるアプリケーションスキャン、コード、サービス、オペレーティングシステムの変更をカバーするインテリジェントな修復、組込みソフトウェアセキュリティ、新しい脆弱性、マルウェア、エクスプロイト、バックドア、サプライチェーンリスク、その他の脅威を自動的に検出するゼロデイ脆弱性検出、更にIoTや組込みデバイスのランタイム保護、エクスプロイトの試みをリアルタイムで警告、ブロックする機能が含まれます。 これらの新機能はソフトウェアのリリースを構成し、ランタイムに至る信頼できる唯一の情報源であるバイナリに焦点を当てるというJFrogの哲学に適応し、セキュリティ分析のための最も信頼できるものとなります。 このようにバイナリを包括的に調査し、スマートな提案を行うことでDevOpsチームやセキュリティ担当者はセキュリティリスクを修復する際の「ノイズ」が減り、調査結果に妥協せずにシフトレフトができ、これらの多くの要因の中から問題を解決するための最も適切な問題にフォーカスできるようになります。 更にVdooはJFrogが組込みソフトウェアやデバイスにより良いサービスを提供するための機能を提供し、CI/CDプロセスにデバイスセキュリティを導入するため、JFrogはこの動きで「シフトライト」します: ほとんどのベンダーができないコンパイル済みのC/C++ソフトウェアをスキャンし、これらのコンポーネントのセキュリティリスクを特定 様々な組込みLinux、Android、RTOSフォーマットをサポート アクティブなデバイスのランタイムモニタリングと保護 このソリューションは開発者にどのようなメリットがあるのか？ 開発者、DevOps組織（そして、もちろんセキュリティチーム）はJFrogとVdooのソリューションの価値をすぐに理解し、JFrog DevOps Platformの一部として、JFrogのセキュリティソリューションの適用範囲を拡大するでしょう: 統合された単一のセキュリティソリューションにより、異なる製品、データの組み合わせ、複雑な設定の維持、膨大な数の脆弱性リストをフィルタリングする必要がありません パイプラインを通して機能する包括的なセキュリティであり、DevSecOpsを単なる「スキャナー」としてだけでなく、統合されたリポジトリ、ディストリビューション、CI/CDフローの一部として機能します（例：JFrog ArtifactoryとDistributionのセキュリティ面、JFrog Pipelinesのサイン付きパイプラインなど）。これにより、統一された画面と過去の開発フェーズを可視化し、強固なセキュリティを維持しつつ、リリースサイクルを短縮してオンタイムデリバリーを可能にします 容易に理解でき、アクセス可能なセキュリティデータと修復方法の提供は開発者の時間、労力、混乱を軽減すると同時に、詳細な調査結果と専門的な緩和策のヒントを提供することで、DevOpsおよびDevSecOpsチームが自分たちで問題を解決することを可能にし、責任を持ってシフトレフトし、セキュリティを恐れるものではなく、エンジニアリングの価値として提供できます アプリケーションの完全なコンテキストを考慮した高度な優先順位付けとスキャンにより、関連性を特定するための膨大な数の脆弱性リストの中から選別する必要性を排除することで、誤検知を最小限に抑え、最も重要なことに集中することができます ゼロデイ脆弱性、マルウェア、エクスプロイト、バックドア、サプライチェーンリスク、その他の脅威を高度なスキャンとファジング手法を用いて自動検出します 安全なCI/CDパイプラインをデバイスソフトウェア作成まで拡張し、コンパイル済みC/C++バイナリの識別とセキュリティスキャンを行います 人々 JFrogの文化は何よりも重要な要素であり、企業の文化的適合性とその哲学は技術ポートフォリオと同じくらい重要視されます。Vdooにはバイナリを第一に考える同じ志を持った会社、エッジまでのセキュリティに対するパッション、開発チームやセキュリティチームのためにセキュリティの状況に革命を起こそうとする人々のマインドセットがありました。 Vdooの80人以上の従業員がJFrogに加わり、JFrogのセキュリティ・エンジニアリング・チームを直ちに強化し、高度なソリューションをより迅速に提供し、お客様により効果的にサービスを提供します。Vdooのチームには業界で最も実績のあるセキュリティ研究者やエンジニアが含まれています。このチームは新たなセキュリティリスクを発見し、軽減するための画期的な手法を発表し、その成果を積極的に提供しています。実際、彼らはこれまでに何百ものゼロデイ脅威を発見し、フォーチュン500社の企業と協力し、保護してきました。 タイムライン 2021年第3四半期には統合プロセスの第一段階として、JFrog Xray脆弱性スキャンをVdooの高度なデータを取入れて拡張し、お客様に直ちに強固な保護を提供します。第4四半期と2022年に向けて、適用性分析、組込みソフトウェアパッケージのサポート、完全に統合されたスキャン機能、ゼロデイ脆弱性のための開発者向け機能など、JFrog Platformとの更なる連携を提供する予定です。 Vdooチームへ：JFrogのセキュリティファミリーに加わることに感謝します。 Xrayチームによって築かれた素晴らしい基盤は大胆なソフトウェア・アップデートを可能にするという私たちのパッションにより、さらに大きくなります。私たちは世界中でソフトウェアが作成され、リリース方法を変えることを楽しみにしています。

Javaの依存関係を管理・整理する最もシンプルな方法はMavenやGradleリポジトリを利用することです。チーム内で共有されている依存関係を一元的に管理するためには信頼性、安全性、一貫性、効率性の高いアクセスが必要です。MavenやGradleクライアントと透過的に動作する複数のレジストリをセットアップする場所も含まれます。 JFrog Artifactory、Xray、Pipelinesを含むJFrog無料クラウドサブスクリプションでは数分で無料のローカル、リモート、バーチャルのMaven/Gradleレジストリをセットアップすることができます。ここでは、その手順をご紹介します。 始める前に 必要なものは以下の通りです。 MavenのインストールまたはGradleのインストール JFrogセルフホステッド・サブスクリプションまたはJFrogクラウド・サブスクリプション JFrog CLIのインストール ステップ1: ご自身の環境にログイン オンプレミス版の場合はデフォルトのユーザ名：admin、パスワード：password、クラウド版の場合はメールで送られてきた認証情報を使ってログインします。 ステップ2: ローカルMaven/Gradleリポジトリの作成 後述のステップで作成するカスタムMaven/Gradleを保存するために使用します。Adminモジュールに移動し、Repositoriesメニューを開き、Repositoriesメニュー項目をクリックします。 Maven/Gradleパッケージタイプで新しいローカルリポジトリを作成します。リポジトリキーとして「maven-challenge-local」または「gradle-challenge-local」を入力し、残りのデフォルト設定はそのままにします。 ステップ3: リモートMaven/Gradleリポジトリの作成 サードパーティのhttps://mvnrepository.com/をキャッシュプロキシとして使用し、データを保存します。 RepositoriesページのRemoteタブをクリックし、Maven/Gradleパッケージタイプの新しいリモートリポジトリを作成します。リポジトリキーとして「maven-challenge-remote」または「gradle-challenge-local」を入力し、残りのデフォルト設定はそのままにします。 ステップ4: バーチャルMaven/Gradleリポジトリの作成 Maven/Gradleのカスタムイメージを作成する際に使用します。 RepositoriesページのVirtualタブをクリックし、Maven/Gradleパッケージタイプの新しいバーチャルリポジトリを作成します。リポジトリキー「Maven/ Gradle」を入力し、ステップ2と3で作成したローカルとリモートMaven/Gradleリポジトリを追加します（矢印ボタンで「Available Repositories」から「Selected Repositories」に移動させます）。リスト内のリポジトリの順序はMaven/Gradleイメージの構築に必要な依存関係を解決するために使用される順序を決定します。ステップ2で作成したローカルリポジトリをDefault Deployment Repositoryとして選択します。Default Deployment RepositoryはビルドしたMaven/Gradleの依存関係がプッシュされるリポジトリです。残りのデフォルト設定はそのままにします。 ステップ5: JFrog Maven/GradleサンプルGitHub リポジトリのフォーク このリポジトリにはプロジェクトのビルドで使用するシンプルなものが含まれています。 ステップ6: JFrog CLIの設定 JFrog製品へのアクセスを自動化するシンプルなインターフェースを提供し、自動化スクリプトを簡素化するスマートクライアントのJFrog CLIを設定します。 Artifactoryサーバの設定を行います。 $ jfrog rt c 以下の手順でMaven/Gradleでプロジェクトをビルドし、Artifactoryからプロジェクトの依存関係を解決します。 プロジェクトのルートディレクトリに移動します。(cd) プロジェクトのリポジトリ設定を行います。 $ jfrog rt mvn-config または $…

数週間前にニュースになった名前空間シャドウイング、別名「依存関係かく乱」攻撃を覚えているでしょうか。JFrog Artifactoryの除外パターン機能については、その時にブログで紹介しましたが、これはずっと前からあったもので、この種の攻撃からユーザーを守るためのものでした。 この話題がニュースになったことで、除外パターン機能に注目が集まり、ビルドの安全性が高まることはもちろんですが（今も使われていますよね？）、このアプローチの欠点も浮き彫りになりました。 私たちはお客様からのフィードバックをいただきました。除外パターンは機能し、実装も簡単です。但し、内部ライブラリが小さな共通の命名パターンに準拠していない場合、多くの除外ルールを設定しなければならず、パフォーマンスに影響を与える可能性があります。これはリポジトリレベルでの管理が必要でしたが、Artifactory 7.16.3からローカルまたはリモートのリポジトリに「優先解決」フラグを立てることができるようになりました。 概要：このチェックボックスをプライベートパッケージを含むリポジトリに対して有効にした場合、Artifactoryはそれらのパッケージの新しいバージョンを検索しない。 技術的な詳細がお知りになりたい方のために、その仕組みをご説明します。 パッケージマネージャが依存関係を要求する場合、（一般的なケースでは）まずメタデータ（利用可能な全てのバージョンリスト）を要求し、次に（依存関係の定義に基づいて）どのバージョンが必要かを判断し、特定のファイルを要求します。 パッケージマネージャがArtifactoryのバーチャルリポジトリを利用するように設定されている場合、リポジトリはローカルおよびリモートリポジトリのセットを含みます。Artifactoryは以下の2つのルールに基づいて、全てのリポジトリの全てのファイルを順に解析し、クライアント用のメタデータを準備します。(1)バーチャルリポジトリで設定した解決順、(2)ローカルリポジトリは常にリモートリポジトリよりも先に問い合わせを実施。 いくつかのシナリオを考えてみましょう。 プロモーションパイプラインのためのローカルリポジトリのセットとセントラルレジストリをプロキシするリモートリポジトリがあり、これらはすべて1つのバーチャルリポジトリに含まれています。バーチャルリポジトリの設定で定義されている解決順は以下の通りです。 ローカル本番用リポジトリ ローカルステージング用リポジトリ ローカル開発用リポジトリ リモートリポジトリ リモートリポジトリをローカルリポジトリよりも上位に配置した場合でも、心配ありません。Artifactoryは常にローカルリポジトリから先に解決するように順番を入れ替えます。この設定でいくつかのシナリオを実行してみましょう。 シナリオ1: 外部依存関係のバージョンをリストアップ ユーザーが依存関係を定義した「external-package」のバージョン~1.0.0（1.0.0と後方互換性のある全バージョン、つまり2.0.0を含まない全バージョン） クライアントがパッケージ「external-package」のメタデータを1.0.0から2.0.0を含まない範囲で要求する。 Artifactoryは3つのローカルリポジトリをすべてチェックするが「external-package」のメタデータが存在しないため、検索できない。 Artifactoryはリモートリポジトリをチェックし、「external-package」（バージョン1.1.0や1.2.0など）のメタデータを検索する。 メタデータのマージは不要で検索された両バージョンを含むセントラルレジストリのメタデータが返される。 シナリオ2: 異なるリポジトリにある異なるバージョンの内部依存関係のバージョンをリストアップ ユーザーが依存関係を定義した「external-package」のバージョン~1.0.0（1.0.0と後方互換性のある全バージョン、つまり2.0.0を含まない全バージョン） クライアントがパッケージ「internal-package」のメタデータを1.0.0から2.0.0を含まない範囲で要求する。 Artifactoryは3つのローカルリポジトリをチェックし、3つのリポジトリに異なるメタデータのリストを検索（本番用にはバージョン1.1.0、1.2.0、1.3.0、ステージング用にはバージョン1.4.0、1.5.0、開発用にはバージョン1.6.0が存在） Artifactoryがリモートリポジトリをチェックし、キャッシュとセントラルレジストリに存在しないため、「internal-package」は検索できない。 Artifactoryはメタデータをマージし、バージョン1.1.0から1.6.0までの全バージョンをバーチャルリポジトリから取得するリストを作成する。 シナリオ3: 名前空間シャドウイング攻撃 攻撃者は「internal-package」の悪意のあるバージョンをバージョン1.7.0として外部リポジトリにアップロードする。 ユーザーが依存関係を定義した「external-package」のバージョン~1.0.0（1.0.0 と後方互換性のある全バージョン、つまり2.0.0までの全バージョン） クライアントがパッケージ「internal-package」のメタデータを1.0.0から2.0.0の範囲で要求する。 Artifactoryは3つのローカルリポジトリをチェックし、3つのリポジトリに異なるメタデータのリストを検出する（本番用にはバージョン1.1.0、1.2.0、1.3.0、ステージング用にはバージョン1.4.0、1.5.0、開発用にはバージョン1.6.0が含まれる） リモートリポジトリには除外パターンが定義されていないため、Artifactoryがチェックした場合、「internal-package」のメタデータが検索され、悪意のあるバージョン1.7.0がリストアップされる。 Artifactoryはメタデータをマージし、バージョン1.1.0から1.7.0までの全バージョンがバーチャルリポジトリから取得できるリストを作成する。 クライアントは最新バージョン（1.7.0）を取得し、ハッキングされる。 リポジトリに優先解決フラグを設定した場合、バーチャルリポジトリを解決する際、解決順が優先されます。リポジトリに優先順位を設定した場合、このフィールドが設定されたリポジトリからのみメタデータがマージされ、シナリオ3のステップ5はキャンセルされます（悪いシナリオ3を良いシナリオ2に効果的に変換します）。そのため、返されるメタデータには6つのバージョンしか表示されないため、クライアントは悪意のあるバージョン1.7.0のことを意識せず、それを要求することもありません。 当然、リポジトリを優先解決するように設定した場合でも（最初の例のように）アーティファクトがどのローカルリポジトリでも見つからない場合は（優先解決が未設定の場合）他のリポジトリの検索が行われます（セントラルレジストリで「external-package」を検索する）。 ほとんどの場合は優先度の設定はローカルリポジトリで行いますが、信頼できるArtifactoryインスタンス（別の開発サイトなど）をプロキシするリモートリポジトリが存在する場合もあるため、優先度の設定はリモートリポジトリでも行えます。 JFrog Artifactoryを最新版にアップグレードし、内部の依存関係があるリポジトリを「優先解決」とマークし、名前空間シャドウイング攻撃から保護することをお勧めします。内部依存関係を名前空間（または少なくとも命名規則）でスコープし、それらに除外パターンを使用することを強くお勧めします。