govulncheckで行う脆弱性対応 はじめに 開発本部でデリッシュキッチンプレミアム会員向けの開発を担当しているhondです! 先日axiosのサプライチェーン攻撃が話題になりました。axiosのリードメンテナのnpmアカウントがソーシャルエンジニアリング経由で侵害され、悪意のあるバージョン(1.14.1と0.30.4)が約3時間npmに公開されていたというもので、詳細はaxios公式のPost Mortemにまとまっています。広く使われているHTTPクライアントが直接狙われた事件で、エコシステムに依存する側としても他人事ではないなと感じました。 これを受けて、普段業務で利用しているGoではどのような脆弱性対策が取られているのか、また開発者としてどのような運用が推奨されているのかを改めて確認しました。結論として、Goではサプライチェーン攻撃自体はgo.sumとChecksum Data
はじめに Go 1.24 以降で HTTPS サーバーを動かしているなら、すでに耐量子暗号が効いてるらしい。 何も設定していないのに。 耐量子暗号という響きがかっこよく、このテーマで記事を書こうと思いたち、2024年も4月にタイトルとリンクだけ張っただけで放置してからはや2年。 気を取り直して最新の状況を確認しようと思ったら、Goのマイナーバージョンは2つも進んでいました。 こんな感じで自分でも深堀りしたいテーマが数多く、Zennの下書き状態で眠り続けています。早く起こさねば…。 というわけで、PQC(Post-Quantum Cryptography:耐量子計算機暗号)が「研究」から「我々のサーバーのデフォルト設定」になるまでの話と、実際に動いているかどうかを確かめてみた記録を残します。 TL;DR 2024年8月、NIST(米国国立標準技術研究所)がPQCの標準アルゴリズム(ML-KE
Cal.com have announced they’re closing their codebase and will no longer be an open-source product. Their reasoning is that AI has made open source too dangerous for SaaS companies. Code gets scanned and exploited by AI at near-zero cost, and transparency is now becoming exposure. I understand where this is coming from; the industry is changing fast. New AIs with new cybersecurity capabilities are
You can now receive Dependabot alerts when your repositories depend on npm packages with known malicious versions. When you enable malware alerting, Dependabot matches your npm dependencies against malware advisories in the GitHub Advisory Database. How it works Opt-in enablement: Enable malware alerting via a new toggle in your repository, organization, or enterprise security settings alongside y
@satetsu888 です。最近AIエージェントで開発が高速化した結果、作った機能の動作確認が間に合わなくなっていく感じがしているので、QAをAIに任せるためのハーネス的なことをするサービス aqua を作っていました。 このサービスの紹介を書こうと思っていたんですが、なんか知らないアカウントが僕の作ったサービスの開発者を自称してXに投稿しているのを見つけたので、注意喚起も兼ねて調べたことをまとめておこうと思います。 起きたことのタイムライン 03/10: サービスをリリース 03/13: 僕が自分でサービスの紹介をredditに投稿 03/14: 知らないアカウントがサービスの紹介をXに投稿 03/15: 僕はXには投稿してないはずなのに t.co からのアクセスが記録されていたので、流入元を探したら知らないアカウントの投稿を発見し、調査と通報を行う 知らないアカウントの様子 以下のア
本日3/6に、 Go 1.26.1 と Go 1.25.8 がリリースされました。 本バージョンで修正された脆弱性のひとつは私が見つけたものです。 せっかくの人生初のCVEなので、経緯を紹介しようと思います。 脆弱性の内容脆弱性は以下で公開されています。 net/url: reject IPv6 literal not at start of host (CVE-2026-25679) · Issue #77578 · golang/go The Go standard library function net/url.Parse insufficiently validated the host/authority component and accepted some invalid URLs by effectively treating garbage before an IP-l
AI models can now independently identify high-severity vulnerabilities in complex software. As we recently documented, Claude found more than 500 zero-day vulnerabilities (security flaws that are unknown to the software’s maintainers) in well-tested open-source software. In this post, we share details of a collaboration with researchers at Mozilla in which Claude Opus 4.6 discovered 22 vulnerabili
Dependabot is a noise machine. It makes you feel like you’re doing work, but you’re actually discouraging more useful work. This is especially true for security alerts in the Go ecosystem. I recommend turning it off and replacing it with a pair of scheduled GitHub Actions, one running govulncheck, and the other running your test suite against the latest version of your dependencies. A little case
はじめにペンギンになりたいエンジニアの島ノ江です。 普段は CSIG で「FutureVuls」という脆弱性管理サービスの開発を担当しています。 Go1.26リリース連載 の6日目。今回は Go 1.26 で New experimental として追加される runtime/secret を、特にどのような議論がされてきたかについて見ていきます(リリースノート) …と思っていたのですが、既に mattn さんがこのパッケージの概説と実験をされています。本機能の導入によりどのように機密情報の扱いが変わるかについてはこちらの記事をご参照ください。 https://zenn.dev/mattn/articles/64d85241fd3726 そこで、本記事では以下の内容に触れていこうと思います。 前方秘匿性についてGo でのメモリ管理について本機能が提案された背景(issue を遡って)機能概
このコーナーでは、2014年から先端テクノロジーの研究を論文単位で記事にしているWebメディア「Seamless」(シームレス)を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。 X: @shiropen2 米UCバークレーや米カーネギーメロン大学などに所属する研究者らが発表した論文「Pixnapping: Bringing Pixel Stealing out of the Stone Age」は、Androidデバイスにおける新たな脅威として、画面上のピクセル情報を盗み取る攻撃手法「Pixnapping」を提案した研究報告だ。 この攻撃は、Androidの基本的な機能を巧妙に悪用することで成り立っている。Androidでは、アプリ同士が「インテント」という仕組みを使って連携できる。攻撃者は、この正規の機能を使って標的となるアプリを起動し、その上に透明ま
id:cohalzです。この記事は、はてなのSREが毎月交代で書いているSRE連載の2025年10月号の記事です。9月の記事はid:s-shiroのCloudFront標準ログ(v2)をカスタマイズして便利に使う工夫でした。 みなさん組織でGitHubを安全に使えていますか? こうした問いに答えるため、安全に利用するためのポリシーをはてな社内でいくつか設定していきました。今回はそのうち、最近利用できるようになった機能を中心に以下の2つについて話していきます。 Enforce SHA pinningの有効化 Owner権限を持つ人を減らす また最後にリポジトリ・プロジェクトの管理者を調べるための方法についても付録として紹介していきます。 Enforce SHA pinningの有効化への道のり 最近大きく話題になっているセキュリティリスクといえばサプライチェーン攻撃で、2025/3にはGit
デジタル時代において、パスワードは依然として最も広く使用される認証手段の一つです。しかし、従来のパスワードポリシーの多くが、実は逆効果だったことをご存知でしょうか? NIST(米国国立標準技術研究所)が発行するSP 800-63B-4は、パスワードセキュリティに関する最新の指針を提供しており、これまでの「常識」を覆す内容が含まれています。(専門家の間では長らく常識だったものなんですが…。)本記事では、企業内でパスワードを使ったユーザー認証システムを担当される方、およびこうしたポリシーを決める担当者や経営者に向けて、この重要な文書の核心をわかりやすく解説します。 パスワードの2つの分類 NIST SP 800-63B-4では、パスワードを以下の2種類に分類しています。 1. パスワード(Passwords) サーバー側で検証される秘密情報。ログイン時にサーバーに送信され、集中的に検証されます
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く