ようこそ
JFrog’s Blog

JFrogが毎年開催しているswampUp DevOpsカンファレンスでは、リキッドソフトウェアによってリリースを加速するというビジョンを推進するために、常に新しくエキサイティングな機能を提供しています。今年も例外ではなく、JFrogのCTO Yoav LandmanとCPO Dror Bereznitskyはエンドツーエンドのバイナリ・ライフサイクル管理を可能にするJFrog DevOps Platformのイノベーションを発表しました。 エンタープライズDevOpsや大規模な最新アプリケーションの配信には、アプリケーションの構成要素であるバイナリを強固に管理することが必要です。 バイナリのライフサイクル管理を大規模に改善することは企業にとって重要な課題であり、この新機能により、企業のDevOpsチームは急激に増加するバイナリ、分散チーム、複数プロジェクトの配布パイプラインを安全で効率的かつ迅速な方法でシームレスにサポートすることができます。 JFrog Platformの主たる機能の発表 JFrog Platformの新機能は企業が大規模なバイナリ・ライフサイクル管理をサポートし、エンドツーエンドのソフトウェア配布プロセス全体で開発者の生産性、効率性、セキュリティを向上するのに役立ちます。注：世界初のプライベート・ディストリビューション・ネットワークに関する重要な発表については別途取り上げています。 フェデレーテッド・リポジトリ JFrog DevOps Platformの中核であるJFrog Artifactoryの業界初の新機能であるフェデレーテッド・リポジトリはマルチサイト・トポロジでのバイナリ管理やリモート開発拠点が配布プロセスで共同作業する際、アーティファクトを同期する場合の課題に対応します。 フェデレーテッド・リポジトリはインフラストラクチャ層を抽象化し、フェデレーションの「メンバー」である異なるリモートロケーションまたはJFrog Platformの異なるインスタンス間でデータセンター透過型のリポジトリを作成します。すべての設定、メタデータ、バイナリの効率的な連続レプリケーションを含む、ロケーション間のミラーリングの自動双方向同期と高速化により、1つのサイトの開発者が行った変更が他のすべてのリモートロケーションから迅速にアクセスできるようになります。フェデレーテッド・リポジトリは設定と管理が容易で開発者の生産性、配布速度、クロスサイト・セキュリティを向上させます。 署名付きパイプライン JFrog Pipelinesの業界初の新機能である署名付きパイプラインにより、開発者はバイナリのライフサイクルを経てビルドやアーティファクトの整合性とセキュリティを確保することができます。 署名付きパイプラインはゼロ・トラストの原則に則り、パイプライン以外のものは信用できないと仮定し、CI/CDパイプラインのすべてのステップと結果を自動的に署名し、不変で改ざん不可能な記録を作成することで、ソフトウェア配布プロセスの信頼性を高めます。 これを実現するため、JFrog Pipelinesではパイプラインの実行が終了後、暗号化された署名入り台帳を作成し、書き込み不可とします。署名付きパイプラインは全てのパイプラインのアクションが認証された固有のバイナリに対して実行されていることを継続的に検証することで、開発やテストを経て本番環境に移行する際のビルドの信頼性を確保します。PipeInfoと呼ばれるこの新しいメタデータは全てのリリースにおいて検証可能なソフトウェア部品表（SBOM）を提供します。 コールドアーティファクトストレージ 現在、既存のお客様向けにベータ版を提供しているコールド・アーティファクト・ストレージは、使用していないが規制上の要件や企業ポリシーにより保管する必要のあるアーティファクトをアーカイブすることでコスト削減、使いやすさとパフォーマンスの向上を実現します。アーカイブのポリシーはバイナリのメタデータに基づいており、許可されたユーザによるセルフサービスの検索と取得が可能です。 依存性スキャン 開発の初期段階からソフトウェア・アプリケーションの信頼性を大規模に向上させるために、JFrogはGitリポジトリのソースコードから直接サードパーティの依存関係にあるOSSの脆弱性を特定する機能を導入します。JFrog Xrayと統合した依存関係のスキャンにより、開発ライフサイクルの早い段階で脆弱性を検出することができ（シフトレフト）、カスタマイズ可能な自動化されたアクションは組織のセキュリティやコンプライアンスのポリシーに基づいて実行されます（特定の危険なコンポーネントの使用をブロックする等）。この機能は第2四半期にリリースされる予定です。 プラットフォーム統合 ツールの世界に接続することは、JFrog Platformと成功するDevOpsの重要な原則です。新しいプラットフォームの統合はDevOpsのライフサイクルを通して統一されたデータと相関性のあるイベントを依存している多くのツールに提供することで、トレーサビリティとコラボレーションを可能にします。 パイプラインにおけるコラボレーション リリースを加速するために、イベント通知やセキュリティアラートをチームメンバーに知らせることが重要です。いくつかの新しい統合機能により、開発者、運用チーム、ビルド間のコラボレーションループを完成させることができます。 最新のJira Cloud統合により、ビルドとそれに対応するJiraの課題との間の双方向リンクが可能になり、JiraとJFrogの相互接続が可能となります。 Xrayで検出されたセキュリティ脆弱性用PagerDutyやCI/CD通知用PagerDutyにより新しい統合により、インシデントおよび変更管理が改良されました。 SlackとMS Teamsの新たな双方向連携（現在ベータ版）により、開発部門と運用部門のチームコラボレーションが強化されます。 エンドツーエンドの可視化性 SDLCパイプラインを最高のパフォーマンスで運用するために、いくつかの重要な質問に答えられることが必要です。例えば最もリクエストの多いアーティファクトは？最も利用されているリポジトリは？最も多いユーザは？セキュリティに関しては、どのユーザーがどのIPから実行している？ これらの答えを知るために現在、JFrogが提供しているいくつかの統合はDatadog、Dynatrace、Splunkなどの分析ツールのダッシュボードにログデータを提供します。これらの統合はJFrog Platformのアクティビティを収集し、開発戦略の改善に役立つ重要なフィードバックを提供します。 提供予定日 JFrog Platform いつ フェデレーテッド・リポジトリ 利用可能 署名付きパイプライン 第２四半期 コールドアーティファクトストレージ…

JFrog DevOps Platformの品質と機能を向上するため、特にDevSecOpsの世界では受賞歴のあるJFrog Xrayをさらに強化する強力な新機能を追加しています。 Xrayはオープンソースソフトウェアの脆弱性やライセンスのコンプライアンス違反を迅速かつ継続的に特定するために、世界中の開発者やDevSecOpsチームから信頼されているユニバーサルなソフトウェア構成分析（SCA）ソリューションとしての地位を確立しています。 ConanとC/C++サポート Xrayは業界唯一のユニバーサル・リポジトリ・マネージャであり、コンテナ・レジストリであるJFrog ArtifactoryにデプロイされたConanパッケージ、C/C++ビルドをスキャンします。ConanはC/C++言語用の依存性およびパッケージマネージャでフリーかつオープンソースであり、すべてのOSプラットフォームで動作します。また、CMakeやVisual Studioなどのあらゆるビルドシステムや独自のビルドシステムとも統合します。Conanの強力な特徴は、あらゆるプラットフォームや構成に対応したコンパイル済みのバイナリを作成・管理できることです。 XrayはConanとC/C++の主にこれら4つのユースケースをサポートしています。 ConanCenterからArtifactoryにダウンロードされたパッケージをスキャン ArtifactoryにアップロードされたConanで作成されたパッケージをスキャン Conanパッケージを構築し、XrayをCIプロセスに統合している場合、それらのConanビルドをスキャン Conanを未使用でもC++のビルドをスキャン CVSS v3サポート CVSS（Common Vulnerability Scoring System）はソフトウェアのセキュリティ脆弱性の深刻度を評価するためのオープンな業界標準です。このスコアリングアルゴリズムは悪用の容易さと影響を近似的に示すいくつかの指標を用い、セキュリティ脆弱性に深刻度のスコアを割り当てます。Xrayは以下の2つの異なるソースからスコアと深刻度を収集します。 NVD: National Vulnerability Databaseには既知の脆弱性がそれぞれのCVSSスコアとともに登録されています OS Package Security Advisory: いくつかのオープンソース・オペレーティング・システムはオペレーティング・システム・パッケージ内の脆弱性をさらに分析した独自のセキュリティ・トラッカーを保持しています スコアレンジと深刻度レベル その目的は脅威のレベルに応じた対応やリソースの優先順位を決められるようにすることです。スコアは0から10まであり、10が最も高い深刻度となります。CVSS v3では次のような深刻度の説明もあります。 Critical High Medium Low Unknown Xrayで設定したセキュリティルールはXrayのポリシーとルールの作成で説明したように違反に対するCVSS v3スコアまたは深刻度レベルに対して測定されます。Xrayは引き続きCVSS v2スコアリングをサポートしますが、CVSS v3スコアが利用できない場合にのみ使用します。 Red Hat Security Scanner認定 JFrog XrayはRed Hat Partner Vulnerability Scanner認定プログラムに統合パートナーとしてRed Hatから認定されました。認定を受けたことで、JFrog Xrayによって特定されたセキュリティ脆弱性とライセンスコンプライアンスのデータが正確であり、Red Hatパッケージに対して期待される結果と一致していることが保証され、信頼できる認定ソースに基づいた正確なリスク評価が可能になります。これは、RPMパッケージを使用している企業が自信を持って、JFrog PlatformをDevSecOpsプラットフォームとして使用できることを意味します。…

組織が大きくなると、ユーザーやグループのライフサイクルを管理することが大きな課題となります。会社は急速に成長し、新しい従業員を雇用し、組織が使用する多くのアプリケーションに対するアクセス権を与えています。つまり、従業員がチームや役割を変更したり、一時的または恒久的に退社したりする際、多くの従業員に関連するアクションが必要になります（そうしないと運用、セキュリティ、コンプライアンスの問題が発生する可能性があります）。 そのため、セキュリティやコンプライアンス上の理由から、従業員の特定のアプリケーションへのアクセスを無効にする必要がある場合が多々あります。多数の外部サービスを利用し、多くのユーザーを抱えている組織では、このプロセスに時間がかかり、エラーが発生しやすくなります。Artifactoryではユーザーやグループの作成・削除、ユーザーの無効化、ユーザーが無効化された場合のアクセストークンやAPIキーの失効などが行えます。 JFrog PlatformにSCIM v2.0のプロトコルとスキーマが追加されたことで、クラウドベースのアプリケーションやサービスのアイデンティティ・アクセス・セキュリティが格段に容易になったのは、DevOpsチームには喜ばしいことでしょう。 Scaling Software Supply Chains Securelyを読む System for Cross domain Identity Management (SCIM)はシステム間でユーザーやグループのプロビジョニングと管理を可能にするオープンスタンダードなプロトコルです。SCIMプロトコルのJFrogの実装はSCIM v2.0仕様のコアを提供しています。SCIMの実装はSCIMスキーマに準拠したRESTエンドポイントに依存しており、ユーザーやグループの作成、削除、無効化、グループやユーザー間の関連付けなど、アイデンティティプロバイダー(IdP)を介して多数のアクションを可能にします。IT部門はOktaやAzure Active Directoryなどのアイデンティティプロバイダーを利用し、JFrogのユーザーやグループを管理することができます。これにより、複数のアプリケーションにまたがるユーザーを管理するための時間のかかるプロセスを削減することができます。 SCIMプロトコルは全てのユーザー管理が一箇所に集中しているため、企業のセキュリティとコンプライアンスの地位を向上させ、アプリケーションへのアクセスはボタンをクリックするだけで簡単に無効化/有効化され、IT部門は多くの時間と労力を節約することができます。 JFrogはDevOpsの世界に不可欠な存在であるため、SCIM v2.0プロトコルをJFrog Platformに実装し、ユーザーが好きなIdPを利用してユーザーやグループを簡単に管理できるようにしました。 このブログではIdP（ここではOkta）を設定し、ユーザーを作成後、そのアクティビティを無効にする方法を3つの簡単なステップでご紹介します。 ステップ1: Access Adminトークンの生成 まず、JFrog Platformアプリケーションとの通信を認証するために使用するAccess Adminトークンを生成します。管理者としてログインし、Identity and Access > Access Tokens > Generate Admin Tokenに進みます。 作成したAccess Admin Tokenをコピーします。OktaでSCIMを設定する際に必要になります。 ステップ2: OktaでSCIMの設定 OktaのApplications > Create New Appをクリックします。ポップアップが表示された後、SCIMと統合されるSAML 2.0をサインオン方法として選択します。 アプリの名前を入力し、「Next」をクリックします。 メモ: 以下の手順に従い、OktaでSAML SSOを任意に設定してください。…

要約 私たちは皆、すべてを超高速で開発したいと思っています。そのため、「単純な」データベースの同期処理などに時間がかかる場合は既成概念にとらわれずに考え直す必要があります。ここではDBのパフォーマンスを向上し、同期時間を16時間から2時間に短縮するために、JFrog Xrayに実装したソリューションをご紹介します。 JFrog Xrayとは まず、課題とソリューションをご説明する前に、JFrog Xrayとは何かをおさらいしましょう。JFrog XrayはDevSecOpsチームのためのツールでソフトウェア・アプリケーションのオープンソース・コンポーネントを得るために使用します。JFrog Artifactoryのリポジトリに保存されているアーティファクトを再帰的にスキャンすることで、Xrayはセキュリティの脆弱性を特定し、組織のために定義されたポリシーに沿ったライセンスのコンプライアンスを保証するのに役立ちます。 現在のXrayの仕組み 脆弱性をスキャンし、ライセンスのコンプライアンスを確認するためにXrayは多くの公開されているコンポーネント、脆弱性、ライセンスを含む大きなデータベースを使用しています。初めてXrayをインストールする際、最初にDBの同期が行われ、Xrayで知られているすべての公開データをダウンロードして保存しますが、これは公開情報の中心となるナレッジベースです。 現在、このデータベースの圧縮サイズは約6GBで日々増え続けています。ダウンロードしたデータをXrayのデータベースに保存した場合、45GBのディスクスペースが必要です。このデータをPostgresデータベースに保存するために、Xrayは100MBのzipファイルを展開し、zipファイルの中にあるjsonファイルの2000個のオブジェクトを分析します。この作業には最小のシステム要件では15時間近く要していました。 * Image credit 考えられるソリューション この課題に取り組むために、Xrayチームは似たような動作をするいくつかの異なるソリューションを検討しました。1つ目のソリューションはユーザー側でデータを再作成するのではなく、既にあるデータをデータベースのテーブルとして配布することでした。この場合、ソフトウェアの一部として配布するデータの数が多くなってしまいます。もう一つの方法はコンポーネントや脆弱性に関する情報を得るためにオンラインサーバーを使用することでしたが、これには多くの時間がかかりました。3つ目の選択肢はハイブリッドなもので、余り使用されていないコンポーネントの中央データベースを用意し、共通のコンポーネントを配布するというものでした。そこで私たちは3つのソリューションを組み合わせることにしました。 調査ステップからスタート 現状を調査する為、pprofツールを使用しました。pprofはGoogleが開発したマルチスレッドアプリケーションを分析するためのgperftoolsの一部であるcpuプロファイラです。pprofにはプログラムのコールグラフを可視化するgraphvizを生成する機能が備わっています。その結果、Xrayはデータベースの操作に多くの時間を費やしていることが分かりました。以下はpprofのグラフの例です: pprofグラフの例 バッチではなく以下のようなシングルエントリーのINSERTステートメントが多数ありました: INSERT INTO table VALUES (a,b,c) 以下のように複数エントリーを一度に実施可能にも関わらず: INSERT INTO table VALUES (a,b,c), (d,e,f), (g,h,i)... 改善点1: 大きな課題はこの改善点をコードに集約することでした。そこで特定の期間やサイズを処理するための小さなキューを作成しました。 集約 goチャンネルのオブジェクトを内部で集約し、500ミリ秒毎または100オブジェクトを排除しました。 これは私たちが行った主要な改善の一つです。これまでの変更点と今回の変更点を合わせると、当初よりも約60％のパフォーマンス向上が計測されました。 初期DB同期と日次DB同期 初期DB同期を改善することが重要でした。初期状態ではDBは空で、99％のオブジェクトが追加されても更新されないことが分かっています。 改善点2: オブジェクトを検索して処理するのではなく、単純にデータを挿入する楽観的アプローチを採用しました。これにより更に数時間短縮し、パフォーマンスが少し向上しました。 しかし、日次同期は話が異なります。というのも、コンポーネントや脆弱性に関する情報を含むDBをすでに保持しており（初めて実行するわけではありません）、新しい脆弱性があれば、このDBを自動または手動で更新されるようにしたいのです。 ワーカーを利用 現在、Xrayでは以下の異なる3ワーカーが実行されています: Zipファイル・ワーカー Jsonファイル・ワーカー コンポーネント/脆弱性・ワーカー（jsonファイルのエンティティ） 改善点3: Xrayでは1つのファイル上のコンポーネントを並行して読み取るのではなく、ワーカーを使って生ファイルを並行して読み取るようにしています。ZIPファイルには2000個のエンティティをjsonで保持する100MBのファイルです。 インデックス化の削減 大量データの挿入に楽観的アプローチ（初期DB同期の為だけに追加）を採用しましたが最後に一番大きなテーブルに対して以下の方法を適用しました。 改良点4: 最大のテーブルを作成するには、コピーを使ってテーブルのデータを一括で読み込んだ後、テーブルに必要なインデックスを作成します。ご存知かも知れませんが既存のデータにインデックスを作成する方が各行の読み込み毎に更新するよりも迅速です。…

世界的な感染症の大流行により、顧客とのやり取りや取引の大部分が非接触型の世界で行われるようになったため、ソフトウェア開発はデジタルビジネスへの市場にシフトしてきています。多くの企業では開発プロジェクトの量と速度の増加を管理するため、プロセスと従業員に負担をかけています。このようなワークロードの増加に伴い、システム管理者は各開発プロジェクトのオンボーディングを適切なチームメンバー、リソース、パーミッション、閾値を用いて計測し、継続的に効率化を図るという困難な課題に直面しています。 DevOpsプロジェクトの管理と拡張 JFrog Projectsはパッケージ管理、リポジトリ、レジストリ、Helm charts、依存関係などが複雑に絡み合っている大規模企業向けに設計されている、以下のようなソリューションです: デジタルビジネスを加速させるための開発プロジェクト数が増加 新規プロジェクト作成時のプラットフォーム管理のボトルネックを解消 プロジェクトレベルでのチームメンバー、ロール、リソースのローカル管理を提供 開発チームやテストチームの新規プロジェクトへのオンボーディングを簡素化 何百、何千ものDevOpsプロジェクトがある場合、DevOps管理者がボトルネックになってしまうことがあります。JFrogは日々の業務をプラットフォームレベルから個々のプロジェクトレベルに委ねることで、ソフトウェアプロジェクトのアジリティとスケールを向上させるアプローチをとっています。 JFrog Projects – ロールベースのアクセスコントロール ロールベースのアクセスコントロール（RBAC）は企業のプロジェクト、組織、ビジネスユニット全体でDevOpsプロジェクトをスケーリングするという課題を解決します。ロールベースのパーミッションにより、例えば開発者はあらかじめ定義されたDEV（開発）環境にのみ成果物をデプロイし、PROD（本番）環境にはデプロイしないといったことが可能になります。 JFrog Projects – 設定済みのDEV環境 管理タスクをプラットフォームレベルから個々のDevOpsプロジェクトレベルに委譲することで、開発チームは事前に設定されたDEVまたはPROD環境に素早くオンボードできる為、すぐに貢献することができます。プロジェクトチームが自己組織化し、管理者がきめ細かいRBACでチームメンバーを追加し、開発から本番までのパイプラインの各段階でリソースとパーミッションを割り当てられるようにすることで、JForg ProjectsはDevOpsを拡大します。 1.0 セルフサービス JFrog Projectsは複数のソフトウェアプロジェクトに割り当てられ、それぞれの環境を手動で設定し、それぞれに適切なレベルの権限を要求しなければならないという開発者の課題を解決します。DevOpsプロジェクト管理者はDEVまたはPROD環境を事前に割り当てることで開発チームが迅速に作業に着手し、コーディングにかける時間を最大化することができます。 また、ソフトウェア開発者は割り当てられたリソースを使って新しいプロジェクトを開始することができ、オンボーディングを簡素化して迅速にコーディングを行うことができます。あらかじめ定義されたDEVまたはPROD環境ではパッケージマネージャー、アーティファクト（イメージ、依存関係など）、ビルド、パイプライン、グローバル検索などの標準的なツールセットが用意されています。 DevOpsプロジェクト管理者の場合、次のスクリーンショットでは「Trading Floor」というプロジェクトが取り上げられています。このTrading Floorプロジェクトには1人のProject Admin、3人のDeveloper、3人のContributor、7人のViewer、3人のRelease Managerがおり、3つのリポジトリと1つのパイプライン統合が事前に設定されているため、チームはすぐに開始することができます。 JFrog Platform – 新ProjectのAdmin表示 2.0 ソフトウェアプロジェクトを容易に管理 クラウド・ファースト・アプリケーションとマイクロサービス・アーキテクチャがスケールのための最新のパターンになるにつれ、SDLCへの影響の1つは各マイクロサービスが独自のコードベースを持ち、独立してデプロイ、アップグレードまたは置換できるため、ソフトウェア・リリースの速度が速くなることです。 このようなライフサイクルの高速化をサポートするためにDevOpsプロジェクト自体がよりアジャイルで自律的なものとなり、開発チームが迅速にコーディングを開始するために必要なリソースを迅速に投入する必要があります。 JFrog Projectsは分散した開発プロジェクトのスケーリングの課題を解決します: 新しい開発プロジェクトの設定、チームメンバーやリソースの割り当て、ストレージのクオータ設定等をシンプルなUIで容易に実施可能 共通プラットフォーム設定を使用し、プロジェクトレベルのデータ分離と異なるプロジェクト/チーム/部門間の情報へのアクセスに対するコンプライアンスを確保 拡張された管理UIにより、容易に新しいロールベースのアクセスとパーミッションの設定が可能 グローバルにリソースを管理する権限と特定のプロジェクトのためのプロジェクト管理の権限を持つ新たに導入されたPlatformとProject管理ロール Viewer, Contributor, Developer, Release Manager等の追加のプロジェクトロールとパッケージ、ビルド、アーティファクト、パイプライン、CI/CD DevOps pipelines全体のグローバル検索などのリソースのCRUDパーミッション JFrog Platform –…

JFrog Cloud EnterpriseまたはEnterprise+サブスクリプションをMicrosoft Azureで利用する場合、当然ながらセキュリティとユーザー管理のためにAzureが提供するサービスを有効に活用したいと考えるでしょう。 DevOpsのセキュリティは誰がビルド、リリース、自動化処理にアクセスできるか、から始まります。JFrog DevOps Platform on Azureはミッションクリティカルな開発パイプラインへの安全なアクセス許可のための窓口として、ユーザー資格情報を管理するAzure Active Directoryと容易に統合することができます。 SSOとSAML 企業では様々なソフトウェア・サービスを利用して業務を遂行していますが、それぞれのサービスに対して個別に認証情報を管理することは負担になります。シングルサインオン（SSO）を利用した場合、管理者は各ユーザーに個別の権限を与えて、使用が許可された一連のサービスにログインさせることができ、企業全体の認証情報は1つだけで済みます。 この目的のためのオープンスタンダードの1つであるSAML（Security Assertion Markup Language）はAzure Active Directoryなどのアイデンティティプロバイダー（IdP）が中央で承認済みの認証情報をJFrog DevOps Platformなどの他のサービスに渡し、SSOユーザーエクスペリエンスを実現します。 JFrog EnterpriseおよびEnterprise+サブスクリプションでJFrog PlatformはSAML SSOをサポートしており、クレデンシャル管理のためにAzure Active Directoryと統合することができます。 SSOのセットアップ JFrog PlatformとAzure Active Directoryを統合してシングルサインオンを実現する場合、以下の2つを実施します: JFrog ArtifactoryをAzure Active Directoryの管理対象SaaSアプリのリストに追加します。 JFrog PlatformでSAML SSOを設定します。 マイクロソフトが詳しいチュートリアルを提供しています。SAMLの設定に必要なものは以下の通りです。 Azure Portal Azure MarketplaceでJFrog Artifactoryアプリケーション統合を取得し、JFrogのSaaSサブスクリプションを追加します。 IdPおよび/またはSP Initiatedモードでアプリケーションを構成するBasic SAML Configurationを編集します。 For IDP Mode In the Identifier…

チームやサイトで使用されているすべてのオープンソース（OSS）コンポーネントの安全性を確保する最も簡単な方法はソフトウェア構成分析（SCA）ツールを利用することです。オープンソースの使用状況を管理・把握するためには自動化された信頼性の高い方法が必要です。 JFrog Xrayはソフトウェア開発ライフサイクル(SDLC)に脆弱性とライセンスコンプライアンスのスキャンを設定することができます。オンプレミス、クラウド、ハイブリッドで利用可能なXrayは企業のソフトウェア・コンポーネントを相互に接続して可視化し、脆弱性やライセンス問題のない迅速なリリースを実現します。このブログ記事で、その手順をご紹介します。 始める前に 必要なものは以下の通りです: JFrog Cloudサブスクリプション（無償のクラウド版とセルフホスティッド版を含む） ステップ1: あなたの環境にログイン オンプレミス版の場合はデフォルトのUsername: admin、Password: password、クラウド版の場合はメールで送られてきた認証情報を使ってログインします。 ステップ2: 選択したリポジトリでJFrog Artifactoryをセットアップ 過去の記事でプライベート、リモート、バーチャルDockerレジストリを設定する方法をご紹介しています。 ステップ3: Policyの定義 Policyはセキュリティおよびライセンスコンプライアンスの仕様を定義するものです。組織のニーズに合わせて強制するルールや適用する自動アクションを定義します。 ApplicationモジュールからSecurity & Compliance > Policiesをクリックします。 タイプが「Security」の新しいPolicyを追加します。新規ルールをクリックし、「All Severities」に設定します。 注: 新たなセキュリティ問題が見つかった場合に実行する自動アクションを定義することもできます。例えばWebhookのトリガー、メールでの通知、ダウンロードのブロック、ビルドの失敗などです。何も有効になっていない場合は単にWeb UIに情報が表示されるだけです。 ステップ4: 監視するリポジトリを選択し、PolicyをWatchに割り当てる Watchはアーティファクト・リポジトリとビルドなどの監視するリソースの範囲を定義します。ここでは新しいWatchを作成し、先ほど作成したPolicyを適用します。 ApplicationモジュールからSecurity & Compliance > Watchesをクリックし、新しいWatchを追加します。 Add Repositoriesをクリックし、このWatchに含めるリポジトリを選択します。 リソースが選択されたため、Policy自体を作成することができます。 Manage Policiesをクリックし、前のステップで作成したPolicyを選択します。 ステップ5: スキャンを実行 Watch作成後、スキャンがトリガーされるイベントが発生した場合、指定されたリソースのアーティファクトをスキャンし、それに応じて違反を報告します。 しかし、スキャンのトリガーとなるイベントが起こるまで（新しいアーティファクトがリポジトリにプッシュされるなど）、システム内にすでに存在するアーティファクトはWatchによってスキャンされません。そこで、関連するアーティファクトにWatchが直ぐに適用されるようにするために、手動でWatchを起動することができます。 先ほど作成したWatchにカーソルを合わせ、Apply on Existing Contentを選択します。 Watchに割り当てられたリソースの内、どのリソースをスキャンするかを指定し、スキャンするためにターゲットにアーティファクトが存在する必要がある時間を定義する日付範囲を指定します。 例えば「Last 90 days」を選択した場合、過去90日間にターゲットに存在していたアーティファクトのみをスキャンします。 注:…

TL;DR JDK（Java Development Kit）14では自己完結型Javaアプリケーションをパッケージングするものとして、Javaツールキットにインキュベーション機能が追加されました。新しくリリースされたJava 16ではこの機能が製品化されています。 異なるプラットフォーム用のコンパイルについて考えると震えるという方、私にはその気持ちがよくわかります。Javaの約束の1つであるWORA（Write Once, Run Anywhere）原則はプラットフォームの独立性に革命をもたらしたものの、もう1つのステップである「どこにでもデプロイできる」ことには至りませんでした。個人的にWORADAは素晴らしいと思いますが、Dockerの登場以前「自分のマシンでは動くのに」問題をなくすのは自分のマシンを出荷するのと同じくらい面倒なことだと思われていたのではないでしょうか。 つまりあなたはクラスを書き、jarファイルを作り、正しいJVM（またはJDK）とすべての依存関係を必要とし、動かすために特殊な作業を行ってきました。この知識が開発サイロから運用サイロに一貫してそのまま送り届けられることは可能なのでしょうか？ 「自分のマシンを出荷する」コンテナ革命 コンテナですべてが変わりました。過去数年間「Javaアプリケーションのデプロイに非常に苦労している」という苦情に対して、「少なくともJavaだとすべてのプラットフォームで動作するけど、他はそれさえもできない」と答えていましたが、Dockerとコンテナの台頭により「少なくともマルチプラットフォームである」という議論は水の泡となってしまいました。マルチプラットフォームのサポートは（ターゲットプラットフォームを出荷するので）突然それほど重要ではなくなりましたが、アプリケーション全体を含むパッケージを持つことが勝者となったのです。 ネイティブなJavaアプリケーションのインストーラー・ジェネレーター、jpackage Docker JEP 311（Java Packager API & CLI）の最初のリリースからわずか4年、ついに日の目を見ました。そのアイデアは古くて放置されていたjavapackagerツール（その目的は「Antタスクの代替として使用されること」でした--Oracleの公式ドキュメントからの引用です、冗談ではありません！）をクリーンアップし、文書化し、適切なAPIを提供し、Java開発者が適切なインストーラを作成できるようにすることでした。そして、JEPの343と392: Packaging Toolに置き換えられました。パッケージングツールはJava 16のリリースできれいに書き直され、素晴らしいものになりました。ご覧ください。 $ jpackage create-installer --runtime-installer \ --name --output outputdir これですべて（アプリ、依存ファイル、JRE、Kitchen sink）を含むインストーラー（.msi/.exe1、.dmg、.deb/.rpm）を作成したことになります。 すべて？それは言い過ぎでは？ 本当にそうなのです。しかし、実際にはすべてをパッケージングする必要はありません。以下のようなコマンドで自分のアプリケーションだけの実行ファイルを作成します。 $ jpackage --name myapp --input lib --main-jar main.jar \ --main-class myapp.Main このパッケージにはmyappと呼ばれるアプリケーションのランチャーが含まれています。アプリケーションを起動するために、ランチャーは入力ディレクトリからコピーされたすべてのJARファイルをJVMのクラスパスに配置します。 JREはどこへ行った？ でも…JREを除外したことで、目的を達成できなかったのでは？はい、そうなのです。JREを含むけれどもすべてではない、という間を取ったやり方を見つけましょう。jlinkコマンドを使って、本当に必要なモジュールだけを含むJREのサブセットを作ることができます。 $ jlink --add-modules java.base,java.sql --output smalljre…

要約 セルフホステッド版のDockerのレート制限、違反の抑止、新しいパッケージタイプのサポートなどの最新情報をご紹介します。 2020年は間違いなく最近の歴史の中で誰にとっても最も困難な年の一つでしたが、特にDevOpsの世界の人々にとってはそうでした。JFrogは同じペースで開発と革新を続け、お客様にさらに優れたエンド・ツー・エンドのDevOps体験を提供し、お客様がオンタイムのリリースを維持できるように努めてきました。 JFrog Platformに導入された新機能を詳しくご紹介します。 セルフホスティッド版のユーザのDockerレート制限 ご存知のように、Docker社はDocker Hubから取得されるコンテナイメージに対して、消費量に応じた制限を発表しました。具体的には匿名のフリーユーザは100回/6時間、認証されたフリーユーザは200回/6時間に制限されます。 JFrogとDockerのパートナーシップにより、無料サブスクリプション（AWS、GCP、Azureで利用可能）を利用するユーザーを含む、JFrog DevOps PlatformのクラウドユーザーはDocker Hubのイメージ取得制限はありません。 JFrog ArtifactoryでDocker Registry機能はDocker社が発表した最新のレート制限の変更に対応するため、以下の機能を最適化しています: HEADリクエストを使用 新しいデフォルトの検索用キャッシュ期間 強化されたログとメッセージ ダイジェストヘッダー（Docker Content Digest）を使用 ライセンス違反や脆弱性への対応 JFrog Xrayレポートはオープンソースパッケージ、ビルド、アーティファクトのXrayスキャンの結果を優先順位付けし、対策を講じることができます。各レポートは特定の時点でのOSSリスクのスナップショットを提供し、視覚的に分かりやすい方法で情報を表示します。 レポートの範囲は脆弱性のあるコンポーネント、影響を受けるアーティファクト、スキャン日、CVE ID、CVSS深刻度スコアでフィルタリングできます。また、修正を目的とし、「すべての脆弱性」、「修正プログラムがあるもの」、「修正プログラムがないもの」を表示するようにレポートすることもできます。 JFrog Xrayレポート レポートの種類 レポートは以下の通りです: 脆弱性レポートはアーティファクト、ビルド、ソフトウェアリリース（リリースバンドル）に含まれる脆弱性に関する情報、脆弱性のあるコンポーネント、CVEレコード、CVSSスコア、深刻度などの基準を提供します。 ライセンス・デュー・ディリジェンス・レポートは全てのコンポーネントとアーティファクトに関連するソフトウェア・ライセンスを提供し、使用しているコンポーネントとアーティファクトが企業のライセンス・ガイドラインに準拠しているかどうかを確認することができます。各コンポーネントに関連するすべてのライセンスタイプと不明なライセンスや認識できないライセンスが一覧表示されます。 違反レポートでは選択したスコープで見つかった各コンポーネントのセキュリティとライセンスの違反に関する情報を提供します。違反の種類、影響を受けるコンポーネント、アーティファクト、深刻度などが含まれます。また、そのスコープは高度なフィルターで定義されます。 Xrayレポートの特徴の一つに、脆弱なコンポーネントのインパクトパスがあります。コンポーネントは1つのビルドイメージ内の複数の場所に現れたり、複数のビルド内に現れたりします。Xrayは脆弱性のあるコンポーネントがソフトウェアに影響を与えるすべての場所を表示します。 脆弱性レポート例 レポートのパーミッション管理 この新機能をサポートするために、JFrog Platformに新しいパーミッションロールが追加されました。このロールはレポートの作成、編集、共有できる権限設定を可能にし、個々のユーザまたはグループレベルで割り当てることができます。 セキュリティ違反抑止の管理 JFrog Xray Ignore Ruleは不要な違反ノイズをフィルタリングするためにセキュリティ違反ルールをホワイトリスト、無視、承認することができます。ルールは以下のような理由で異なるチームやユーザーが無視することができます: すでに脆弱性を認識しているが、安全性を保つことができる場合 お使いの環境が違反の条件を満たしていない場合 脆弱性が致命的でなく、後で処理すれば問題ない場合 重要でない違反によりビルドやダウンロードが失敗してしまう場合 JFrog XrayのIgnore Ruleの設定 Ignore Ruleの粒度 Ignore Rule機能は幅広い柔軟性と粒度の高さを備えており、脆弱性/ライセンス、コンポーネント、アーティファクト、Watchに基づいて違反を無視することができます。そのため、無視したい内容を非常に細かく設定することができます。例えば特定のコンポーネント、特定のライセンス、特定のコンポーネントのバージョン番号などを設定することができます。 時間による無視…

マイクロサービスはアプリケーションの構築方法を変えました。ソフトウェア設計は大規模なモノリシックなアプリケーション（変化や改善に適応できない）から、アジャイルな世界の変化に適応する小規模で独立したプロセスのインフラストラクチャの集合体へと移行しています。 マイクロサービスはどのように通信するのか？ マイクロサービスは互いに分離していますが通信できなければなりません。マイクロサービスのインフラストラクチャ内で通信を行う場合、最もポピュラーな1つが非同期通信です。 同期通信では他のタスクに移る前にレスポンスを待つ必要がありますが非同期通信ではマイクロサービス間でメッセージを送信し、他のタスクで作業を続けることができます。また、このアプローチは各マイクロサービスの独立性を高めることにもなります。マイクロサービスが停止した場合、障害を受けたマイクロサービスが再び稼働するまでタスクは保留されるため、他のサービスに影響を与えることはありません。非同期通信の最も良い例の一つが電子メールです。電子メールを送信した後、送信者は他の作業を継続でき、受信者が電子メールを読むまでの間、送信者は返信に頼らずに作業を継続することができます。 非同期通信の実装方法はメッセージキュー（宛先サービスがビジーな状態であったり、利用できない間に待機しているすべてのメッセージのための一時的なストレージ）を使用することで実現できます 。メッセージキューイングの基本的なアーキテクチャは非常にシンプルでプロデューサとコンシューマを使って実現します。プロデューサはメッセージを作成してキューに送信するアプリケーション/サービスです。コンシューマはキューに接続し、処理するメッセージを取得します。 メッセージキューイングを実装するためにプロデューサからメッセージを受け取り、コンシューマに渡すにはサービスのメッセージブローカーが必要です。メッセージはキューに直接公開されません。その代わりにプロデューサはメッセージを異なるキューにルーティングする交換機に送ります。メッセージはプロデューサに処理されてキューから削除されるまで存在します。 JFrog Xrayの場合 JFrog Xrayには主に2つの作業フローがあります: データベースの同期化 –  VulnDBなどのプレミアムリソースからのデータを含見ます。JFrogが管理するグローバルな脆弱性データベースサーバから問題と脆弱性に関するデータを毎日自動的に取得します。また、エアギャップ/DMZ環境では手動によるオフラインモードも可能です。 リソースのインデックス化 – インデックス化されたリソース内のコンポーネントに違反や脆弱性をインデックス化してマッチングします。 このフローは新規と既存コンテンツの2つのフローに分けられます。 Xrayではマイクロサービス間の内部通信はすべて非同期でRabbitMQメッセージブローカーを使用して管理します。 注: JFrog Xrayをすでにお使いですか？JFrog XrayのRabbitMQの詳細はこちらの記事をお読みください。 JFrog XrayがRabbitMQを使用する方法 Xrayはスキャン、インパクト分析、データベース同期など複数の重要な役割があります。これらの役割には異なるXrayサービスで同時に処理する必要があります。XrayはRabbitMQを使用してサービス間の通信を確認しながら、異なる処理を管理します。 RabbitMQはXrayで主に3つのタイプのキューを管理しています: 新しいコンテンツ – システムに追加された新しいコンテンツに関連するイベントを処理します。例えばインデックス化するリポジトリに新しいアーティファクトがアップロード後にインデックスキューにメッセージが作成されます。 既存コンテンツ – システム内の既存コンテンツを処理します。例えばリポジトリを再インデックス化後にこのキューにメッセージが送信されます。 リトライ – 失敗したメッセージはこのキューに送信され、TTLの間はそこに留まります。TTLの経過後、メッセージは元のキューに戻されます。 キュー名はサービス名とキュータイプによって定義されます（新しいコンテンツのキュー名にはサフィックスがありません）。この命名規則によってキュー名が予測できるため、RabbitMQキューをデバッグする際に便利です。 XrayのメインフローでのJFrog Xrayキュー ワークフローを独立したキューに分離するアプローチはメッセージキューの負荷を削減し、より効率的な機能を提供します。 各Xrayマイクロサービスは「ワーカー」と呼ばれるコンシューマ数の設定を可能にしています。特定のキューに対するワーカー数を増やしたり、新しいXrayインスタンスをクラスタに追加したりすることで、ワーカーのスケールアップが可能です。各サービスのワーカー数を個別に調整することで、集中度の低いサービスには比較的少数のワーカーを割り当て、より必要とされるところでインスタンスリソースを利用することができ、Xrayのパフォーマンスを最適化することができます。     試してみてください JFrog XrayはRabbitMQメッセージブローカーを使用して内部のマイクロサービスの非同期通信を行い、堅牢性とスケーラビリティを向上させています。 DevSecOpsを向上しつつ、この独立した非同期通信ベースのソフトウェアを体験してみませんか？Xrayを無料で使ってみましょ