1Password のログイン時、マスターパスワードは 1Password のサーバに一度も送信されていません。 少し前まで、私はこれを知りませんでした。パスワードマネージャーなのだから、当然サーバがマスターパスワードを受け取るのだろうと思っていたのです。それで暗号化された金庫を開いていると。しかし違いました。 サーバ側は「あなたが正しいマスターパスワードを知っている」ことだけを確認します。パスワードそのものは受け取りません。金庫の中身も、金庫を開ける鍵も、サーバは知らない。それでもログインは通ります。 この設計を知ったとき、UX の滑らかさとセキュリティの強さが同居する理由がやっと腑に落ちました。この記事では、その中身を「2つの秘密の鍵」と「見せずに証明する認証」という2つの仕組みで解剖します。 使いやすさに違和感を持った瞬間 はじまりは 1Password の使いやすさへの違和感でした
Per-process network monitoring for your terminal: live TCP, UDP, and QUIC connections with deep packet inspection, sandboxed by default. English | 简体中文 Real-time visibility into every connection your machine makes, who owns it, and what protocol it's speaking. No tcpdump, X11 forwarding, or root piping. Per-process attribution: Every TCP, UDP, and QUIC connection mapped to its owning process, via
最近のサプライチェーンアタックを見ていると、これまでとは明らかにフェーズが変わったと感じています。 この記事は、具体的な解決策を提示するというより、最近のサプライチェーン攻撃を見て、自分が開発環境やCI/CDについて考えていることを整理したものです。 以前の攻撃は、どちらかというとコンピュータリテラシーがそこまで高くない人を狙うものが多かったと思います。怪しいメールを開かせる、怪しい添付ファイルを実行させる、偽サイトに認証情報を入力させる、というようなものです。もちろんそれらも深刻ではありますが、少なくとも「気をつける」という個人の努力である程度防げる余地がありました。 しかし最近の攻撃は、明確に開発者を狙っています。 開発者は、一般的な業務利用者よりも強い権限を持っていることが多いです。GitHub token、npm token、SSH key、cloud credentialなどを持
on: push jobs: example: runs-on: ubuntu-latest steps: # persist-credentials 未設定 - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 # `${{ github.token }}`, `${{ secrets.GITHUB_TOKEN }}` を使用せずに # ファイル経由で GitHub トークンを抜き取る - run: | GH_TOKEN=$( cat "$RUNNER_TEMP"/git-credentials-*.config \ | awk 'NR==2 {print $5}' \ | base64 --decode \ | cut -d: -f2 ) # 最初の 10 文字だけ出力 echo "gith
📢 アップデート版を公開しました（2026/05/01） この記事のあと、3スキル体制に分割 + テストハーネスで検出率100%を達成 しました。最新の使い方は以下の記事をどうぞ。 👉 claude-security-scanを3スキル体制にアップデートしたら月$1未満で検出率100%を達成した話🎯 はじめに こんにちは、Sabakanです。 今回、Claude Code 用のセキュリティ診断スキル claude-security-scan を作って公開しました。 正直、自分でもびっくりするくらい実用的なものができたので、紹介させてください。 リポジトリはこちら → https://github.com/sabakan0123/claude-security-scan こんな気持ち、ありませんか？ 「セキュリティ診断、ちゃんとやりたいけど Burp Suite の使い方よくわからん」
TL;DR 家にあった中古 x86 デスクトップ(合計5,000円で動く状態)を Ubuntu 24.04 LTS + ヘッドレス運用で常駐化し、Claude Code CLI を tmux で 10セッション前後 常時動かしています。 TLP + thermald + powertop + カーネル起動パラメータの省電力チューニングで、idle 15〜18W / 平均運用 18〜22W に収まりました。 電気代は 月約520円(自宅の2026年3月電気料金明細から算出した実効単価 36円/kWh ベース)。 外出先からは Tailscale 経由の SSH (Shellfish) と Claude Code の /remote-control を使い分けています。どちらか片方だけでは実運用が閉じません。 sshd / ufw / fail2ban でひと通りの hardening を入れ
はじめに こんばんは、mirukyです。 2026年3月31日、npmの Axios パッケージ（週間1億ダウンロード）がサプライチェーン攻撃を受けました。攻撃者はメンテナーへの標的型ソーシャルエンジニアリングでセッションを乗っ取り、悪意ある依存 plain-crypto-js を注入した axios@1.14.1 と axios@0.30.4 をレジストリに公開しました。このパッケージは postinstall フックで多段階RATを展開し、macOS・Windows・Linuxすべてに対応する本格的なバックドアを設置するものです。影響はOpenAIのmacOS署名パイプラインにまで及び、証明書のローテーションが実施される事態となりました。 OWASP Top 10:2025でも Software Supply Chain Failures（サプライチェーンの障害）が第3位 に新設される
はじめに 本記事はサーバのセキュリティ対策として、fail2banを用いた不正アクセスを防止する方法について記載しています。 インターネット上に公開されたサーバは、アタックサーフェスとして常にスキャンや攻撃のリスクにさらされているため、手動で対応する場合は運用が大変です。 fail2banを導入することで、このような脅威に自動で対処し、運用負荷を大幅に軽減できます。 背景 筆者はGoogle CloudのCompute Engineを利用してWebサーバを運用しています。 基本的に無料枠内で使用しているため、課金は発生していませんでしたが、ある時期から課金が発生していました。原因は既に特定していて、VM インスタンスからの下りネットワークの通信が原因です。 公式ドキュメントの無料枠の使用量上限の通りにアウトバウンドのデータ量が1GBを超えたためです。 北米から全リージョン宛ての 1 GB
この記事では、弊社でサプライチェーン攻撃対策として社内にアナウンスやガイドライン化した項目の抜粋を紹介します。 昨今のSupply Chain Attackの激化、特にTrivy, LiteLLMの侵害による影響範囲の大きさを懸念し実施したものとなります。幸い直接の影響は出ていませんでしたが、どちらも社内で使っているというのあり、温度感高く対応しました。 何が起こってるの〜というのは、Flatt Securityの米内さんの記事がめっちゃわかりやすいです (本当にありがとうございます…！) SHA pinning enforcement GitHub Actionsで外部のActionを利用する場合、タグ指定(v1など)ではなくSHA(コミットハッシュ)でバージョンを固定することを求めるものです。 primeNumberでは、初回のShai-Huludのときに、主要リポジトリに対してはsu
目次ghalint / actionlintに頼る3rd party actionをできるだけ使わないSecretsにKeyを置かないやろうと思っているけど徹底できていないことRequire actions to be pinned to a full-length commit SHAの有効化branch ruleset / push rulesetghalint / actionlintを全リポジトリで回すさいごに 2026年も引き続きGitHub Actionsまわりのセキュリティ（と、それに起因するサプライチェーン攻撃界隈）は盛り上がっていて、気が抜けない。仕事とは別にして、趣味の開発で気をつけていることをさらっと共有してもいいかもな、と思い立ちこの記事を書いている。 正直この手の話題は出尽くしている感もあるし、別に何か目新しいTipsがあるわけではないのだが、仕事は別として個人と
以下の GitHub Actions ワークフローの問題点がわからない人は、お願いなので読み進めてください。 on: pull_request: jobs: example: runs-on: ubuntu-latest steps: - run: echo "PR title is ${{ github.event.pull_request.title }}" - run: echo "PR Head Ref is ${{ github.head_ref }}" 要約 run の中で直接 ${{}} を使わないでください 必要な値は環境変数を経由して渡してください Pull Request のタイトルでスクリプトインジェクションしてみる おや、こんなところに Pull Request のタイトルを出力するシンプルで完璧な GitHub Actions ワークフロー定義 YAML が落ちて
昨今GitHub上で提供されている有名なOSSに対して攻撃がなされることが多い（例: Nxの2025/08の事例）。自分もそこから学び、最低限GitHub上でセキュリティ周りの設定を入れた方が良いと考えた。 設定を考えるにあたって、とくに次の3つの記事が参考になった。 リポジトリを保護するためのクイック スタート - GitHub ドキュメント Nx の攻撃から学べること #s1ngularity | blog.jxck.io GitHub の Immutable Releases を有効にしてセキュリティインシデントを防ごう これらを参考にAIと協力して最低限のセットアップドキュメントを作ったので共有する。もっとこういう設定を入れるべきなどあれば、教えてもらえると嬉しい。 GitHub OSS セキュリティ最低限セット チェックリスト [ ] Dependabot Alertsを有効化
npm史上最悪のサプライチェーン攻撃「Shai-Hulud 2.0」。正規パッケージのメンテナー認証情報を盗み、悪意あるバージョンをnpmに公開するという手口で、11月21日から急速に拡散しました。 この記事では2つのことを解説します： 自分が被害にあっていないか確認する方法 今後の被害を防ぐ多層防御アプローチ *この記事と同じ内容を動画でも解説していますので、動画の方が好きな方は下記からどうぞ 被害確認 - あなたは大丈夫か？ Shai-Hulud 2.0は11月21日から急速に拡散しました。この日以降にnpm installを実行した人は、感染の可能性があります。 チェック1: GitHubアカウントの確認（ブラウザで完結） 確認ポイント1: 見覚えのないリポジトリ まずGitHubで自分のリポジトリ一覧を確認。 Shai-Huludは感染したアカウントにランダムな名前のパブリックリポ
iOS開発において、APIキーやFirebaseの設定情報などのシークレット情報を管理するのは重要な課題だ。多くの開発者が.envファイルを使って環境変数を管理しているが、平文でディスクに保存されるため、うっかりGitにコミットしてしまうリスクが常につきまとう。 私はArkanaを使ってシークレット情報を難読化しているが（Arkanaについての詳細は以前の記事を参照）、その元となる.envファイルの管理には課題があった。 2025年10月、1Passwordの新機能「1Password Environments」がパブリックベータとしてリリースされた。この機能を使うと、.envファイルを仮想的にマウントし、シークレット情報をディスクに書き込まずに管理できる。 本記事では、1Password EnvironmentsとArkana、Xcode Cloudを組み合わせた運用方法を紹介する。 検
こんにちは。 本記事では、アプリケーションの権限制御の実装でよく用いられる権限モデルと、それらの違いや使い所についてまとめます。 想定読者 権限モデルの種類や概要を知りたい方 RBACは実装したことがあるが、ABACは実装したことがなく、何となくだけ知っている方 ReBACは全く知らなかったのでとりあえず概要を知りたい方 →私です 前提 アプリケーションの権限制御とは、「アプリケーションが管理するリソースに対して、ある主体が行う何らかの操作を許可するか否かを判定する制御」だと考えます。 主体はユーザー単体であることもあれば、グループという形でユーザーの集合である場合もあります。 ECサイトを例にすると、以下のようなケースが考えられます。 顧客は自身の注文情報を閲覧することは許可されるが、他の顧客の注文情報を閲覧することは拒否される 顧客が商品を購入することは許可されるが、商品を作成すること
パッケージを利用する側、パッケージを公開する側でサプライチェーン攻撃を防ぐためにできることのメモ書きです。 パッケージを利用する側 npmやGitHub Actionsなどを利用する側として、サプライチェーン攻撃を防ぐためにできることをまとめます。 ロックファイルを使う npmやYarn、pnpmなどのパッケージマネージャーは、依存関係のバージョンを固定するためにロックファイル（例: package-lock.json, yarn.lock, pnpm-lock.yaml）を使用する GitHub ActionsではSHA Pinを行う pinactなどを使ったGitHub ActionsのSHA Pinを行う また、GitHubリポジトリの"Require actions to be pinned to a full-length commit SHA”を有効にする https://gi
はじめに 課題 seibiiのRuby on Railsプロジェクトではdirenvを使用し環境変数を管理していましたが、下記のような課題がありました。 1Passwordのメモに保存された .envrc を最初コピペする必要がある シークレット値がプレーンテキストで保存される Gitで管理されていないため、変更・追加の際手動での更新を個別に行う必要がある 懸念点 そこで元々社内で使っていた1Passwordを活用し、これらの課題を解決することにしたのですが、導入にあたり下記のような懸念点がありました。 単純に導入するだけだとENVを必要とするコマンドは全て op run 経由で実行する必要があり面倒。 1Passwordのクライアントアプリを使い生体認証などで保護したいが、dockerはどうすればいいのかよく分からない。 プライベートなシークレット値も1Passwordで手軽に管理したい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
