源代码审计碰到了知识图谱的安全共识

“ 源代码安全审计与知识图谱的邂逅，不论为了图谱而图谱还是为了绵薄技术探索。”

01

—

漏洞是在硬件、软件、协议的具体实现或系统安全策略上存在的缺陷，从而可以使攻击者能够在未授权的情况下访问或破坏系统。说源代码审计呢，咋扯上漏洞了，啥还0day,在开发人员的眼里那就是个bug，那么代码安全为啥很重要？大家可以看下最近很火的绿盟发布的《软件供应链安全技术白皮书》；源代码审计贯穿数字化的全生命周期，也是安全最起始保障，源代码审计经过了许些年的发展，早年一直被国外市场所垄断，近几年国内新星不断，在源代码的智能时代不断推陈出新，今天我们来用知识图谱做些源代码审计的技术尝试探索。

• 一、传统源代码审计

源代码审计（Code Review）是分为工具审计、人工审计和半自动化审计，是通过对源代码的架构分析、代码规范、业务流程理解，结合经验、工具实现静态、动态、模糊测试等过程，找出代码中存在的安全性问题。

随着互联网的崛起，信息化向数字化转型，市场上出现了太多的Code Review工具和产品，不论是商用的还是开源，总一款适合实际业务安全发展需要，咋感觉上广告词了，以至于选择一个合适的Code Review都会成为一种挑战，工具与产品只是为了帮助企业解决部分自动化或半自动化的手段，人才是衡量整体安全过程的核心竞争力，具不完全统计（记忆大数据分析）目前国际和国内在网络安全专业人才缺口都很大；老跑题可咋弄。

最早期，代码是通过安全人员进行人工审计，查找函数、变量、接口危险的风险控制或属性，但是动辄几万几十万的代码，纯靠人工的方式很难实现全覆盖的审计，聪明的开始编写脚本辅助人工审计，机智的将脚本变成了产品和工具，比如非常有名的Checkmarx，Fortify等商业TOP，国内近年出现的优秀厂家如北大库博、开源网安、海云安、悬镜安全、默安科技等公司；如下图：（图序自然组合无先后）

图：国内外部分代码审计厂家

• 二、源代码审计与知识图谱的相遇

一个团队中开发成员的配置几乎是金字塔形的，各个开发成员水平参差不齐、被压榨的周期性、无序的使用开源组件、开发人员的高流动性、安全检测的常规性等外在与内在的因素必然带来各种问题。近年攻击的方向越来越侧重于利用软件或系统自身安全漏洞，或开发过程使用的第三方组件产生的漏洞；随着DevOps的兴起，软件的生成变成了一套流程化体系，就像工厂的流水线，每个环节和模块之间的低耦合，在极大的提高了开发的效率的同时，也给安全带来了风险；DevSecOps的技术旨在整个开发生命周期内提早发现和解决安全问题，去年的供应链安全引起大家极大关注的是Log4J漏洞，被称为是有史以来最严重的安全漏洞之一，后文有详细描述；源代码安全现在被细分了很多领域，贯穿整个供应链安全周期，从源代码组成分析（SCA）、静态分析、动态分析、漏洞管理、开发环境安全。

知识图谱本质上是一种叫做语义网络（semantic network）的知识库，知识图谱是知识工程的一个分支，以知识工程中语义网络作为理论基础，并且结合了机器学习、自然语言处理、知识表示和推理的最新成果，知识图谱对于解决大数据中文本分析和图像理解问题发挥重要作用。知识图谱又是人工智能的一个重要分支，也是机器具有认知能力的基石，更好的让机器理解知识或传递的信息，知识图谱从个人（不代表公司“安技汇”）的理解看法，需具备完备的知识体系，细分专业完备内容、可追溯推敲的既定事实，使用一个经典的定义来自于柏拉图：一条陈述能称得上是知识必须满足三个条件，它一定是被验证过的，正确的，而且是被人们相信的；图谱分开表述：图是可视化展示，是为了通过图像更好的了解事物的一种形式，谱按照汉译本义：依照事物的类别、系统制的表册。

当源代码和知识图谱在无意间的邂逅，会给我带来什么样的冲击，经过上述描述介绍，可以知道，在一定（知识完备）的前提下，通过知识图谱对源代码数据进行抽取、融合、加工，会不会呈现出一个整体的业务架构关系、代码逻辑关系、组件关系、依赖关系等等内容，将专业的信息通过可以理解认知的方式呈现给我们，那么源代码与知识图谱的相遇故事就开始了。

• 三、源代码审计与知识图谱的偕手

文章开头也说最近绿盟发布的《软件供应链安全技术白皮书》中也有一段介绍了，知识图谱与供应链安全的偕手，我们引用（如侵犯绿盟知识产权，请后台留言，进行删除）来再给大家介绍下，应用白皮书中P33-P36页部分内容：

就2021年12月份出现的Log4j2漏洞（CVE-2021-44228）。Log4j2作为一个堪比标准库的基础日志库，受到无数开源Java组件直接或间接依赖。分析这种庞大且复杂的关系链，可以使用知识图谱技术。参考CycloneDX 提供的开源组件成分及其关系规范化的格式描述，可以通过关系图描述开源组件的组成成分，如下图所示。

 图;基于CycloneDX BOM 的图关系模型

通过知识图谱可以很好的解决开源软件复杂的依赖关系表示不清晰问题，让开源软件成分语义化，可视化，变得机器可读可推理：

1．知识图谱的图表示方法构建开源软件的成分深层关系（如依赖、引用、许可等）；

2．使用开源软件相关的漏洞知识库和其建立关系，利用知识图谱的分层传播路径搜索算法有效分析开源软件的漏洞影响，以衡量项目漏洞的严重性；

3．应用图算法分析知识图谱（依赖关系图）获得最具风险的关键依赖关系，推荐有效的修复建议。

图：开源软件知识图谱本体模型

在安全分析研究方面，开源软件知识图谱可以帮助安全人员对开源软件进行全面的风险评估分析：

1. 基于开源组件属性特征（如源代码、包等文件的hash 值）来判定组件是否存在被包装冒用或自身被篡改的风险 ；

2. 利用不同开源组件的依赖关系，结合组件版本信息，可以在高危漏洞应急响应中快速识别受影响的其他组件，通过图的聚合及子图拆分等图优化算法能够高效、持续输出风险分析结果。

如下图，展示了[email protected] 组件存在的多个高危漏洞关系，如果在软件中引用了存在高危漏洞的开源组件，无疑会给软件产品带来潜在的威胁，同样，软件供应商的软件产品也会面临同样的安全风险。

 图：log4j 组件的依赖图谱

不是说源代码和知识图谱吗？咋又扯到了漏洞分析和供应链安全上了，能不能有点专业性，大佬的内容分享完了，那么来看看我们内部针对源代码和知识图谱的技术探索，首先是制定图谱抽取的规则，定义包、类、变量、方法、传参、返回值、Value等抽取方法，同时作为实体，再结合它们的属性、内容及执行顺序建立边关系和节点实体；搭建完源代码的知识图谱关系，通过知识训练，完善了部分架构、业务逻辑等场景模型，在采用内在的图计算，将专业的源代码业务逻辑机构转化为便于理解和可视的架构图、业务流程图，可更好的展示产品的业务逻辑和架构情况，辅助产品经理、架构师更好的完善或优化业务流程与架构；如下图：

图：源代码抽取关系图

通过先验知识（漏洞知识）、验证规则（POC）、权重推理等完成源代码安全审计与漏洞验证工作，判定漏洞利用的后果、利用的先决条件、是否可以被正常利用等知识，降低在审计过程中过多的人员参与和相互推诿，如判定一个函数存在问题，但是这个函数在整体业务中仅作为特定场景使用，前端又无法直接使用时，传统的判定为存在漏洞，通过知识图谱可以给与更为明确的说明，便于更好的解决问题或规避问题；同时可以用于业务逻辑的风险识别，通过知识图谱对源代码的深层次解析，利用推理和决策引擎，对变量、传参、方法、返回值、Value等进行演算，排查业务逻辑存在的问题，可有效避免因业务逻辑、活动差异导致的安全问题，如在图谱中发现未对传参、返回值和Value进行效验，就会导致小钱买大东西、不花钱得收意、薅羊毛、订单未结算返利等逻辑问题;如图：

图：审计源代码与漏洞关系图

源代码与知识图谱的碰撞，仅是做了些基础试探性的研究与测试验证，也只是抛砖引玉的进行了粗框的介绍，后续结合公司的产品会不断的完善、优化基于知识图谱的源代码审计产品，更好的利用AI、自动化、图谱等新技术为安全赋能，让安全与源代码更为高耦合、相同步、相适应，真正的实现同步建设、同步规划和同步运维，达到“本质提升、标本兼治”。

• 四、愿景与展望

垂直领域的知识图谱构建缺乏自然语言处理方面的资源，特别是专业性词典的匮乏使得垂直领域知识图谱构建需要付出更大的代价，数字化转型带来的低代码时代，时间、人力与代码质量，其本身就是鱼和熊掌不可兼得的问题，寻求一个平衡点或突破点，那么知识图谱和源代码还可以实现什么，数字化研发辅助工具、源代码安全自动化修复？其实最重要的是什么，是知识的储备、标准化的参考依据、知识的完备性，希望有能力或者有实力的企业建立一个适合持续发展的安全知识图谱联盟，更好地为智能化安全发展提供助力。

02

—

原文始发于微信公众号（安技汇）：源代码审计碰到了知识图谱的安全共识