<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>xiaokeqing</title><link>https://xiaokeqing.cn/</link><description>Recent content on xiaokeqing</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Tue, 13 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://xiaokeqing.cn/index.xml" rel="self" type="application/rss+xml"/><item><title>把部署链做成「造不了假」：CI → ACR → digest → 看门狗</title><link>https://xiaokeqing.cn/posts/verifiable-deploy-chain/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><guid>https://xiaokeqing.cn/posts/verifiable-deploy-chain/</guid><description>一个容器跑起来，你怎么知道跑的就是你刚推的那个 commit？这条链上我封了五道闸门：触发即校验、jar 内指纹核对、镜像 digest 而不是 tag、部署前后的硬校验、以及一个会自己回滚的看门狗。</description></item><item><title>规则裁剪 20% 的取舍：判据、演练与代价</title><link>https://xiaokeqing.cn/posts/suricata-rule-trim/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><guid>https://xiaokeqing.cn/posts/suricata-rule-trim/</guid><description>53,122 条 alert 规则、44MB 规则文件，24 小时里真正命中的只有 1 个签名。裁掉 10,675 条（约 20%）之后，阳性对照照常在报、基线命中集逐条复现、丢失 = 0。这篇讲判据怎么定、怎么证明没裁错、以及被裁掉的那部分弱信号意味着什么。</description></item><item><title>蜜罐与诱饵端口：从「看不见」到「能检出」</title><link>https://xiaokeqing.cn/posts/honeypot-visibility/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><guid>https://xiaokeqing.cn/posts/honeypot-visibility/</guid><description>多端口扫描的漏报，在本环境里不是「规则不够」，而是「看不见」——7 个端口的 SYN 在云安全组就被丢了，传感器看不到的包，任何规则都检测不到。这篇讲清可见性缺口怎么证明、误报抑制怎么做，以及哪些检测能力被刻意放弃了。</description></item><item><title>数据战报模板：周报 / 月报（字段全部可核对）</title><link>https://xiaokeqing.cn/posts/weekly-report-template/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><guid>https://xiaokeqing.cn/posts/weekly-report-template/</guid><description>一份可以直接照着填的周报/月报骨架：每一格都写明它来自哪个公开端点、哪个字段、什么口径，以及「取不到的时候写什么」。模板的价值不在于好看，而在于它逼你回答「这个数字到底是怎么算出来的」。</description></item><item><title>为什么公开问答只解释、不取证：两层防御怎么做</title><link>https://xiaokeqing.cn/posts/public-ask-explain-not-forensics/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><guid>https://xiaokeqing.cn/posts/public-ask-explain-not-forensics/</guid><description>「不执行处置」和「不泄露内部事件数据」是两件事。收紧之前，匿名问一句「我们昨天被谁打了」，回答里会带出内部资产名和内部接口路径 —— 处置确实没执行，但数据已经出去了。这篇讲两层防御（编排层不派发 + 工具层二次拒绝）怎么落地，以及它换来的代价。</description></item><item><title>一次 6 分钟全站事故复盘：4 个独立缺陷</title><link>https://xiaokeqing.cn/posts/incident-502-postmortem/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><guid>https://xiaokeqing.cn/posts/incident-502-postmortem/</guid><description>站点 502 了约 6 分钟。查下来不是「一个 bug」，而是四个各自独立、每一个单独都足以致命的缺陷：启动崩溃、配置格式、潜伏 3 天的防火墙冲突、以及发布链的盲区。这篇按时间线还原，并给出正在生效的对照组。</description></item><item><title>我把这个博客当成一个安全项目来做</title><link>https://xiaokeqing.cn/posts/blog-as-a-security-project/</link><pubDate>Sat, 10 Oct 2026 00:00:00 +0000</pubDate><guid>https://xiaokeqing.cn/posts/blog-as-a-security-project/</guid><description>静态托管、零第三方脚本、源站不暴露——这些选择看起来是「技术选型」，其实每一条都是在做攻击面收敛。</description></item><item><title>写作计划：接下来会写什么</title><link>https://xiaokeqing.cn/posts/roadmap/</link><pubDate>Sat, 10 Oct 2026 00:00:00 +0000</pubDate><guid>https://xiaokeqing.cn/posts/roadmap/</guid><description>把准备写的题目列出来，写完一个勾一个——公开自己的进度表，也是一种督促。</description></item><item><title>这个站点在做什么</title><link>https://xiaokeqing.cn/posts/welcome/</link><pubDate>Sat, 10 Oct 2026 00:00:00 +0000</pubDate><guid>https://xiaokeqing.cn/posts/welcome/</guid><description>一个安全方向的学习与技术记录站——把做过的项目、踩过的坑、以及可以亲手试的东西放在一起。</description></item></channel></rss>