クラウドコンピューティングの初期の頃、AWS は世界中の都市で AWS Pop-up Lofts と呼ばれる物理的なスペースで建設業者を対象とした集中学習をサポートしていました。これらのスペースは、スタートアップ起業家、開発者、およびイベント、ミーティング、共同作業で AWS についてもっと知りたいと考えている人が利用できました。最近の生成 AI の登場により、 AWS Gen AI Lofts は世界中でポップアップスタイルのコラボレーションスペースを提供し、スタートアップや開発者に没入型の体験を提供しました。 私たちは、実践的な体験、コミュニティ主導の共有、技術的なコラボレーションを通じて、学生や開発者が学び、つながり、貢献できる常設のコミュニティスペースが必要であることに気づきました。2025 年 7 月にサンフランシスコでオープンして以来、最初の AWS Builder Loft は 22,500 人以上の開発者を迎え、地元の技術コミュニティが一堂に会するハッカソン、ワークショップ、デモナイト、コミュニティ主導のイベントを開催してきました。 2026 年 8 月 18 日、ベルリン、ハイデラバード、サンパウロに新しいビルダーロフトをオープンする計画を発表しました。各場所は、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ制作スペース、コラボレーション/コワーキングエリア、イベント主催を提供する常設コミュニティスペースとなり、ドアを通り抜けたい開発者、学生、技術専門家向けに、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ作成スペース、コラボレーション/コワーキングエリア、イベントの開催が可能になります。 そこでは引き続き AWS の専門家に会うことができますが、それ以上に、 AWS User Groups や AWS Student Builder Groups 、すでに参加している独立した開発者グループまで、地域の技術コミュニティの本拠地を作りたいと考えています。テクノロジーコミュニティのリーダーとして、ミートアップを開催するためのスペースの予約を無料でリクエストしていただけます。 なぜ 3 都市なのか この拡張は、各地域の重要な人材とイノベーションの拠点である開発都市が急成長していることを反映しています。 ベルリン : AWS European Sovereign Cloud を立ち上げた後、私たちはヨーロッパの開発者コミュニティへの取り組みを深めています。ベルリンの Builder Loft は、デジタル主権に関する教育セッション、ハッカソン、セキュリティ対策ワークショップ、コミュニティミートアップを開催し、ドイツの成長を続けるスタートアップエコシステムと、より広範なヨーロッパおよび世界のテクノロジー環境をつなぐコミュニティミートアップを開催します。 ハイデラバード : Hyderabad Builder Loft は、インドの開発者に AI のスキルアップ、クラウドネイティブアーキテクチャの探求、次世代アプリケーションを構築する仲間との交流のための専用スペースを提供します。 サンパウロ : ブラジルのクラウド市場は毎年 30 % の成長を遂げており、サンパウロはラテンアメリカのテクノロジーブームの中心に位置しています。Builder Loft は、地域の開発者のハブとして機能し、地域社会、大学、スタートアップネットワークと連携して無料のプログラミングを提供します。 ビルダーロフトでの典型的な一週間 サンフランシスコの Builder Loft では、生成 AI に関する技術的なディープダイブからスタートアップのピッチナイト、学生向けのコーディングワークショップから地域全体の開発者が集まるネットワーキングセッションまで、毎週 4 〜 8 件のコミュニティイベントを開催しています。 スペースは柔軟に設計されています。火曜日の朝、トレーニングルームは 50 人以上の学生でいっぱいになります。夕方になると、スタートアップが潜在的なコラボレーターの部屋に最新のプロトタイプを披露するデモステージに変わります。週末には、コミュニティグループが独自のミートアップを開催します。 このモデルが機能する理由は、コミュニティ自体によって推進されているということです。地元の開発者、ミートアップ主催者、技術リーダーがプログラミングを形作ります。AWS はスペース、インフラストラクチャ、サポートを提供しますが、エネルギーは参加するビルダーから得られます。 今後のイベント を検索するか、サンフランシスコの Builder Loft での 独自のイベントの開催 をリクエストしてください。 ご期待ください Builder Loft は、今後のブログ記事で 3 都市でのオープンについて発表しますので、最新情報にご期待ください！ Builder Lofts の詳細を確認したり、最新情報を入手したりするには、 Rick のブログ投稿 と AWS Builder Loft のページ をご覧ください。 – Channy 原文は こちら です。

本ブログは 2024 年 1 月 26 日に公開された AWS Blog “ Export a Software Bill of Materials using Amazon Inspector ” を翻訳したものです。 Amazon Inspector は、 Amazon Web Services (AWS) ワークロードのソフトウェアの脆弱性と意図しないネットワークの露出を継続的にスキャンする、自動化された脆弱性管理サービスです。Amazon Inspector の機能が拡張され、 Windows EC2 インスタンス を除く、Amazon Inspector がモニタリングするサポート対象リソースの統合された ソフトウェア部品表 (SBOM) をエクスポートできるようになりました。 訳注: 本記事公開後の 2026 年 2 月 28 日より、エージェントレス方式でスキャンされる Windows EC2 インスタンスの SBOM エクスポートがサポートされました。エージェントベース方式の Windows EC2 インスタンスは引き続き対象外です。詳細は「 Amazon Inspector による SBOM のエクスポート 」を参照してください。 お客様からは、Amazon Inspector がモニタリングするリソースから収集したソフトウェアアプリケーションのインベントリを追加で提供してほしいというご要望をいただいていました。これにより、現在の Amazon Inspector の検出結果に関連する可能性のあるソフトウェアサプライチェーンやセキュリティ上の脅威を追跡できるようになります。SBOM を生成すると、最も頻繁に使用しているパッケージや、組織全体に影響を及ぼす可能性のある関連する脆弱性など、ソフトウェアサプライチェーンの詳細を可視化する重要なセキュリティ情報が得られます。 このブログ記事では、組織全体で Amazon Inspector がモニタリングするリソースの統合された SBOM を、 CycloneDx や SPDX といった業界標準形式でエクスポートする手順を紹介します。また、 Amazon Athena を使用して SBOM アーティファクトを分析するためのアプローチと、そこから得られる洞察についても共有します。 概要 SBOM は、ソフトウェアコンポーネントを構成する要素のリストを含む、ネストされたインベントリとして定義されます。セキュリティチームは、Amazon Inspector の AWS マネジメントコンソールにあるリソースカバレッジページから、組織全体の統合された SBOM を Amazon Simple Storage Service (Amazon S3) にエクスポートできます。 CycloneDx や SPDX の業界標準形式を使用することで、SBOM から得られる洞察をもとに、組織全体でどのソフトウェアパッケージを更新する必要があるか、他に選択肢がない場合はどのパッケージを廃止するかといった意思決定を行えます。個々のアプリケーションエンジニアやセキュリティエンジニアは、コンソールまたはアプリケーションプログラミングインターフェイス (API) の SBOM エクスポートワークフローの中で、特定のアカウント、リソースタイプ、リソース ID、タグ、またはこれらの組み合わせによるフィルターを適用して、単一のリソースやリソースグループの SBOM をエクスポートすることもできます。 SBOM のエクスポート Amazon Inspector の SBOM レポートを S3 バケットにエクスポートするには、SBOM レポートのエクスポート先となる AWS リージョンにバケットを作成して設定する必要があります。Amazon Inspector のみがバケットに新しいオブジェクトを配置できるように、 バケットのアクセス許可を設定 する必要があります。これにより、他の AWS サービスやユーザーがバケットにオブジェクトを追加できないようにします。 各 SBOM レポートは S3 バケットに保存され、指定したエクスポート形式に応じて Cyclonedx_1_4 (Json) または Spdx_2_3-compatible (Json) という名前が付けられます。また、 S3 イベント通知 を使用して、新しい SBOM レポートがエクスポートされたことを各運用チームに通知することもできます。 Amazon Inspector では、SBOM レポートの暗号化に AWS Key Management Service (AWS KMS) キーを使用する必要があります。このキーはカスタマーマネージドの対称暗号化 AWS KMS キーであり、SBOM レポートの保存用に設定した S3 バケットと同じリージョンにある必要があります。SBOM レポート用の新しい AWS KMS キーには、Amazon Inspector がキーを使用できるようアクセス許可を付与する キーポリシー を設定する必要があります (図 1 を参照)。 図 1: Amazon Inspector の SBOM エクスポート 訳注: 現在は、バージョン範囲指定などにより特定の名前・バージョンに解決できないパッケージ (未解決ハッシュ) も SBOM エクスポートに含まれるようになりました。これらのパッケージは脆弱性スキャンの対象にはなりませんが、ハッシュ値がエクスポートされたコンポーネント一覧に記録されます。 前提条件のデプロイ 提供されている AWS CloudFormation テンプレートは S3 バケットを作成し、Amazon Inspector が SBOM レポートオブジェクトをそのバケットにエクスポートできるようにするバケットポリシーを関連付けます。このテンプレートは、SBOM レポートのエクスポートに使用する新しい AWS KMS キーも作成し、Amazon Inspector サービスにキーを使用するアクセス許可を付与します。 エクスポートは、 Amazon Inspector の委任された管理者アカウント または Amazon Inspector の管理者アカウント自体から開始できます。これにより、S3 バケットには Amazon Inspector のメンバーアカウントのレポートが格納されます。同じリージョンにデプロイされた Amazon Inspector から SBOM レポートをエクスポートするには、CloudFormation テンプレートがその AWS アカウントとリージョン内にデプロイされていることを確認してください。複数のアカウントで Amazon Inspector を有効にしている場合は、Amazon Inspector が有効になっている各リージョンに CloudFormation スタックをデプロイする必要があります。 CloudFormation テンプレートをデプロイするには 次の Launch Stack ボタンを選択して、アカウントで CloudFormation スタックを起動します。 テンプレートのスタック名とパラメータ ( MyKMSKeyName と MyS3BucketName ) を確認します。S3 バケット名は一意である必要がある点に注意してください。 [次へ] を選択して、スタックのオプションを確認します。 次のページに進み、 [送信] を選択します。CloudFormation スタックのデプロイには 1～2 分かかります。 CloudFormation スタックのデプロイが正常に完了したら、スタックによって作成された S3 バケットと AWS KMS キーを使用して SBOM レポートをエクスポートできます。 SBOM レポートのエクスポート セットアップが完了したら、SBOM レポートを S3 バケットにエクスポートできます。 コンソールから SBOM レポートをエクスポートするには S3 バケットと AWS KMS キーを作成したのと同じリージョンの Amazon Inspector コンソールに移動します。 ナビゲーションペインから [SBOMs] を選択します。 フィルターを追加 して、リソースの特定のサブセットのレポートを作成します。フィルターを指定しない場合は、アクティブでサポート対象のすべてのリソースの SBOM がエクスポートされます。 希望するエクスポートファイルタイプを選択します。オプションは Cyclonedx_1_4 (Json) または Spdx_2_3-compatible (Json) です。 CloudFormation テンプレートの出力セクションにある S3 バケット URI を入力し、作成した AWS KMS キーを入力します。 [エクスポート] を選択します。エクスポートするアーティファクトの数に応じて、完了までに 3～5 分かかることがあります。 図 2: SBOM エクスポートの設定 エクスポートが完了すると、すべての SBOM アーティファクトが S3 バケットに格納されます。S3 バケットから SBOM アーティファクトをダウンロードすることも、 Amazon S3 Select を使用して標準 SQL クエリでオブジェクトからデータのサブセットを取得することもでき、柔軟に活用できます。 図 3: Amazon S3 Select 訳注: Amazon S3 Select は新規のお客様には提供されていません (すでにご利用のお客様は引き続き利用できます)。同等の処理には、本記事で後述する Amazon Athena の利用を検討してください。 また、 Amazon Athena を使用して高度なクエリを実行したり、 Amazon QuickSight を使用してダッシュボードを作成したりすることで、洞察を得たり傾向を把握したりすることもできます。 クエリと可視化 Athena を使用すると、S3 バケットに保存されている生データに対して SQL クエリを実行できます。Amazon Inspector のレポートは S3 バケットにエクスポートされます。「 AWS Glue クローラーの追加 」のチュートリアルに従って、テーブルを作成しデータをクエリできます。 AWS Glue が S3 データをクロールできるようにするには、AWS Glue クローラーのチュートリアルに記載されているロールを AWS KMS キーのアクセス許可に追加して、AWS Glue が S3 データを復号できるようにする必要があります。 以下は、ユースケースに合わせて更新できるポリシー JSON の例です。AWS アカウント ID の <111122223333> と S3 バケット名の <DOC-EXAMPLE-BUCKET-111122223333> は、必ずお客様自身の情報に置き換えてください。 { "Sid": "Allow the AWS Glue crawler usage of the KMS key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: <111122223333> :role/service-role/AWSGlueServiceRole-S3InspectorSBOMReports" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey*" ], "Resource": "arn:aws:s3::: <DOC-EXAMPLE-BUCKET-111122223333> " }, 注: AWS Glue 用に作成されたロールには、クローラーを作成するために、レポートのエクスポート先である S3 バケットを読み取るアクセス許可も必要です。AWS Glue の AWS Identity and Access Management (IAM) ロールによって、クローラーの実行と Amazon S3 データストアへのアクセスが許可されます。 AWS Glue データカタログを構築した後は、クローラーをスケジュール実行するように設定することで、S3 バケットにエクスポートされる最新の Amazon Inspector の SBOM マニフェストを常に反映した状態に保つことができます。 さらに、クローラーによって追加されたテーブルに移動し、Athena でデータを表示できます。Athena を使用すると、Amazon Inspector のレポートに対してクエリを実行し、環境に関連する出力データを生成できます。生成される SBOM レポートのスキーマは、レポート内の特定のリソース ( Amazon Elastic Compute Cloud (Amazon EC2) 、 AWS Lambda 、 Amazon Elastic Container Registry (Amazon ECR) ) によって異なります。そのため、スキーマに応じて、レポートから情報を取得する Athena の SQL クエリを作成できます。 以下は、SBOM レポート内のリソースについて上位 10 件の脆弱性を特定する Athena クエリの例です。レポートに含まれる CVE (共通脆弱性識別子) を使用して、CVE の影響を受ける個々のコンポーネントを一覧表示できます。 SELECT account, vuln.id as vuln_id, count(*) as vuln_count FROM <Insert_table_name>, UNNEST(Inset_table_name.vulnerabilities)as t(vuln) GROUP BY account, vuln.id ORDER BY vuln_count DESC LIMIT 10; 以下の Athena クエリの例では、上位 10 件のオペレーティングシステム (OS) を、リソースタイプおよびその数とともに特定できます。 SELECT resource, metadata.component.name as os_name, count(*) as os_count FROM <Insert_table_name> WHERE resource = 'AWS_LAMBDA_FUNCTION' GROUP BY resource, metadata.component.name ORDER BY os_count DESC LIMIT 10; 重大な脆弱性を持つパッケージがあり、そのパッケージがプライマリパッケージとして使用されているのか、依存関係として追加されているのかを知りたい場合は、以下の Athena のサンプルクエリを使用して、アプリケーション内のパッケージを確認できます。この例では、Log4j パッケージを検索しています。結果として account ID 、 resource type 、 package_name 、 package_count が返されます。 SELECT account, resource, comp.name as package_name, count(*) as package_count FROM <Insert_Table _name>, UNNEST(<Insert_Table_name>.components) as t(comp) WHERE comp.name = 'Log4j' GROUP BY account, comp.name, resource ORDER BY package_count DESC LIMIT 10 ; 注: サンプルの Athena クエリは、SBOM エクスポートレポートのスキーマに応じてカスタマイズする必要があります。 このソリューションをさらに拡張するには、 Amazon QuickSight を使用して AWS Glue テーブルに接続し、データを可視化するダッシュボードを作成できます。 訳注: Amazon QuickSight は 2025 年 10 月に Amazon Quick Suite へ進化 し、現在は Amazon Quick として提供されています (BI 機能は Quick Sight コンポーネントとして存続し、既存の API や連携は変更なく動作します)。また、本記事の発展形として、Lambda と Amazon EventBridge によるエクスポートの自動化からダッシュボードでの可視化までを実装した「 Enhance container software supply chain visibility through SBOM export with Amazon Inspector and QuickSight 」も公開されています。 まとめ Amazon Inspector の新しい SBOM 生成機能は、複数レベルの依存関係にわたるソフトウェアパッケージのリストを提供することで、ソフトウェアサプライチェーンの可視性を向上させます。また、SBOM を使用して各ソフトウェアパッケージのライセンス情報をモニタリングし、組織内の潜在的なライセンス違反を特定することで、潜在的な法的リスクの回避にも役立ちます。 SBOM エクスポートの最も重要なメリットは、業界の規制や標準への準拠を支援できることです。業界標準の形式 (SPDX と CycloneDX) を提供し、他のツール、システム、サービス (Nexus IQ や WhiteSource など) との容易な統合を可能にすることで、インシデント対応プロセスの効率化、セキュリティ評価の正確性と速度の向上、規制要件へのコンプライアンスの維持を実現できます。 これらのメリットに加えて、SBOM エクスポート機能は、リソース内で検出された OS パッケージやソフトウェアライブラリの把握にも役立ち、業界の規制や標準への準拠をさらに強化します。   この記事で共有した情報に関するご質問がある場合は、 Amazon Inspector re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせ ください。 Varun Sharma Varun は、セキュリティのマントを誇らしげにまとう AWS クラウドセキュリティエンジニアです。Amazon Cognito と IAM の謎を解き明かす才能を持ち、これらのサービスの頼れる専門家です。クラウドのセキュリティ確保の手を休めているときは、セキュリティペネトレーションテストの世界に没頭しています。そして画面から離れているときは、気分を切り替えて、カメラのレンズを通して自然の美しさを捉えています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

プロダクトチームの小林です。 弊社では、エンジニアの技術力向上および自主的な挑戦を推奨する取り組みとして「ひとりプロジェクト」を実施しています。これは、通常行っているペアプログラミング環境から一度離れ、1ヶ月程度で企画・設計・実装・リリースまでを1人のエンジニアが遂行する制度です。 今回は、この取り組みの中で社内ツールを開発した際、AIコーディングアシスタントが生成したSQLを過信した結果、意図しない大規模なデータ更新を発生させてしまった失敗事例と、そこから得た「AIとの付き合い方」、および再発防止策としてのシステム的なガードレール構築についてご紹介します。 発生したインシデントの概要 今回の…