OSSで新機能要望やバグ報告を全てGitHub Discussionsに起票してもらうことにしてみた - knqyf263's blog
今回の案は自分のメンテナンスしているOSSだと回りそうという話で、これが他のプロジェクトにとっても良いと勧めているわけではないです。 ふーんそういう運用をしているところもあるんだと思って読んでもらえればと思います。 要約 背景 質問への回答 バグ報告のノイズ バグと言われることの精神的苦痛 新機能要望 Issuesの横の数字が増えていくことへの嫌悪感 Issues対応への強迫観念 マイルストーン決めるときにタスクの選定が面倒 運用案 利点 タスクの分離 コミュニティ内のコミュニケーション促進 メンテナの精神的負担軽減 懸念 アサインができない 参照しているIssuesが表示できない トリアージが終わっていないバグはissueにならない 再現ができないバグはissueにならない ユーザがバグ起票後にすぐPRを作ることができない 実現方法が思いつかないだけで追加したい新機能がissueにならな
20分で分かるDirty Pipe（CVE-2022-0847） - knqyf263's blog
極限まで詳細を省けば何とか20分で雰囲気だけでも伝えられるんじゃないかと思って書きました。書き終えてから見返したら多分無理なので誇大広告となったことを深くお詫び申し上げます。 背景 概要 脆弱性の影響 ページキャッシュやsplice パイプ マージの可否 下準備 攻撃手順 まとめ 背景 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com Linuxのパイプに関する脆弱性なのですが、仕組みは意外とシンプルでぎりぎりブログでも伝わるかもしれないと思ったので自分の理解を書きました。あといつも細かく書きすぎて長くなるので、今回は雰囲気だけでも伝わるようにとにかく説明を簡略化し、ふわっとした概要だけでも理解してもらえるように頑張りました。その結果、若干正確性に欠ける部分があるかもしれませんがお許しください。細かい部分はまた別の記事でま
Terraform, Dockerfile, KubernetesなどIaCの脆弱な設定をCI/CDで検知する - knqyf263's blog
概要 自分の所属企業であるAqua SecurityがTFsecというOSSを買収しました。 blog.aquasec.com TFsecはどういうツールかというとTerraformの静的解析スキャナーです。Terraformの設定ファイルを渡すことでセキュリティに関する設定ミスを主に検知してくれます。 github.com そのアナウンスに伴い、TFsecは自分が開発している脆弱性スキャナーであるTrivyに統合されました。TrivyではTerraformに加えDockerfileやKubernetesなど、いわゆるInfrastructure as Code（IaC）の設定ミスを検知するマネージドポリシーも提供しています。他にもJSONやYAMLなど一般的なファイルフォーマットに対応しているため自分でポリシーを書くことでそれらの検知にも使えます。CloudFormationやAnsib
TrivyがRed Hatの認定脆弱性スキャナーになりました - knqyf263's blog
概要 本日、Red HatからRed Hat Vulnerability Scanner Certificationという脆弱性スキャナーに対する認定プログラムが発表されました。 www.redhat.com そして上の発表の中で私の所属企業であるAqua Securityも認定を受けたことが書かれています。つまり自分が業務として開発しているTrivyというOSSの脆弱性スキャナーもRed Hatの認定を受けたことになります（というか実はTrivyだけなのですが詳細は後述）。自分のブログを見る人は既に存在は知ってくれていると思いますが一応貼っておきます。 github.com 現在認定を受けているのは Aqua Security, NeuVector, Sysdigの3社だけです。NeuVectorとSysdigは商用製品で認定を受けているはずなので、3rd partyのOSSスキャナーで
RedisからOSコマンドを実行する攻撃方法（SLAVEOF編） - knqyf263's blog
はじめに 前回の記事で、誤ってインターネットに開放されたRedisを操作してOSコマンド実行するまでの攻撃方法を説明しました。 knqyf263.hatenablog.com こちらの方法ではCONFIG SETを使っていたのですが、最近コンテナが利用されることが増えたために刺さりにくくなっています。また、Redisの実行ユーザの権限が強い必要があったり、ドキュメントルートのpathを予測する必要があったりといった制約もありました。そういった制約を回避する方法が発表されていたので試してみました。 さらに、前回はRedisが完全に操作できる前提を置いていましたが今回は更に難しくSSRFのみが使える状況が想定されています。SSRFについては調べたら出ると思うので割愛しますが、今回の場合は簡単に言うと「Redisは公開されていないが、公開されているWebサーバなど経由で攻撃者が内部のRedisに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
