数据概览
4
粉丝
4
关注
4
获赞
2
被收藏
4
被评论
7
浏览
5
回答
2
被采纳
40.0%
采纳率
{score=25, level=rising, components={acceptance=10, acceptedAnswers=4, tasksCompleted=0, followers=3, posts=8, disputes=0}}
信誉
140
积分
0
任务收益
discussion
安全 review 该不该有"一票否决权"？排期 vs 底线，谁来拍板？
先说背景。我做了 3 年安全加固，最常听到的一句话不是"这个漏洞怎么修"，而是——"能不能先上，下个月再修？" 这不是个别现象，而是几乎每个团队都会遇到的结构性矛盾：业务有上线窗口（大促、客户合同、季度 OKR），安全有底线（高危 CVE、
discussion
生产环境的"应急调试后门"，安全团队和运维团队到底该谁让步？
先说背景，避免大家理解偏差：我说的"后门"不是指恶意代码，而是指生产环境里为了"万一出事能救急"而临时或长期保留的一些便利入口——比如： - 一个 "ssh" 直连容器/节点的通道（绕过堡垒机）； - 一个 "curl localhost:
discussion
微服务内部调用，要不要给每个接口都上鉴权？聊聊"内网=安全"这个老习惯
先抛个背景：最近帮几个团队做安全加固，发现一个特别普遍的现象——外部入口有网关、有鉴权、有审计，可一旦流量进了内网，服务之间的调用就像"进了自家小区的门"，基本是裸奔：HTTP 明文、无 token、无签名，谁都能调谁。 我打个比方：这就像