依存管理
このタグの記事 6 件
LiteLLM 1.107.0に認証情報を盗むマルウェアが混入（2026年10月）：対象のPyPI版・Dockerイメージと、利用者がやること
LiteLLMの開発元BerriAIは2026年10月21日（UTC）、リリースの仕組みが侵害され、認証情報を盗み遠隔でコードを実行する道具を読み込むマルウェア入りのv1.107.0が配布されたと発表した。対象はPyPIのlitellm==1.107.0（11:39〜13:23 UTC、日本時間20:39〜22:23）と、Docker HubとGHCRのv1.107.0・latest・main-latest・main-stableのタグ（Docker Hubは11:46〜14:20 UTC、日本時間20:46〜23:20。GHCRは13:51 UTC＝日本時間22:51までに取り下げ、約2時間）。GitHubの公式のソースのタグには不正なファイルは含まれず、似た名前の攻撃者のリポジトリから作られたという。それより前の版は安全で、同社は1.106.2など明示した版への固定を求めている。原因は、3人の開発者のGitHub CLIのトークンが盗まれ、ブランチ保護を外してリリースの手順を書き換えられたことだと同社は説明し、トークンは社内のLiteLLMのログから取られたとみている。社内の環境に入られた経路は確認中。当サイトの結論：期間内に入れた・起動した環境は侵害されたものとして作り直し、その環境から届いたキー（LLMプロバイダのキー、プロキシのマスターキー、データベース、クラウドの権限）をすべて変える。
osv-scanner の実務Q&A — pnpm対応・CVEの除外・オフライン実行・つまずくエラー
導入の次に出てくる実務の疑問だけを集めた。要点＝pnpm-lock.yamlは対応済み、除外は osv-scanner.toml の IgnoredVulns（期限付きで書ける）、オフラインは3つのフラグの関係を理解すれば迷わない。当サイトの考え：スキャナが知らせるのは既知の脆弱性だけで、自分で固定したバージョンが古くなったことは教えてくれない。そこは別の仕組みで見る必要がある。
Express（Node.js）のセキュリティ対策 — 本番ハードニング実務リファレンス
Expressは最小構成で、既定ではほとんどセキュリティ対策をしない。対策は開発者が自分で追加する。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝セキュリティヘッダ(helmet)＋x-powered-by無効化・依存(npm)CVE・入力検証とインジェクション(SQL/NoSQL演算子)・認証と所有者スコープの認可・レート制限とサイズ上限・セッション/Cookie/CSRF・SSRF・本番のエラー処理(スタック非露出)・NODE_ENV (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Next.jsのセキュリティ対策 — 本番ハードニング実務リファレンス
Next.jsの既定は安全寄りだが、事故は『サーバーとクライアントの境界』で起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝境界と環境変数(NEXT_PUBLIC_)・依存CVE(本体RCE含む)・Server Actions/Route Handlersの認可＋入力検証・SSRF(サーバー側fetch)・セキュリティヘッダ/CSP・認証/セッション/Cookie・レート制限 (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Ruby on Railsのセキュリティ対策 — 本番ハードニング実務リファレンス
Railsは規約と安全な既定(CSRF保護・Strong Parameters・ORM)を備えるが、本番事故は運用から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝秘密とcredentials(master key/secret_key_base)・本番設定(force_ssl・例外非露出)・gem CVE・Strong Parameters/Mass Assignment・認可(Pundit等・所有者スコープ)・インジェクションと危険メソッド(where連結/send/constantize)・セッション/Cookie/CSRF・SSRF/アップロード (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Spring Bootのセキュリティ対策 — 本番ハードニング実務リファレンス
Spring Bootは安定したフレームワークだが、事故は依存・設定・認可から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝依存CVE(Log4Shell系・実稼働版で判定)・本番設定と秘密の外部化・Spring Securityの認可(既定拒否/メソッド認可/所有者チェック)・Actuator/管理面の露出削減・安全でないデシリアライズ・インジェクション・ヘッダ/CSRF/セッション・SSRF (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。