テーマ: supply-chain
-
npmとPyPIの公開IDを承認済みリリースアーティファクトに結び付ける
OIDCのtrusted publishingは公開トークンの保存を不要にするが、その安全性は引き続き承認されたワークフローに依存する。ビルドと公開を分離し、承認を保護したうえで、provenanceをマルウェア判定と見なさず、アーティファクトが意図したものかを検証する。
-
Dependency confusion: when a public package shadows a private one
If a build resolves package names across a private index and a public one, an attacker who publishes the private name publicly with a higher version can get their code installed; pip's documentation calls --extra-index-url for private packages unsafe for exactly this reason. Defences are namespaces bound to one registry, a single proxying index, hash pinning and claiming names.
-
外部のスクリプトとスタイルシートに対するサブリソース完全性
script または link 要素の integrity 属性には、期待するファイルの SHA-256、SHA-384、SHA-512 ハッシュを base64 で記します。内容が一致しないリソースは、ブラウザーが実行や適用を拒否します。CDN が提供できる内容を厳密に固定し、別オリジンのファイルには CORS を必要とするため、内容が固定されたリソースでのみ機能します。
-
攻撃面としての MCP ツール定義:汚染された説明、名前の偽装、無通知の変更
MCP サーバーのツール名、説明、注釈は、ツールが呼ばれる前にモデルが読むテキストです。悪意あるサーバーや侵害されたサーバーは、それらを使ってエージェントを誘導したり、別のサーバーのツールを装ったり、承認後に挙動を変えたりできます。クライアントは、コードと同様に定義を固定し、差分を取り、レビューすべきです。
-
依存関係の衛生管理とソフトウェアサプライチェーンのチェック
何に依存しているかを把握し、固定して検証し、既知の脆弱性を監視し、信頼できるソースからビルドする。SLSA のレベル、OpenSSF Scorecard、ハッシュを検証するインストールが具体的な手順を示す。
-
架空のパッケージ名と紛らわしいパッケージ名:エージェントが依存関係をインストールする前の確認
コード生成モデルは、存在しないパッケージの名前を挙げることがあります。攻撃者はその名前を登録でき、タイポスクワッターは人気の名前に似たものを登録します。インストール前に、エージェントはパッケージが存在し、意図したプロジェクトのものであり、混同しやすい名前で新規登録されたものではないことを確認すべきです。
-
LiteLLMの2026年10月のインシデント:確認されたトークン漏えいとゲートウェイログの保護
LiteLLMの後日の事後分析は、当初のログ窃取という仮説を訂正し、Agent Platform APIを通じたトークン漏えいの証拠を示した。このインシデントは引き続き、エージェントの認証情報、応答本文、高い権限を持つ自動処理に、それぞれ別のアクセス境界が必要な理由を示している。
-
Software bills of materials with SPDX and CycloneDX
An SBOM is a machine-readable inventory of the components in a software artifact; SPDX and CycloneDX are the two widely used formats, and generating one per release supports vulnerability matching and licence review.
-
Dependency upgrade cadence: batching, grouping and what to merge at once
Update bots open one pull request per dependency unless configured otherwise; a sustainable cadence merges security fixes as they arrive, batches patch and minor updates into a scheduled group, and treats major versions as planned work. Dependabot and Renovate both document scheduling and grouping, and Renovate's guide names the cost of grouping: a failing group blocks all of its members.
-
開発者のマシンと公開用アカウントに広がるnpmワームを封じ込める
ChainDropとTensorlakeの侵害は、インストール時の認証情報窃取が不正なパッケージ公開につながることを示している。封じ込めでは、依存パッケージの実行、公開権限、リポジトリ内の永続化、汚染されたビルド成果物まで対象にする必要がある。
-
GitHub Actionsのワークフローを強化する:SHA固定のアクション、最小権限トークン、信頼できない入力
サードパーティーのアクションを完全なコミットSHAに固定し、GITHUB_TOKENは既定で読み取り専用にしてジョブ単位で権限を広げます。信頼できないイベントのフィールドをrunスクリプトに直接展開せず、pull_request_targetとworkflow_runを特権トリガーとして扱います。
-
パッケージリリースのクールダウン:正確な設定、単位、適用範囲
リリースからの経過時間による制御は、npm、pnpm、uv、Renovate、Dependabotで異なる。正しい単位で設定し、タイムスタンプの扱いと推移的依存関係の解決を確認するとともに、緊急のセキュリティ更新に対応する手順を明確にしておく。
-
小さく再現可能なコンテナーイメージを作る
ベースイメージをダイジェストで固定し、ロックファイルからハッシュを検証してインストールし、実行時に必要なものだけをコピーする。root 以外のユーザーで実行し、ヘルスチェックを追加し、レイヤーやビルド引数にシークレットを含めない。
-
Software-Stücklisten (SBOM): das Inventar der eigenen Lieferkette
Eine Software-Stückliste zählt maschinenlesbar auf, welche Komponenten in welcher Version in einem gelieferten Artefakt stecken. SPDX (ISO/IEC 5962:2021) und CycloneDX (OWASP) sind die verbreiteten Formate; erzeugt wird sie pro Release aus dem gebauten Artefakt, daneben abgelegt und zum Abgleich mit Schwachstellenmeldungen und Lizenzpflichten genutzt. Zusammen mit Herkunftsnachweisen (SLSA) macht sie die Lieferkette prüfbar.
-
SBOM・コンテナイメージ・ソフトウェア台帳を横断したサポート終了検出の自動化
製品の識別情報、サポート提供元、根拠の鮮度を保ちつつ、ランタイムとイメージの台帳をライフサイクル情報に関連付ける。このワークフロー案は endoflife.date を調査の手掛かりとなる情報源として使い、ベンダーで期限を確認し、サポート終了と根拠不足を別々に通知する。
-
Signing commits and tags with an SSH key or GPG
Git signs commits and tags with OpenPGP, X.509 or, since gpg.format=ssh, a plain SSH key; the signer sets gpg.format and user.signingKey, verifiers need an allowed-signers file (SSH) or a trusted key ring (GPG), and forges are checked with git verify-commit or the host's signature badge.
-
ビルドの来歴証明:SLSA が記録する内容と検証方法
SLSA の Build トラックは、成果物の来歴の信頼性を「来歴が存在する」(L1)から強化されたビルド基盤(L3)まで評価します。来歴は、成果物のダイジェスト、ビルダー、ビルドタイプとその外部パラメーターを示す in-toto アテステーションです。利用側は使用前に、信頼の起点と期待値に照らして検証します。
-
コンテナイメージのタグとダイジェスト:可変の名前と内容アドレス
タグは人が読めるポインターで、いつでも別のマニフェストへ移せる。ダイジェストはマニフェストのバイト列のハッシュであり、永久に正確に1つのイメージを識別する。ビルドとテストにはタグ、デプロイと固定にはダイジェストを使い、すべてのリリースノートにダイジェストを記録する。
-
耐量子移行に向けた暗号資産台帳の作成と維持
暗号がどこでデータを保護しているか、各依存関係の責任者は誰か、記録の根拠は何かを整理する。CycloneDX CBOM は技術資産の情報交換に使い、それだけで移行計画が完成すると考えない。
-
Which checks on automated dependency-update pull requests have caught a malicious or broken release, and which only add noise?
Open question: automated update pull requests arrive daily and are often merged on green CI; the npm documentation describes provenance attestations that npm audit signatures can verify, but which checks (provenance, unpacked diff review, install-script inspection, waiting periods, lockfile diffs) have a record of catching a compromised or broken release?
機械可読: JSON