テーマ: security
-
TLS証明書の有効期限を、メインのウェブサイトだけでなく全エンドポイントで監視する
有効期限切れの証明書は、発生時刻を正確に予測できる障害である。実際に配信されているすべての証明書(ウェブ、API、メール、社内パネル、ロードバランサー)のnotAfter日付を外部からプローブし、手動更新に十分なリードタイムを持ってアラートを出し、リーフ証明書だけでなく中間証明書も確認する。
-
TLS 接続で X25519MLKEM768 が実際に選択されたかを確認する
ブラウザーの接続詳細、OpenSSL、curl、サーバー側の記録を使い、耐量子機能の導入状況と、実際の TLS 接続で選択されたグループを区別する。
-
監査ログ: 何を記録し、どう改ざんから守り、誰が読めるようにするか
監査ログは、誰が・いつ・何を・どのオブジェクトに対して行い・その結果はどうだったかに答える。アプリケーションがセキュリティ上重要なすべての操作について書き出し、デバッグログとは別に保管し、追記専用または一度書き込んだら変更できないストレージへ速やかに移すことで改ざんから守り、記録され制限されたアクセスのもとでのみ読み取れるようにする。
-
LinuxカーネルのKEV対応:各CVEをディストリビューションのパッケージと稼働中のカーネルで確認する
悪用された5件のカーネル脆弱性を個別に追跡する。ディストリビューション別の修正パッケージを使い、起動したカーネル、または明示されたライブパッチの対応範囲を確認する必要があり、あるサブシステムの緩和策で他の問題まで解決するわけではない。
-
シークレットをコミットしたら:ファイル削除だけでは足りない理由と対応の順序
Git リポジトリへ push した認証情報は、履歴、フォーク、クローン、キャッシュ、CI ログに残ります。履歴の書き換えは今後の露出を減らせてもコピーは回収できないため、まず認証情報を失効・ローテーションし、次に履歴を整理し、使用状況を確認します。
-
Unix のファイル権限と umask
各ファイルには所有者・グループ・その他の読み取り、書き込み、実行の権限ビットと、setuid、setgid、sticky ビットがある。新規ファイルの権限にはプロセスの umask が使われる。秘密情報は 0600 のファイルに置き、ディレクトリをたどるには実行権限が必要で、サービスは専用ユーザーで動かす。
-
System Integrity ProtectionとSigned System Volume:保護の対象と無効化すべきでない理由
SIPはrootでも保護されたシステムパスやプロセスを変更できないよう制限します。Signed System Volumeはシステムボリューム全体を暗号学的に封印し、起動のたびに検証します。この2つにより、/usr/localに書き込めても/usrには書き込めない理由と、権限エラーの正当な解決策としてSIPを無効化すべきでない理由が分かります。
-
サービスを守り、クライアントに伝わるレート制限の設計
検証できる識別情報、例えばアカウントやネットワークプレフィックスごとに制限する。固定窓またはスライディング窓で原子的なカウンターを使い、429と Retry-After を返す。読み取り、書き込み、登録の枠を分け、実効的な制限を公開する。
-
Sudo policy as drop-in files in /etc/sudoers.d, checked with visudo -c
Adding a scoped rule as its own file under /etc/sudoers.d, validated with visudo before it takes effect, keeps sudo policy auditable and avoids a syntax error locking everyone out. This methodology also covers the risk of broad NOPASSWD rules and where sudo logs its decisions.
-
npmとPyPIの公開IDを承認済みリリースアーティファクトに結び付ける
OIDCのtrusted publishingは公開トークンの保存を不要にするが、その安全性は引き続き承認されたワークフローに依存する。ビルドと公開を分離し、承認を保護したうえで、provenanceをマルウェア判定と見なさず、アーティファクトが意図したものかを検証する。
-
File upload service walk-through: direct-to-storage tickets, asynchronous scanning and quotas
A design walk-through for uploads that bypass the application servers: a ticket that reserves quota and returns a signed upload URL, a completion step that verifies the stored object, a scan worker that promotes or deletes it, lifecycle rules for abandoned uploads, and a status model that explains every stored object.
-
出力時のエンコードでクロスサイトスクリプティングを防ぐ
データを挿入する実際の文脈に合わせてエスケープする。対象は HTML テキスト、属性、JavaScript、URL、CSS である。標準でエスケープするテンプレートを使い、文字列連結で HTML を組み立てず、厳格な CSP で補強する。
-
Cisco Secure Email GatewayとSD-WAN Manager:修正の確認と侵害の証拠保全
メールスキャナーとSD-WAN Managerの対処記録は個別に管理する。実際にインストールされた修正を確認し、状態を変える復旧作業の前に証拠を保全したうえで、製品ごとの調査手順に従う。
-
Short-link services with sequential identifiers receive more enumeration requests than services with random identifiers
Hypothesis: a URL shortener whose keys are a counter encoded in base62 lets anyone walk every link, whereas random fixed-length keys make most guesses miss; the proposal is that sequential services see a higher share of requests for existing keys from clients that never received the link, and that the share of 404 responses does not distinguish the two.
-
製造者のCRA脆弱性対応フローを整備する:受付、証拠、報告期限の管理
脆弱性の受付と構成要素の記録をCRAの報告判断につなげる準備手順案である。2026年にすでに適用されている報告義務と、2027年12月に適用される、より広範な脆弱性対応要件を区別する。
-
The Standard Webhooks spec versus Shopify's HMAC header and GitLab's shared-secret token
The Standard Webhooks specification defines webhook-id, webhook-timestamp and webhook-signature headers, a whsec_-prefixed base64 secret whose decoded bytes are the HMAC key, and a v1,<base64> signature over "{id}.{timestamp}.{payload}"; GitLab's signing tokens (GitLab 19.0, generally available in 19.1) implement exactly this. Shopify instead sends a base64 HMAC of the raw body in X-Shopify-Hmac-SHA256, and GitLab's older X-Gitlab-Token is a plain shared secret, not an HMAC at all.
-
Verifying installed RPM packages for tampering with rpm -V
rpm -V compares installed files against the checksums, permissions and ownership recorded when the package was installed, and its single-letter output codes say exactly what changed. This methodology covers reading that output and its limits as an integrity check.
-
同一オリジンポリシー:オリジンの定義と隔離する対象
オリジンは URL のスキーム、ホスト、ポートからなる。スクリプトは同一オリジンの文書、ストレージ、応答を読み書きできる。別オリジンからの読み取りは既定で拒否されるが、フォーム送信などの書き込みや、画像・スクリプトの埋め込みは通常許可される。CORS は読み取り制限を緩めるが、CSRF 対策は引き続き必要である。
-
After a vulnerability report arrives: acknowledge, assess, fix in private, disclose
Once a report reaches the project's security contact, the work is a sequence with dates: acknowledge quickly, classify (working as intended, bug, feature request, vulnerability), agree an embargo with the reporter, develop the fix privately, obtain a CVE identifier, then release and publish an advisory that names affected and fixed versions and credits the reporter. The OpenSSF maintainer guide and GitHub's disclosure guidance describe this process; this article compresses it for a project with one to five maintainers.
-
エージェントの操作をサンドボックス化する:ファイル、ネットワーク、認証情報の境界
コマンドやコードを実行するエージェントは、触れられるファイル、到達できるホスト、読める秘密情報を制限する境界内で動かすべきである。capabilities の削除と seccomp プロファイルを備えたコンテナ、gVisor などのユーザー空間カーネル、既定で拒否するネットワーク、範囲を絞った短寿命の認証情報が構成要素になる。
機械可読: JSON