视频分析专用大模型"Olympus"

亚马逊可能最早于本周宣布推出其名为“Olympus”的AI模型，该模型专注于视频和图像处理。根据The Information的报道，Olympus擅长处理视频分析工作，旨在服务于体育和媒体等行业，并以具有竞争力的价格吸引客户。

Olympus AI模型的特点

Olympus 大模型不仅能够处理图像和视频，还可以处理文本内容，使其在功能上与其他产品产生差异化。据消息人士透露，Olympus在视频分析方面表现出色，例如可以追踪篮球的轨迹、诊断海底钻探设备的问题等。

尽管在文本生成方面，Olympus的能力可能不如OpenAI和Anthropic，但其独有的视频处理能力以及具有竞争力的价格策略是其打开市场的敲门砖，这有助于它在市场上开辟出一片独特的领域。

视频分析市场AI的渗透率还不是那么高，所以，Olympus大模型的市场前景是相对乐观的。

亚马逊与Anthropic的合作

据报道，亚马逊计划在年度AWS re:Invent客户大会期间发布Olympus，该活动将于12月2日至12月6日在拉斯维加斯举行。

加强与Anthropic的合作

11月份，ReadWrite报道了亚马逊加强了与Anthropic的合作关系，其追加投资了40亿美元用于公司发展。协议中指出，Anthropic指定AWS为其主要云服务提供商，而AWS客户将提前获得访问权限，可以通过Amazon Bedrock定制AI模型。

双方在官方声明中表示：

该协议是更广泛合作的一部分，旨在开发行业内最可靠、性能最高的基础模型。

结合内外部资源推进AI发展

此次 Olympus 的推出也反映了亚马逊结合外部合作与内部研发双管齐下的AI发展战略：

• 亚马逊给Anthropic投资80亿美元，显示了其对外部技术的投资兴趣；

• Olympus的发布体现了亚马逊自身在AI领域的创新实力和技术积累。

这种内外结合的方式不仅增强了亚马逊的技术多样性，也为客户提供了一个更为全面且灵活的AI解决方案平台。

关键词

• CodeQL

• Copilot

• AI modeling

• Variant analysis

Good Sentence

Avi Douglen（Bounce Security安全咨询机构CEO）:

Security at the expense of usability, comes at the expense of security

牺牲可用性换取安全性，最终会牺牲安全性

大佬资料

• Nick Liffen Github架构师

• Niroshan Rajadurai Github副总裁，Semmle（CodeQL前公司）安全专家

背景

AI 正在从根本上改变技术和安全领域。GitHub将 AI 视为一种工具，帮助开发者加速开发过程的同时编写更安全的代码。例如，Copilot 推出了一个Security filter（安全过滤器），针对 Python 和 JavaScript 中最常见的易受攻击的编码模式（包括硬编码密钥、SQL 注入和路径穿越等）提出更安全的编码方式。

CodeQL 团队负责为框架/API建模，以帮助 CodeQL 发现更多漏洞。建模是一个耗时的过程，因此团队开始思考能否将AI的能力迁移过来，加速建模过程。

实验结果超出预期，团队能够利用 AI 优化建模过程，以增强工具在代码中发现漏洞的能力。

1.Security filter 安全过滤器

1.1.工作原理

为了提高Copilot 的代码建议质量，团队更新了底层的 Codex 模型，从而大幅提升了代码建议的质量。

Codex模型主要的更新点：

1. 升级的 AI Codex 模型：将 Copilot 升级到新的 OpenAI Codex 模型，该模型在代码合成方面的能力有显著提升。

2. 更好的上下文理解：通过一种称为 Fill-In-the-Middle (FIM) 的新范式改进了Copilot，该范式为开发者提供了更好的代码建议。其不仅考虑代码前缀，还会利用代码后缀，在二者中间留下 gap 供Copilot 填充。这样，大模型现在能够更好地理解用户代码的逻辑。在 FIM 提供高质量代码建议的同时，还开发了各种策略保证模型的低延迟。

3. 轻量级客户端模型：更新 VS Code 的 Copilot 插件，引入了轻量级客户端模型，从而提高了代码建议的整体接受率。Copilot 还会关注用户的历史行为（如：上次建议是否被接受），以降低无效建议出现的频率。这项更新使大模型提供的无效建议减少了 4.5%，以帮助 Copilot 更好地响应每位开发者。

1.2.代码安全能力

基于 AI 的漏洞预防系统，可以实时阻止不安全的编码模式，以使 Copilot 的建议更加安全。可以处理常见的安全缺陷：

• 硬编码密钥

• SQL 注入

• 路径穿越

该系统利用大型语言模型（LLMs）来模拟静态分析工具的行为—— Copilot 拥有强大的算力，计算速度非常快，甚至可以检测不完整代码片段中的易受攻击模式。

• 检测硬编码密钥的示例：

2.AI污点建模实践

2.1.技术点

CodeQL发现安全缺陷离不开污点传播分析，对API的污点建模（source、sink、summary）至关重要。

开源软件（OSS）社区已经开发了数千个可能需要建模的 API 的 package 。如果建模不及时更新，就会导致漏报。

传统上，安全人员会对这些 API 手动建模，但要对数千个 OSS 框架建模非常耗时。为此，团队开始使用大语言模型（LLMs）来自动为这些API建模，极大地提高了效率。

AI建模的结果会使用一种 variant analysis （变体分析）的技术进行测试，这是一种识别新型安全漏洞的方法。

variant analysis是使用一个已知的漏洞（可能来源于渗透、fuzzing等）作为一个源，去发现代码中相似问题的一个过程，其会用到以下技术点：

• 语义分析（程序语义，可以迅速找到重点函数的调用或拥有特定方法签名的函数）

• 控制流分析（代码执行路径）

• 数据流分析（可以发现潜在的summary）

• 污点分析（可以发现潜在的summary）

• ...

此外，其还推出了一种 Multi-Repository Variant Analysis (MRVA)技术，可以多仓库联动，大规模执行变体分析。

2.2.AI建模实践

• CodeQL建模编辑器：

2.2.1.建模前扫描

2.2.2.开始建模

点击 【Start modeling】

可以为找到的未建模的API选择【Model type】

• Source

• Sink

• Flow summary

• Netural

• 还可以选择【Model dependency】

也就是将建模结果适配到你选定的其他仓库

• 会找到你选定仓库中所有调用sql2o相关方法的地方，可以看到上文展示的那个sink点也被找到了

此时，常规建模是需要我们手动指定api是source、sink 还是 summary，这项工作量非常巨大

但是 AI建模 可以一键完成以上污点建模过程

2.2.3.AI一键污点建模

【Model with AI】AI一键污点建模

AI建模会自动理解各个API的工作原理，建模完成：

完成后点击【Save all】

2.2.4.建模后重新查询

重新运行查询即可发现SQL注入漏洞

建模后的查询结果：

总结

Copilot + CodeQL 还有很多其他功能，但好多功能还未公开，如：

• Secret to detect generic secrets

• Copilot chat to scale remediation

• Automically remediating security backlog

实在找不到关于CodeQL+Copilot 的AI污点建模的实现原理（流下了没用的泪水），如果大家有发现相关的文章，欢迎留言/私信(抱拳了！)

关键词

• CodeQL（SAST工具）

• Coplit（AI工具）

• AI增强SAST工具的实现原理

• AI驱动的SAST工具能带来哪些好处

背景

在2023年GitHub的一项调查中，开发者们表示，除了编写代码（占比32%），他们最常做的任务就是发现和修复安全漏洞（占比31%）。

随着开发团队将安全检查提前到软件开发生命周期（SDLC）的早期阶段（安全左移），开发者们已经成为抵御漏洞的第一道防线。

然而，遗憾的是，这种“左移”策略更多是将安全实践的责任推给了开发者，而非真正带来好处。不过，45%的开发者认为，在对软件进行安全审查时，如果能很好地结合生成式AI的能力，那么会在保证软件安全的前提下，极大地提高开发效率。

• 开发者面临的安全挑战

• AI驱动的安全工具的价值

• AI如何增强静态应用程序安全测试（SAST）的效果

为什么开发者对安全问题感到沮丧？

• 在进行安全审查时，一些开发者被迫使用非定制化的工具，工具无法结合业务场景做分析，导致产生大量的误报漏报，这严重影响了他们发现和解决安全漏洞的效率。

• 此外，大多数开发者的首要任务是编写和review代码。然而，在“安全左移”策略的背景下，他们还被要求在日常工作中审查、理解和修复漏洞，这对他们的安全开发能力提出了更高的要求。

开发者在做安全审查时，需要在不运行项目的前提下发现漏洞，这需要他们有丰富的安全审查经验，并且对各种漏洞类型熟练掌握。开发者需要在"开发"与"安全"两个角色之间反复切换，无形中加重了负担，降低了开发效率。

简而言之：

安全并非开发过程的固有部分，开发者往往对自己代码的安全性缺乏信心。

如果不加以干预，这些困扰只会随着时间的推移而加剧。根据Gartner的预测，到2028年，75%的企业软件工程师将使用AI编码助手。这意味着，随着开发者借助GitHub Copilot等AI工具提高生产力并编写更多代码，需要审查的代码量也将随之增加。

安全专家也面临巨大压力

通常情况下，每100名开发者中只有一位安全专家，他们最终成为抵御漏洞的最后一道防线（并负责制定和执行安全政策），这是一项艰巨的任务。ISC2（国际信息系统安全认证联盟）在其2023年的工作力研究中报告称，全球对安全专业人员的需求增加了四百万。

虽然AI不能取代安全专家，但它可以帮助他们扩展知识和能力。

AI可以帮助进行代码和安全审查，确保在提高开发速度的同时不会导致漏洞的增加。”

AI如何赋能SAST工具

SAST工具并非开发者使用的唯一安全工具，但它们是最受欢迎的工具之一。让我们看看AI如何帮助SAST工具更高效地完成工作。

AI增强框架建模能力

为了让SAST工具检测代码中的漏洞，工具自身需要理解整个项目。因此，安全专家通过建模来进行污点分析。但项目中使用的组件/框架是千变万化的，因此，对常用的框架进行建模是非常重要的。

这时AI就派上用场了。

可以使用AI对开源框架和库进行建模，从而提高SAST工具对整个项目的理解能力。

CodeQL如何通过AI对框架进行建模 会在后续文章中介绍

在开发环境中提供上下文相关的漏洞信息

Code scanning autofix 是一个AI驱动的安全功能示例，它结合了SAST工具（在本例中是GitHub的CodeQL）与GitHub Copilot的生成式AI能力。

• 开发者可以在PR(pull request)中直接收到AI建议的代码修复方案和警报

• 收到关于漏洞描述及针对具体的业务场景的修复建议

• 可以在命令行界面（CLI）中直接查看并应用自动修复建议，只需启用GitHub CLI扩展即可

开发者可以在CI/CD流水线中更快地修复漏洞，而不是在生产环境中才发现这些漏洞。

增强软件开发生命周期（SDLC）

开发者使用SAST工具在整个SDLC中保护他们的代码。

一旦开发者启用了像CodeQL这样的代码扫描解决方案，SAST工具将扫描源代码，并将安全检查集成到CI/CD工作流程中：

• 当你对代码库进行更改并在GitHub上创建PR时，CodeQL会自动进行扫描。如果发现漏洞，它会在PR中对应的文件中发出警报。开发者可以在合并分支前持续监控代码安全，做到在开发阶段发现漏洞并修复。

• 除了commit和PR，你还可以在

  GitHub Actions

  工作流程中设置指定时间点运行CodeQL。因此，如果你想让CodeQL在特定时间间隔内定期扫描代码，可以使用GitHub Actions工作流程进行调度。

code scanning autofix的实际效果

code scanning autofix

通过提供修复方案及上下文解释，使CodeQL对开发者更加友好。这种AI应用降低了开发者修复漏洞的门槛。

SQL注入是一种常见的漏洞，通常可以通过SAST工具发现。

步骤1:发现漏洞

CodeQL的代码扫描功能可以在所有公共仓库中免费启用，并自动安排运行。扫描过程主要包括四个部分，都围绕源代码展开：

• tokenization（标记）

• abstraction（抽象）

• semantic analysis（语义分析）

• taint analysis（污点分析）

CodeQL运行原理（以上四步）会在后续文章中解释

步骤2:构建prompt (提示)以生成修复方案

以下是发送给Copilot的prompt中包含的内容：

• CodeQL报告及关于检测到的漏洞的常规信息：如漏洞示例及其修复方法，这些信息是从CodeQL漏洞知识库中获取的。

• 代码片段和行号，可能来自多个源代码文件，这些代码片段和行号来源于CodeQL污点分析的完整数据流信息。这些代码片段就是项目中最可能需要修复的代码块。

为了指导Copilot的响应格式，我们的机器学习工程师需要：

• 限制Copilot的基础模型，使其仅编辑prompt中包含的代码。

• 要求模型生成Markdown格式的输出，包括漏洞的详细描述和修复方案。

• 要求提供“before”和“after”的代码块（上下文信息），展示需要更改的代码片段（包括一些上下文行）以及要进行的编辑内容。

• 要求模型列出修复方案中使用的所有外部依赖项。

步骤3:检查不良代码

做一些过滤操作（不良内容、敏感内容等）

步骤4:最后的润色

• fuzzy search（模糊搜索），以确保包含AI生成的修复代码与prompt中提供的代码块上下文信息匹配。模糊搜索寻找代码块之间的精确和相似匹配，以便

  fix generator

  可以捕捉并纠正错误，例如缩进、分号或代码注释差异相关的错误。

• 使用解析器检查语法错误

• 进行语义检查，以评估AI提供的修复方案的逻辑。例如，名称解析和类型检查有助于确保修复代码与原始代码的意图和功能相匹配。

• 验证Copilot修复方案中的外部依赖项。这意味着查找包含项目依赖项信息的配置文件，以查看所需的依赖项是否已存在于项目中。如果没有，

  fix generator

  会验证依赖项是否存在，并检查其是否有漏洞。然后，它会将需要的依赖项添加到配置文件中，作为修复建议的一部分。

步骤5:解释漏洞和修复方案

如何从AI驱动的SAST工具中受益

通过AI，安全检查能够无缝集成到开发者的日常工作流程中，使安全成为SDLC的一部分，而非生产后的补救措施。当开发者在开发阶段更容易地确保代码安全时，整个SDLC都会得到强化。而当SDLC得到更好的保护时，组织可以更专注于创新。

当你将安全视为SDLC的一个特性时，你的应用程序将更能抵御日益复杂的攻击，从而节省时间和金钱。你可以将这些节省下来的成本用于其他改进和新功能的实验。

组织在构建安全产品的同时，释放了资源用于创新。此外，安全团队可以专注于那些需要他们专业知识的战略性项目。

此外，开发者也可以获益：

• 在开发阶段更安全地编写更多代码。只需看看数据。由Copilot驱动的

  code scanning autofix

  可以为代码库中检测到的超过90%的漏洞类提供修复方案，并且超过三分之二的建议几乎无需修改即可合并。
• 更快更好地修复漏洞。通过

  code scanning autofix

  ，开发者会收到AI生成的代码修复方案（与业务场景结合）。他们还会收到针对实际业务场景的漏洞描述，而非固定的描述。这种具体的上下文帮助开发者更好地理解检测到的漏洞的性质、为何存在于代码库中以及如何修复它。

• 在开发环境中直接获得安全指导。开发者可以在PR中直接获取AI增强的SAST工具提供的所有信息。与传统的安全工具不同，其可以被视作定制化工具。

由老版mybatis-plus本地构建说开去

类似的场景：

需要研究一些比较老的开源项目，在进行本地构建时遇到的各种问题：

• 构建工具新旧版不兼容

• 旧的项目使用一些旧的插件/组件/三方库等（有的都已经废弃了，可能找不到）

• ...

问题1:gradle新旧版本特性不兼容

解决1:找到对应的旧版gradle并配置

1. 通过google定位到是gradle新旧版不兼容问题，那么下载哪个旧版本呢，通过观察mybatis-plus-v2.3.2的发布时间，决定要用哪个旧版本的gradle

可以看到是2018.9.17发布的，所以当时使用的gradle版本一定是这个日期之前的。

可以看到v4.10.1是2018.9.12发布的，v4.10是2018.8.27发布的，保险起见，我们使用gradle v4.10，就可以解决新旧版特性不兼容问题

1. 下载gradle4.10（新版gradle不支持

   uploadArchives

   特性）

2. idea配置gradle-4.10

问题2：旧组件propdeps-plugin无法找到

解决2：切换build.gradle仓库配置

1. 直接google搜索，可以找到一个spring仓库的issue（

   https://github.com/spring-projects/spring-batch/issues/4428

   ）：

点击 comment：

可以看到，propdeps-plugin这个插件已经废弃了，现在发布了新版（spring-attic/propdeps-plugin）作为替换，但是其依旧保留了一些旧版的snapshots（快照），我们点击链接，可以跳转到JFrog，然后直接搜索propdeps-plugin：

第一个是我们要找的：

把url copy出来，url如下：

buildscript {    repositories {        maven { url "https://repo.spring.io/plugins-release" }    }    dependencies {        classpath("org.springframework.build.gradle:propdeps-plugin:0.0.7")    }}

改为（maven仓库及dependencies都要改）：

buildscript {    repositories {        maven { url "https://repo.spring.io/artifactory/plugins-snapshot-local" }    }    dependencies {        classpath("org.springframework.build.gradle:propdeps-plugin:0.0.7-SNAPSHOT")    }}

改完后，再次build，即可build成功

考研求职两不误——开放-封闭原则

• 开闭原则是面向对象设计思想的核心所在

• 需求发生变化时，要尽量考虑到后续可能的同类变化，对频繁变化的点及时做出抽象

• 面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码

• 应对频繁变化的点才需抽象，拒绝刻意抽象

1.考研失败

“……多少次迎着冷眼与嘲笑，从没有放弃过心中的理想，一刹那恍惚，若有所失的感觉，不知不觉已变淡心里爱（谁明白我）……”

小菜此时正关在房中坐在桌前发呆，音箱中大声地放着 Beyond 乐队的《海阔天空》。此时有人敲门。打开一看，原来是大鸟。

大鸟：“小菜，怎么听这么伤感的歌，声音这么大，我在隔壁都听得清清楚楚。发生什么事了？”

小菜：“今天研究生考试成绩出来了，我的英语成绩离分数线差两分。之前的努力白费了。

大鸟：“失败也是正常的，考不上的人还是占多数呀，想开些吧，找到好工作未必比读研要差的。”

小菜：“为了考研，我没有做任何求职的准备，所以我们班不少同学都找到工作了，我却才刚开始，前段时间的面试也没消息。”

大鸟：“哈，鱼和熊掌岂能兼得，为一件事而放弃另一些机会，也是在情理之中的事。”

小菜：“说是这么说，我却感觉比较难受，我的同学，有几个其实水平不比我强，他们都签了 XX 大集团、XX 知名公司，而我现在一无所有，感觉很糟糕。要是当时我也花点时间在简历上，或许现在也不至于这么不爽。”

大鸟：“你考研复习的时候，每天学习多长时间，有没有休息的时候？”

小菜：“差不多十小时吧，其实效率并不高，有不少时候都困得不行，趴在桌上睡觉去了。”

大鸟：“这就对了，你为什么不利用休息的时间考虑一下自己的简历如何写，关心一下有些什么单位在招聘呢？这样也就不至于现在这样唉声叹气。”

小菜：“我感觉找工作会影响复习的精力，所以干脆什么都没找，但其实每天都会有些同学求职应聘的消息传到我耳朵里，我也没有安心复习。”

大鸟：“小菜呀，你其实就是没有搞懂一个设计模式的原则。”

小菜：“哦，是什么原则？”

大鸟：“先不谈这个原则，你想想看，香港澳门的顺利回归，有一个人起了重要的作用，他是谁？”

小菜：“啊，那还用说，是邓小平呀，如果不是他老人家提出的一国两制思想，或许现在还没回归呢。”

大鸟：“小平同志的确是伟大的政治思想家，他的这一创造性想法有什么独到之处？”

小菜：“我想想看，原因主要是在于大陆的社会主义制度不能修改，这一点毋庸置疑，而香港澳门长期在资本主义制度下管理和发展，所以回归时强行修改香港澳门的制度也并不合理，所以用‘一国两制’来解决制度差异造成的矛盾是最合理的办法。”

大鸟：“说得好，社会主义制度不能修改，邓小平在和英国首相撒切尔夫人谈香港问题的时候，如果咬定香港回来必须要实现社会主义制度，那回归就困难重重了，香港老百姓也不答应呀，毕竟这么多年来的殖民统治，突然在整个管理制度上进行彻底变化也是不现实的，那么怎么办？为了回归的大局，增加一种制度又何尝不可，一个国家，两种制度，这在政治上，是伟大的发明哦。

在软件设计模式中，这种不能修改，但可以扩展的思想也是最重要的一种设计原则，它就是开放-封闭原则(The Open-CloseedPrinciple，简称OCP)或叫开-闭原则。”

2.开放-封闭原则

小菜：“开放、封闭，具体怎么解释呢？”

开放-封闭原则，是说软件实体(类、模块、函数等等)应该可以扩展，但是不可修改。（ASD）

大鸟：“这个原则其实是有两个特征，一个是说'对于扩展是开放的(Openfor extension)’，另一个是说'对于更改是封闭的(Closed for modification)’（ASD）。”

大鸟：“我们在做任何系统的时候，都不要指望系统一开始时需求确定，就再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计的软件可以相对容易修改，不至于说，新需求一来，就要把整个程序推倒重来。

怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？开放-封闭给我们答案。”

小菜：“我明白了，你的意思是说，设计软件要容易维护又不容易出问题的最好的办法，就是多扩展，少修改？”

大鸟：“是的，比如说，我是公司老板，我规定，九点上班，不允许迟到。但有几个公司骨干，老是迟到。如果你是老板你怎么做？”

小菜：“严格执行考勤制度，迟到扣钱。”

大鸟：“你倒是够狠，但实际情况是，有的员工家离公司太远，有的员工每天上午要送小孩子上学交通一堵就不得不迟到了。”

小菜：“这个，让他们有特殊原因的人打报告，然后允许他们迟到。”

大鸟：“哈，谈何容易，别的不迟到的员工不答应了呀，凭什么他能迟到，我就不能，大家都是工作，我上午也完全可以多睡会再来。”

小菜：“那怎么办？老是迟到的确也不好，但不让迟到也不现实。家的远近，交通是否堵塞也不是可以控制的。”

大鸟：“仔细想想，你会发现，其实迟到不是主要问题，每天保证8小时的工作量是老板最需要的，甚至8小时工作时间也不是主要问题，业绩目标的完成或超额完成才是最重要的指标，于是应该改变管理方式，比如弹性上班工作制，早到早下班，晚到晚下班，或者每人每月允许三次迟到，迟到者当天下班补时间等等，对市场销售人员可能就更加以业绩为标准，工作时间不固定了。

这其实就是对工作时间或业绩成效的修改关闭，而对时间制度扩展的开放。”

小菜：“这就需要老板自己很清楚最希望达到的目的是什么，制定的制度才最合理有效。

大鸟：“对的，用我们古人的理论来说，管理需要中庸之道。”

3.何时应对变化

小菜：“啊，有道理。所以，我们尽量应在设计时，考虑到需求的种种变化，把问题想得全了，就不会因为需求一来，手足无措。”

大鸟：“哪有那么容易，如果什么问题都考虑得到，那不就成了未卜先知，这是不可能的。需求时常会在你想不到的地方出现，让你防不胜防。”

小菜：“那我们应该怎么做？”

大鸟：“开放-封闭原则的意思就是说，你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。”

小菜：“这可能做到吗？我深表怀疑呀，怎么可能写完一个类就再也不改了呢？”

大鸟：“你说得没错，绝对的对修改关闭是不可能的。无论模块是多么的'封闭’，都会存在一些无法对之封闭的变化。既然不可能完全封闭，

设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化[ASD]。”

小菜：“那还是需要猜测程序可能会发生的变化，猜对了，那是成功，猜错了，那就完全走到另一面去了，把本该简单的设计做得非常复杂，很不划算呀。而且事先猜测，这又是很难做到的。”

大鸟：“你说得没错，我们是很难预先猜测，但我们却可以

在发生小变化时，就及早去想办法应对发生更大变化的可能。也就是说，等到变化发生时立即采取行动（ASD）。

正所谓，同一地方，摔第一跤不是你的错，再次在此摔跤就是你的不对了。”

大鸟：“在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化（ASD）。

即面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码[ASD]。这就是'开放-封闭原则’的精神所在。”

大鸟：“

当然，并不是什么时候应对变化都是容易的。我们希望的是在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难（ASD）。”

小菜：“这个我能理解，如果加减运算都在很多地方应用了，再考虑抽象、考虑分离，就很困难。”

大鸟：“开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。

开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要（ASD）。切记，切记。”

小菜：“哦，我还以为尽量地抽象是好事呢，看来过犹不及呀。”

4.两手准备，全力以赴

大鸟：“回过头来说，你考研和求职这两件事，考研是你的追求，希望考上研究生，可以更上一层楼，有更大的发展空间和机会。所以考研之前，学习计划是不应该更改，雷打不动的。这就是对修改关闭。

但你要知道，你几个月来只埋头学习，就等于放弃了许多好公司来你们学校招聘的机会，这机会的失去是很不值得的。我就不信你一天到晚全在学习，那样效果也不会好。

所以你完全可以抽出一点时间，在不影响你复习的前提下，来写写自己的简历，来了解一些招聘大学生的公司的资讯，这不是很好的事吗？既不影响你考研，又可以增大找到好工作的可能性。为考研万一失败后找工作做好了充分的准备。这就是对扩展开放，对修改关闭的意义。”

小菜：“是的，我就不信，我会比别人差！”

大鸟笑了笑说：“好了，我回房间去了，你也早些休息吧。”

站起身走出了小菜的房门，此时 Beyond 的音乐再次响起，大鸟回头，伸出右手向前摆了个“V”字，说了声:“海阔天空，加油！”

“今天我寒夜里看雪飘过，怀着冷却了的心窝漂远方，风雨里追赶，雾里分不清影踪，天空海阔你与我可会变(谁没在变)，…………仍然自由自我，永远高唱我歌，走遍千里！”

（作者注:本故事和“开放-封闭原则”对应有些**牵强,**所以在此做一声明。全力以赴当然是必需，两手准备也是灵活处事的表现，希望读者您能对痛苦关闭，对快乐开放。）

拍摄UFO——单职责原则

1.新手机

大鸟小菜晚上晚饭过后，再外面散步。

大鸟：“小菜，刚换的手机感觉如何？”

小菜：“哈，当然是怎个爽字了得，可以听音乐、玩游戏、拍照、摄像，功能全着呢！”

大鸟：“你们这些小年轻，只会赶时髦，手机要那么多功能干吗？能打电话就可以了。”

小菜：”这你就不懂了吧，比如你出门旅游，数码相机一定要的吧，拍照是最起码的旅游需求；

有摄像机会更好，动的影像不是更有保留价值吗；

一路上无聊的时候，打打游戏总是需要的，游戏机要准备；

坐在大巴士上，看着窗外美景，听听音乐应该也属子正常需求吧，MP3一定要带着了；

有时或许还需要什么GPS来定定位，上网看看新闻，发发邮件，查查股票行情，这些求如何办，总不能带着笔记本电脑在路上跑吧。

这些东西且不说本身就很重，很麻烦，就说这些东西的充电器，就是五花八门，估计单就带这些东西，你就得累个半死了。”

大鸟：“你说得也没错，现在电子产品能玩的东西太多……”

小菜：”啊，大鸟！快看！“

2.拍摄

小菜惊呼，左手拉住大鸟的手，右手指向了天空。

大鸟跟着抬头一看，“那应该是架飞机吧！”

“不可能，”小菜坚决地说，“飞机哪有没翅膀的，那个东西飞得很奇怪，你看，你看，它停在空中，普通飞机怎么会在空中停下来。”

“是不太像飞机，飞碟？！——傻菜，快点用你手机录像呀！”

“是是是，啊，这手机怎么……等等，”小菜手忙脚乱。

“看你慌得，”大鸟说，“快些，马上可能就没了。”

“好了好了，”小菜终于打开了手机的摄像功能，对准了天空，“主要是对新功能不熟悉，你看，这家伙飞得多快。”

“嗯，它应该是飞碟，不然不可能这种样子的，以前也没有听说过这玩意，”大鸟肯定道，“还好你这手机可以摄像——啊，它飞跑了，你拍下来了没有？”

“好了，我都拍下来了，有点不太清楚，回去放电脑上看看吧。”小菜很开心，他的新手机发挥大作用了，“头一次看到 UFO，就拍到了，这下可是大新闻了。”

“是呀，我也头一次看到，我们太幸运了。”

3.没用的东西

回到家中。小菜将手机文件传入电脑。

”这什么呀，黑乎乎的，什么也看不清。”大鸟大为失望。

“那不是有一个小白点吗？”小菜想极力申辩。

“那白点就和液晶显示器里的坏点一样，这如何看得出是UFO呢，说给别人谁信呀。”

“害！是的。”小菜也承认了这个事实，“这手机拍出来的东西没办法看呀，根本算不上是UFO的证据。”

小菜拿起手机，一脸苦相，对着它说道：“狗屁，要你这么多功能有鸟用，关键时刻就萎掉，我砸……”小菜举起手机欲往地上砸去。

4.单一职责原则

“砸呀，你砸呀！”大鸟笑嘻嘻地看着小菜，“哼哼，我就知道你舍不得，不过你的手机的确是太没用，这么好的机遇，都没有录成，如果是摄像机，效果一定不会差，因为当时我们眼睛看得很清楚呀。这下说给谁，谁也不信呀！大多数时候，

一件产品简单一些，职责单一一些，或许是更好的选择。这就和设计模式中的一大原则——单一职责的道理是一样的。”

“哦，听字面意思，单一职责原则，意思就是说，功能要单一？”

“哈，可以简单地这么理解，它的准确解释是，就一个类而言，应该仅有一个引起它变化的原因（ASD）。

“是的，我写代码一般刚开始就是把所有的方法直接写在窗体类的代码当中的。”

“

单一职责原则(SRP)，就一个类而言，应该仅有一个引起它变化的原因。

5.方块游戏的设计

“我们再来举些例子，比如就拿手机里的俄罗斯方块游戏为例。要是让你开发这个小游戏，你如何考虑？”大鸟问道。

“我想想，首先它方块下落动画的原理是画四个小方块，擦掉，然后再在下一行画四个方块。不断地绘出和擦掉就形成了动画，所以应该要有画和擦方块的代码。然后左右键实现左移和右移，下键实现加速，上键实现旋转，这其实都应该是函数，当然左右移动需要考虑碰撞的问题，下移需要考虑堆积和消层的问题。”

“你能不能就这些代码划分一下类呢？”

“分类？ 这里好像关键在于各种事件代码如何写吧，这里有什么类可言呢？”

“看来你的面向过程开发已经根深蒂固了。你把所有的代码都写在了 Form1.cs 这个类里，你觉得这合理吗？”

“可能不合理，但我实在没想出怎么分离它。”

“你都已经说了，不能使用，我当然就没法使用了。Copy过去，再针对代码做些改进吧。“

“但这当中，有些东西是始终没变的。”

“你是说，下落、旋转、碰撞判断、移动、堆积这些游戏逻辑吧？”

“说得没错，这些都是和游戏有关的逻辑，和界面如何表示没有什么关系，为什么要写在一个类里面呢？

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏（ASD）。

事实上，你完全可以找出哪些是界面，哪些是游戏逻辑，然后进行分离。”

“但我还是不明白，如何分离开。”

“我知道了，

• 是否能左移，就是判断

  arraySquare[x,y]

  中的

  x-1

  是否小于 0，否则就撞墙了。或者

  arraySquare [x-1,y]

  是否等于1，否则就说明左侧有堆积的方块。
• 所谓堆积，不过是判断

  arraySquare [x,y+1]

  是否等于1的过程，如果是，则将自己

  arraySquare[x,y]

  的值改1。
• 那么消层，其实就是

  arraySquare [x,y]

  中循环x由0到9，判断

  arraySquare[x,y]

  是否都等于1，是则此行数据清零，并将其上方的数组值遍历下移一位。”

“那你就应该明白了，所谓游戏逻辑，不过就是数组的每一项值变化的问题，下落、旋转、碰撞判断、移动、堆积这些都是在做数组具体项的值的变化。

而界面表示逻辑，不过是根据数组的数据进行绘出和擦除，或者根据键盘命令调用数组的相应方法进行改变。

因此，至少应该考虑将此程序分为两个类，一个是游戏逻辑的类，一个是 WinFom 窗体的类。当有一天要改变界面，或者换界面时，不过是窗体类的变化，和游戏逻辑无关，以此达到复用的目的。”

“这个听起来容易，真正要做起来还是有难度的哦！”

“当然，软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离（ASD）。其实要去判断是否应该分离出类来，也不难，那就是

“

如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责[ASD]，就应该考虑类的职责分离。”

“的确是这样，界面的变化是和游戏本身没有关系的，界面是容易变化的，而游戏逻辑是不太容易变化的，将它们分离开有利于界面的改动。”

6.手机职责过多吗？

“这下你知道你的手机为什么不能拍摄好 UFO的原因了吧？”大鸟笑道。

“如果手机只用来接听电话，DV用来拍摄，职责的分离是可以把事情做得更好。不过这其实不是一回事哦，现在的智能手机承担的职责多，并不等于就不可以做好，只不过现在的科技还不能让手机在摄像时超过 DV 而已。”小菜分析说。

“整合当然是一种很好的思想。比如 Google 最初的理想就是将一切的需求都整合到一个文本框里提交，用干净的页面来吸引用户，导致互联网的一场变革。

但现在分类信息、垂直搜索又开始流行，这却是单一职责的思想体现。

现在智能手机整合了很多功能的原因是因为 DV、DC、MP3 等产品的体积也太大了。手机携带很方便，所以才有了这样的过渡产品，如果，每一样数码产品都缩小100倍，就像放在包里的一张卡片、一支笔那么简单，而功能和质量都不发生变化，你还会觉得它们很麻烦吗？”大鸟总结道，“总的来说，手机的发展有它的特点，

“

而编程时，我们却是要在类的职责分离上多思考，做到单一职责，这样你的代码才是真正的易维护、易扩展、易复用、灵活多样。”

引言

本文继续补充Kotlin集合高阶函数~

4.过滤操作符

• filter{...}

  : 过滤函数，返回满足指定条件的元素集合

• filterIndexed{...}

  : 与

  filter{}

  类似，在过滤时可以操作元素下标（

  index

  ）

• filterNot{...}

  : 与

  filter{}

  相反

• filterNotNull()

  : 返回集合中不为

  null

  的元素集合，也就是过滤掉集合中的

  null

  元素

• take(num)

  : 返回集合中前

  num

  个元素组成的集合（针对所有

  Iterable

  容器）

• takeWhile{...}

  : 循环遍历集合，从第一个元素开始遍历，当出现一个不满足条件的元素时，退出遍历，返回遍历过程满足条件的元素（针对所有

  Iterable

  容器）

• takeLast(num)

  : 返回集合中后

  num

  个元素组成的集合（针对

  List

  ）

• takeLastWhile{...}

  : 与

  takeWhile{...}

  类似，遍历是从最后一个元素开始（针对

  List

  ）

• drop(num)

  : 过滤集合中前

  num

  个元素，返回剩余元素（针对所有

  Iterable

  容器）

• dropWhile{...}

  : 循环遍历集合，从第一个元素开始遍历，当出现一个不满足条件的元素时，退出遍历，返回除遍历过程满足条件的元素外的剩余元素（针对所有

  Iterable

  容器）

• dropLast(num)

  : 返回集合中除后

  num

  个元素外的其他元素（针对

  List

  ）

• dropLastWhile{...}

  : 相同条件下，与

  takeLastWhile{...}

  得到的结果相反（针对

  List

  ）

• distinct()

  : 去除重复元素

• distinctBy{...}

  : 根据操作元素后的结果去重，返回的集合元素顺序与原集合保持一致

• slice

  : 按元素下标过滤元素

示例：

val list = listOf("a", "bc", "def", "g", "hijk", "lmn")println(list.take(2))  // [a, bc]println(list.takeWhile { it.length < 4 })  // [a, bc, def, g]println(list.takeLast(2))  // [hijk, lmn]println(list.takeLastWhile { it.length < 4 })  // [lmn]println(list.drop(2))  // [def, g, hijk, lmn]println(list.dropWhile { it.length < 4 })  // [hijk, lmn]println(list.dropLast(2))  // [a, bc, def, g]println(list.dropLastWhile { it.length < 4 })  // [a, bc, def, g, hijk]val list3 = listOf(1, 1, 2, 3, 3, 4, 5)println(list3.distinct())  // [1, 2, 3, 4, 5]println(list3.distinctBy { it % 2 })  // [1, 2]println(list3.slice(0..2)) // [1, 1, 2]println(list3.slice(listOf(2, 3, 4)))  // [2, 3, 3]

5.生产操作符

• plus()

  : 合并两个集合。对于可变集合，此操作会直接修改集合内容；对于不可变集合，它会返回一个新的合并后的集合。也可以使用符号

  +

• zip

  : 将两个集合的对应元素配对，形成一个新的集合，每个元素是一个

  Pair

  。如果两个集合长度不一致，结果集的长度将与较短的那个集合相同。

• unzip

  :与

  zip

  相反，将一个包含

  Pair

  的集合转换回两个集合。每个

  Pair

  的元素分别放入两个集合中。

• partition

  : 根据给定的条件将集合分为两个子集合：分别存放满足条件的元素和不满足条件的元素。

示例：

val list1 = listOf(1, 2, 3)val list2 = listOf(4, 5)val combined = list1 + list2 // combined 是 [1, 2, 3, 4, 5]val names = listOf("Alice", "Bob")val ages = listOf(24, 30)val nameAgePairs = names.zip(ages) // nameAgePairs 是 [("Alice", 24), ("Bob", 30)]val pairs = listOf("Alice" to 24, "Bob" to 30)val (namesList, agesList) = pairs.unzip() // namesList 是 ["Alice", "Bob"], agesList 是 [24, 30]val numbers = listOf(1, 2, 3, 4, 5)val (even, odd) = numbers.partition { it % 2 == 0 } // even 是 [2, 4], odd 是 [1, 3, 5]

6.统计操作符

• any()

  ,

  any{...}

  : 检查集合中是否有至少一个元素满足给定条件。无参数版

  any()

  用于判断集合是否非空。

val numbers = listOf(1, 2, 3, 4)val hasEven = numbers.any { it % 2 == 0 } // trueval isEmpty = listOf<Int>().any() // false

• all{...}

  : 检查集合中的所有元素是否都满足给定条件

val numbers = listOf(2, 4, 6, 8)val allEven = numbers.all { it % 2 == 0 } // true

• none()

  ,

  none{...}

  : 集合中是否所有元素都不满足给定条件。无参数版

  none()

  判断集合是否为空

val numbers = listOf(1, 3, 5)val noEven = numbers.none { it % 2 == 0 } // trueval isEmpty = listOf<Int>().none() // true

• max()

  ,

  maxBy{...}

  : 返回集合中的最大值。

  max()

  适用于

  Comparable

  类型的集合，

  maxBy{...}

  接受一个

  lambda

  表达式来确定比较标准

val numbers = listOf(1, 3, 2)val maxVal = numbers.maxOrNull() // 3val maxByAbs = numbers.maxBy { -it } // 1，这里取负数，所以实际是最小值的绝对值最大

• min()

  ,

  minBy{...}

  : 类似于

  max()

  和

  maxBy{...}

  , 但用于找到最小值

val numbers = listOf(1, 3, 2)val minVal = numbers.minOrNull() // 1

• sum()

  ,

  sumBy{...}

  ,

  sumByDouble{...}

  : 计算集合元素的总和。

  sum()

  用于数值类型集合的直接求和。

  sumBy{...}

  和

  sumByDouble{...}

  则用于根据提供的函数计算总和

val numbers = listOf(1, 2, 3)val directSum = numbers.sum() // 6val mappedSum = numbers.sumBy { it * 2 } // 12

• average()

  : 计算集合中数值的平均值

val numbers = listOf(1.0, 2.0, 3.0)val avg = numbers.average() // 2.0

• reduce{...}

  ,

  reduceIndexed{...}

  ,

  reduceRight{...}

  ,

  reduceRightIndexed{...}

  :  对集合元素进行累积操作，可以自定义累积逻辑。

  reduceRight{...}

  和

  reduceRightIndexed{...}

  是从右到左累积

val numbers = listOf(1, 2, 3)val product = numbers.reduce { acc, i -> acc * i } // 6, 累乘val rightSum = numbers.reduceRight { acc, i -> acc + i } // 6, 从右到左累加

• fold{...}

  ,

  foldIndexed{...}

  ,

  foldRight{...}

  ,

  foldRightIndexed{...}

  : 类似于

  reduce

  ，但第一个参数可以指定初始值。

  foldRight

  系列也是从右向左折叠。

val numbers = listOf(1, 2, 3)val foldedWithInit = numbers.fold(10) { acc, i -> acc + i } // 16, 初始值10，累加

引言

作为一名前Java开发者，当我每次需要写一些冗长且常用的功能时，时常会发出这样的感叹：

这个功能JDK中怎么没有啊？每次都要写好几十行代码，JDK不应该把这个功能封装一下吗

不知道广大的Java开发者是否也会跟我一样，也会有类似的感慨，欢迎大家留言讨论。

在用了Kotlin之后，才知道什么才是真正的方便，其针对集合做了非常丰富的支持：排序、查询、条件过滤、类型转换等等，本文就盘点一下Kotlin中集合的一些骚操作。

Collection结构

• 一个 只读 接口，只提供访问集合元素的操作。

• 一个 可变 接口，通过写操作扩展相应的只读接口：添加、删除及更新其元素。

每种容器类型都有可变与不可变之分，可变的是不可变的子类，如：

MutableCollection

会实现对应的

Collection

接口（如下图）

集合操作

集合的高阶操作大致可分为六类：

• 元素操作符

• 顺序操作符

• 映射操作符

• 过滤操作符

• 生产操作符

• 统计操作符

1.元素操作符

• componentX()

  ：获取集合中的某一个元素，其中的

  X

  只能取

  1..5

  ，其是

  List

  的扩展函数

• contains(element: T)

  : 集合中是否包含指定的元素，若存在则返回

  true

  ，反之返回

  false

• elementAt(index: Int)

  : 获取对应下标的元素。若下标越界，会抛出

  IndexOutOfBoundsException（下标越界）

  异常，与

  get(index)

  一样

• elementAtOrElse(index: Int, defaultValue: (Int) -> T)

  : 获取对应下标的元素。若下标越界，返回默认值，此默认值就是你传入的下标的运算值

• elementAtOrNull(index)

  : 获取对应下标的元素。若下标越界，返回

  null

• first()

  : 获取第一个元素，若集合为空集合，这会抛出

  NoSuchElementException

  异常

• first{}

  : 获取满足条件的第一个元素。若不满足条件，则抛出

  NoSuchElementException

  异常

• firstOrNull()

  : 获取第一个元素，若集合为空集合，返回

  null

• firstOrNull{}

  : 获取满足条件的第一个元素。若不满足条件，返回

  null

• getOrElse(index,{...})

  : 同

  elementAtOrElse

• getOrNull(index)

  : 同

  elementAtOrNull

• last()

  : 与

  first()

  相反

• last{}

  : 与

  first{}

  相反

• lastOrNull{}

  : 与

  firstOrNull()

  相反

• lastOrNull()

  : 与

  firstOrNull{}

  相反

• indexOf(T)

  : 返回指定元素的下标，若不存在，则返回

  -1

• indexOfFirst{...}

  : 返回第一个满足条件元素的下标，若不存在，则返回

  -1

• indexOfLast{...}

  : 返回最后一个满足条件元素的下标，若不存在，则返回

  -1

• single()

  : 若集合的长度等于

  0

  ,则抛出

  NoSuchElementException

  异常，若等于

  1

  ，则返回第一个元素。反之，则抛出

  IllegalArgumentException

  异常

• single{}

  : 找到集合中所有满足条件的元素，若找到的元素个数为1，则返回该元素。否则会根据不同的条件，抛出异常（与

  singel()

  一致）

• singleOrNull()

  : 与

  single()

  类似，但不会抛出异常，会返回

  null

• singleOrNull{}

  : 与

  single{}

  类似，但不会抛出异常，会返回

  null

• forEach{...}

  : 遍历元素本身

• forEachIndexed{index,value}

  : 遍历下标及元素

看到这里，你是不是想说，Kotlin就这？

稍安勿躁！

接着往下看~

2.顺序操作符

• reversed()

  : 反转集合。

• sorted()

  : 自然升序。

• sortedBy{}

  : 有条件的升序（不满足条件的放在前面，满足条件的放在后面）

• sortedDescending()

  : 自然降序。

• sortedByDescending{}

  : 有条件的降序（不满足条件的放在后面，满足条件的放在前面），与

  sortedBy{}

  相反

• sortedWith(comparator:

  Comparator

  <

  in

  T)

  ：自定义比较器

3.映射操作符

• map{...}

  : 把每个元素按照特定的方法进行转换，组成一个新的集合

• mapNotNull{...}

  : 与

  map{}

  函数的作用相同，但会过滤掉转换之后为

  null

  的元素

• mapIndexed{index,result}

  : 与

  map{}

  函数的作用相似，但在转换过程中可以拿到每个元素的下标，最终也会组成一个新的集合

• mapIndexedNotNull{index,result}

  : 与

  mapIndexed{}

  函数的作用相同，但会过滤掉转换之后为

  null

  的元素

• <T, R> Iterable<T>.flatMap(transform: (T) -> Iterable<R>): List<R>

  : 可分为flat和map两个步骤，flat可以将集合扁平化处理，map可以对集合进行转换。该函数在处理集合嵌套层级很多的情况很实用，可以很大程度上简化操作

• <T, K> Iterable<T>.groupBy(keySelector: (T) -> K): Map<K, List<T>>

  : 对集合进行分组。你需要传一个key，函数会根据条件把集合拆分为为一个

  Map<K,List<T>>

  类型的集合

示例：

val numbers = listOf(1, 2, 3, 4)val squared = numbers.map { it * it }// squared 是 [1, 4, 9, 16]，每个数字被平方val mixedValues = listOf("1", "two", "3", "four")val integers = mixedValues.mapNotNull { it.toIntOrNull() }// integers 是 [1, 3]，只有可以转换为整数的字符串被保留val words = listOf("apple", "banana", "cherry")val indexedWords = words.mapIndexed { index, word -> "$index: $word" }// indexedWords 是 ["0: apple", "1: banana", "2: cherry"]，每个单词前加上了它的索引val data = listOf("some", "", "text", "none", "here")val nonEmptyItems = data.mapIndexedNotNull { _, value -> if (value.isNotBlank()) value else null }// nonEmptyItems 是 ["some", "text", "none", "here"]，过滤掉了空字符串val nestedLists = listOf(listOf(1, 2), listOf(3), listOf(4, 5, 6))val flatList = nestedLists.flatMap { it }// flatList 是 [1, 2, 3, 4, 5, 6]，将嵌套的列表展平val people = listOf("Alice", "Bob", "Charlie", "David", "Eve")val byFirstLetter = people.groupBy { it.first() }// byFirstLetter 是 {'A'=["Alice"], 'B'=["Bob"], 'C'=["Charlie"], 'D'=["David"], 'E'=["Eve"]}，按名字首字母分组

到此，阁下该如何应对？

篇幅太长，下一章讲集合的过滤操作符、生产操作符及统计操作符。

一、项目导入

implementation(group = "de.fraunhofer.aisec", name = "cpg-core", version = cpgVersion)implementation(group = "de.fraunhofer.aisec", name = "cpg-language-java", version = cpgVersion)

二、cpg调用

1.使用方式

TranslationConfiguration

构建

fun testNullPointer() {    val config =        TranslationConfiguration.builder()            .sourceLocations(File("src/test/resources/Array.java"))            .defaultPasses()            //                .registerLanguage<JavaLanguage>()            .build()    val analyzer = TranslationManager.builder().config(config).build()    val result = analyzer.analyze().get()    NullPointerCheck().run(result)}

• sourceLocations

进入该方法

可以发现，参数是待分析的源码/源码所在目录，

• defaultPasses

进入该方法

• registerLanguage（被注释）

进入该方法

可以看到，其可以指定待分析项目的语言，其支持的语言有这么多~

另外，其还支持自定义语言，大概步骤如下：

要支持一种新的编程语言，你需要执行以下步骤：

1. 提供一种新的语言定义。在这个阶段，你需要考虑该编程语言的特点以及它必须实现哪些

   LanguageTraits

   （语言特征）。通过这种方式，你可以对该语言进行精细化调整，确保各个分析流程（Passes）能够正确运作。
2. 实现一个新的

   LanguageFrontend

   。当遇到匹配新语言的文件时，这个前端将会被执行。前端的要求已经在上面详细描述过。
3. 为了让CPG能够使用新添加的前端，你需要相应地配置翻译过程。这是通过

   TranslationConfiguration

   来完成的，在此配置中，你需要通过调用其中一个

   registerLanguage()

   方法来注册你的新语言，以便于CPG能够识别并使用针对新语言的前端进行源代码到代码属性图的转换。示例如下：

val config: TranslationConfiguration = TranslationConfiguration    .builder()    // More configuration    .registerLanguage(MyNewLanguage()) // Option 1    .registerLanguage<MyOtherNewLanguage>() // Option 2    .registerLanguage("MyThirdNewLanguage") // Option 3    .build()

2.TranslationConfiguration解析

高能预警！！！高能预警！！！高能预警！！！

1.symbols

2.softwareComponents

3.topLevel

通常是待分析项目的根目录。其可以为null

4.debugParser

5.failOnError

6.loadIncludes

7.includePaths

头文件目录列表（针对C++）。这是解析器查找头文件的目录集合，确保符号能够正确解析。

8.includeWhitelist

头文件白名单（针对C++）。非空情况下，只有指定列表中的头文件会被解析和加入到CPG中，除非它同时出现在黑名单中。支持相对路径。

9.includeBlocklist

头文件黑名单（针对C++）。非空情况下，指定的头文件不会被解析，也不会加入CPG节点中，黑名单优先于白名单。

10.passes

What is a Pass?

Passes get a prebuilt CPG that at least contains the CPG-AST and output a modified graph. Their purpose is to extend the syntactic representation of code with additional nodes and edges to represent the semantics of the program. Passes can be executed in sequence, where the output of the previous pass serves as input of the next pass.

解释：

Passes

接收一个预构建的

CPG

，其中至少包含了

CPG-AST

（代码属性图抽象语法树），并输出一个经过修改的图。它们的目的是通过添加额外的节点和边来扩展代码的句法表示，从而体现程序的语义。这些

Pass

可以按照序列执行，前一个Pass的输出结果作为下一个Pass的输入。

• DependsOn(other: KClass<out Pass>, softDependency: Boolean = false)

  -- The annotated pass is executed after the other pass(es). If

  softDependency

  is set to

  false

  , it automatically registers these passes if they haven't been registered by the user.

• ExecuteBefore(other: KClass<out Pass>, ...)

  -- The annotated pass is executed before the other pass(es) specified.

• ExecuteFirst

  -- The annotated pass is executed as the first pass if possible.

• ExecuteLast

  -- The annotated pass is executed as the last pass if possible.

• RequiredFrontend(frontend: KClass<out LanguageFrontend>)

  -- The annotated pass is only executed if the frontend has been used.

11.replacedPasses

12.languages

支持的语言列表，包括相应的前端解析器。

13.codeInNodes

CPG节点中是否包含源代码片段。默认true

14.processAnnotations

是否处理源代码中的注解。默认 false

15.disableCleanup

是否禁用解析后的TypeManager内存清理步骤。默认false，测试时才可以打开。

16.useUnityBuild

是否启用统一构建模式。默认为false，仅针对C++。

在这种模式下，所有的翻译单元会被合并成单一的一个，从而避免重复处理头文件，降低向图中添加重复节点的情况。

17.useParallelFrontends

是否使用多线程并发处理不同的语言前端。 默认fasle

18.useParallelPasses

是否开启Pass并行执行，加速分析速度。默认false

19.inferenceConfiguration

推断配置对象，控制对未知节点的推断策略。

默认如下：

private var inferenceConfiguration = InferenceConfiguration.Builder().build()

19.1.enabled

在整个系统中开启推断模块

19.2.guessCastExpressions

启用对强制转换表达式与调用表达式的智能猜测。仅针对C/C++。

19.3.inferRecords

是否推断record声明（类声明）。

19.4.inferFunctions

是否推断方法声明。

19.5.inferVariables

是否推断变量，例如全局变量。

19.6.inferDfgForUnresolvedSymbols

是否将方法调用表达式的DFG边添加到未解析的函数中。（例如：在给定的源代码中没有方法的实现）

20.compilationDatabase

编译数据库，可选参数，提供编译信息以辅助解析。  默认为 null

21.matchCommentsToNodes

是否采用启发式方法将源文件中找到的注释与其最近的AST节点匹配，并将注释保存在节点的注释属性中。

默认false

22.addIncludesToGraph

是否将头文件包含关系添加到CPG中（针对C++）。 默认true

23.passConfigurations

推荐阅读

代码属性图CPG系列文章（白盒/静态代码分析方向）：超万字的详细讲解，文章理论与实践相结合，示例代码可拿来即用，通俗易懂，这样的文章你爱了吗！ 

• 抽丝剥茧代码属性图CPG-第一弹：CPG介绍

• 抽丝剥茧代码属性图CPG-第四弹：CPG中的DFG-3

• SAST-短小精悍的Benchmark

能够看到这篇文章，就是我们的缘分，坚持输出优质内容是笔者一直在做的事情。若文章对你有帮助，感谢点个免费的 点赞、在看，大家的鼓励是我最大的动力

点个关注，不后悔

引言

CPG中的DFG系列共分为三篇，三篇文章加起来将近10000字了，针对每个表达式类型都做了非常详尽的讲解，内容已经非常全面且细致了，绝对值得一读，先放个链接哈，想要学习的同学可直接点击链接跳转哈：

• 抽丝剥茧代码属性图CPG-第二弹：CPG中的DFG-1

• 抽丝剥茧代码属性图CPG-第三弹：CPG中的DFG-2

• 抽丝剥茧代码属性图CPG-第四弹：CPG中的DFG-3

但笔者转念一想，想要从这么多内容中提取要点（或者自己关注的点）还是需要点功夫的，所以嘞，笔者就以自己粗浅的开发经验，从如何利用CPG中的DFG做开发工作的角度，总结一下常见的使用场景，方便大家更快地理解掌握重点（若对总结的要点有疑惑的，可以点击文章底部合集标签代码属性图CPG，去对应的文章中找详细的介绍）

tips：本文几乎不会讲解新的内容，本文是一个精简版，是对前文CPG中的DFG的提炼，若对这块很熟的同学可以忽略哈~

OK，正文开始~

DFG常见使用场景总结

1.CPG运行逻辑回顾

CPG的运行逻辑图回顾：

tips: Data Flow Graph 对应源码中的

DFGPass

，Control-Flow Sensitive Data Flow Graph 对应源码中的

ControlFlowSensitiveDFGPass

• DFGPass

  依赖

  SymbolResolver

• SymbolResolver

  依赖

  TypeResolver

  ，

  TypeHierarchyResolver

  ，

  EvaluationOrderGraphPass

• TypeHierarchyResolver

  依赖

  TypeResolver

• TypeResolver

  ，

  EvaluationOrderGraphPass

  不需要依赖其他Pass

这些Pass间的依赖关系与图中从左到右的顺序是对应的，大家可直接看图，比较直观

2.CallExpression之Known function

DFG边：

• CallExpression的实参流向被调用方法的形参

• 被调用方法的声明流向CallExpression

3. AssignExpression

DFG边：

• rhs 流向 lhs

4.Reference之ControlFlowSensitiveDFGPass

一元操作符(

++

,

--

)及复杂二元操作符(

+=

、

-=

、

*=

、

/=

)此处不作总结。

DFG边：

• 变量声明：initializer  -->  VariableDeclaration

• 变量读取：当前读取语句之前的最后一次写入 --> 当前读取

tips:若在变量读取前有分支语句，并且if块和else块内都有对变量的写入操作，CPG会将if块和else块的变量写入语句都流向当前的变量

• 变量简单赋值(operatorCode为

  =

  )：

• rhs --> lhs

• lhs --> next read access of reference

5.MemberExpression

成员表达式（MemberExpression）关注以下字段：

• base: Expression

  : 被访问字段所属的对象表达式

• refersTo: Declaration?

  : 被访问字段的声明，如果源码中未实现相应的类，则该字段为

  null

DFG边：

• refersTo != null

• MemberExpression

  是

  Reference

  的子类，若其

  refersTo

  字段不为

  null

  ，那么其处理方式与

  Reference

  一致

• refersTo == null

• base --> MemberExpression

6.ForStatement

• condition: Statement

  : for循环的条件

• conditionDeclaration: Statement

  : 条件声明语句

DFG边：

• condition --> ForStatement

• conditionDeclaration --> ForStatement

7.IfStatement

• condition: Statement

  : if语句的条件

• conditionDeclaration: Statement

  : 条件声明语句

DFG边：

• condition --> IfStatement

• conditionDeclaration --> ForStatement

技术交流群

进群方式：

1.点击公众号菜单栏"点击进群"，加笔者好友（备注进群）-- 推荐

2.扫码进群

引言

在当今快速发展的数字化时代，确保软件应用的安全性成为了企业不可忽视的首要任务。各种软件安全测试技术发挥着重要的作用。其中，SAST（Static Application Security Testing）、DAST（Dynamic Application Security Testing）、IAST（Interactive Application Security Testing）以及RASP（Runtime Application Self-Protection）构成了现代应用程序安全测试的四大支柱。

SAST，静态代码分析，能够在代码提交之前深入挖掘潜在的安全隐患，为开发初期筑起第一道防线。DAST通过模拟真实攻击场景，对运行中的应用程序进行渗透测试，有效检测出暴露在外的漏洞。而IAST，则如同一位内置于应用的侦察兵，通过代码插桩技术在运行时动态监测，提供即时且精准的漏洞反馈，极大地提升了测试效率。RASP技术以其独特的运行时自我保护机制，直接嵌入应用程序内部，实现实时监控与主动防御，为应用程序穿上了一层隐形的“防弹衣”。

这四大技术各有所长，相互补充，共同构建了一个多层次、全方位的安全防护体系，助力企业在不断变化的安全威胁面前，保持韧性，确保软件质量和用户数据的安全。

什么是SAST？

SAST（Static Application Security Testing ，又称“白盒工具”），是用来扫描源代码或二进制文件中的安全缺陷的工具，扫描结果通常会包含漏洞描述信息、修复建议、相关标准等， 大部分SAST工具会提供CI/CD集成服务，可无缝衔接至软件开发生命周期内，在软件的开发阶段提升软件的安全性及可靠性。

SAST的优势

• 在软件开发阶段就发现潜在漏洞，漏洞修复的成本较低

• 自动化分析项目的所有源代码，比人工审计速度更快

• 无需真正运行程序就可分析，可在软件上线之前完成

• 输出可读性较高的分析报告（漏洞的确切位置信息、完整调用链等），帮助开发人员快速审计定位问题

• 提供漏洞审计功能，可对漏洞进行自定义标记

SAST的劣势

• 误报率较高（静态分析无法完全模拟程序的动态执行过程）

• 使用门槛较高、维护不易

• 业务逻辑漏洞分析能力几乎为零

• 没有一套标准/Benchmark测试集去完美定义SAST工具的能力

什么是DAST？

DAST（Dynamic Application Security Testing，动态应用程序安全测试）是一种安全测试方法，它通过模拟真实世界攻击的方式，在应用程序运行时检测安全漏洞。DAST不依赖于应用程序的源代码，而是直接对正在运行的应用程序进行黑盒测试，重点在于发现外部攻击者可能利用的弱点。

DAST的优势

• 贴近实战：DAST模拟了实际攻击场景，能够检测到运行时的安全问题，如输入验证问题、会话管理漏洞、配置错误等，这些是真实世界攻击者可能利用的漏洞。

• 技术无关性：DAST独立于应用程序的技术栈和平台，无需了解应用程序的内部结构或源代码，适合多种技术和环境下的应用测试。

• 误报率较低：相较于SAST，DAST通常因直接测试应用行为而非源代码逻辑，而导致的误报较少，测试结果往往更具有操作性。

• 复杂架构适应性：DAST能够测试由多个组件、微服务和第三方系统组成的复杂应用架构，特别是对于那些难以通过静态分析检测的部分特别有效。

• 集成SDLC：DAST可以集成到软件开发生命周期（SDLC）中，作为持续集成/持续部署（CI/CD）流程的一部分，帮助在部署前发现并修复安全问题。

DAST的劣势

• 覆盖范围限制：DAST依赖于应用程序的可访问性，可能无法测试到所有代码路径或深层次的逻辑问题，尤其在没有实际用户交互的场景下。

• 资源消耗：由于DAST在应用程序运行时进行，可能需要更多的资源和时间来完成全面的安全测试，尤其是对于大型或复杂应用。

• 定位问题难度：DAST通常不能精确定位到导致安全漏洞的具体代码行，修复漏洞时可能需要额外的调试和分析工作。

• 环境依赖：为了进行全面测试，DAST可能需要在尽可能接近生产环境的条件下进行，这可能导致测试环境搭建复杂度增加。

SAST与DAST对比

特性	SAST（静态应用安全测试）	DAST（动态应用安全测试）
测试时机	在代码编写阶段，无需运行应用程序	在应用程序运行时进行，通常在部署后的环境中
测试对象	源代码或字节码	应用程序的运行实例，包括Web服务、API等
测试方法	静态分析，基于规则和算法检查代码逻辑	动态分析，模拟黑客攻击，探测运行时行为
漏洞发现	逻辑错误、设计缺陷、编码不良实践	输入验证、认证与授权漏洞、配置错误、网络层面漏洞
误报与漏报	可能有较高误报率，需人工复审	误报较低，但可能漏报某些仅在特定条件下触发的漏洞
覆盖范围	深入代码内部，包括未执行路径	侧重于可到达路径，对实际执行逻辑的测试
实施成本	高，需要配置和维护复杂规则集	较低，易于设置，但需准备测试环境
集成程度	通常集成在CI/CD管道中，支持早期发现	可作为后期安全审计或持续监控的一部分
技能要求	需要对编程语言和安全规则有深入了解	更侧重于渗透测试技能，理解攻击面和漏洞利用
适用阶段	开发初期，代码审查阶段	开发后期，测试、部署及生产环境监控阶段

SAST和DAST各有侧重，SAST更偏向于代码质量和逻辑层面的安全问题，适合在开发早期发现并修复潜在漏洞；而DAST则更接近于真实攻击场景，专注于发现运行时和外部接口暴露的安全问题。

什么是IAST？

IAST（Interactive Application Security Testing，交互式应用程序安全测试）是一种安全测试技术，它结合了SAST（静态应用安全测试）和DAST（动态应用安全测试）的优点，提供了一种在应用程序运行时检测安全漏洞的新方法。IAST通过在应用程序内部植入（或插桩）探针来实时监测代码执行情况，可以在应用程序执行的同时识别潜在的安全问题。

IAST的优势

• 高准确性和低误报率：IAST工具在应用程序的实际执行环境中运行，能够更准确地识别漏洞，因为它基于真实的运行时数据和上下文。这大大降低了误报率，使得安全团队能够集中精力处理真正的问题。

• 深入检测：由于IAST在应用程序内部工作，它能够检测到深层次的逻辑问题和业务逻辑漏洞，这些往往是SAST和DAST难以发现的。

• 即时反馈：IAST能够提供即时的漏洞报告，使得开发人员可以在开发过程中快速识别并修复安全问题，加速了安全问题的修复周期。

• 集成DevOps：IAST工具设计为无缝集成到CI/CD流程中，支持自动化测试，有助于实现安全左移，即在软件开发生命周期的早期阶段就发现并解决安全问题。

• 广泛覆盖：支持对Web应用、API、AJAX页面、CSRF token页面、验证码页面等多种场景进行深度测试，包括对加密接口和防重放攻击的检测。

IAST的劣势

• 性能影响：因为需要在应用程序内部植入探针，可能会对应用的运行性能产生一定影响，尤其是在大规模或高性能要求的应用中。

• 支持范围：虽然IAST技术日益成熟，但它对编程语言和框架的支持仍然有限，尤其是某些特定或较新的技术栈可能无法得到很好的支持。

• 实施复杂性：相对于DAST，IAST的部署和配置可能更为复杂，需要在代码中植入探针，对开发和运维团队有一定的技术要求。

• 成本问题：高级的IAST工具和服务可能会带来较高的成本，尤其是对于小型企业和预算有限的项目来说，这可能是一个考虑因素。

什么是RASP？

RASP（Runtime Application Self-Protection，运行时应用自我保护）是一种先进的安全技术，它将安全防护机制直接嵌入到应用程序内部，使其能在运行时自我监控并防御各种安全威胁。RASP通过在应用程序代码中植入代理或探针，能够实时分析应用程序的行为和数据流，识别并阻止恶意活动，比如SQL注入、跨站脚本(XSS)攻击、命令注入等。

RASP的优势

• 深度防护：RASP因为嵌入到应用程序内部，能直接观察和控制程序的执行流程，因此能够提供更深入、更精确的安全防护，包括识别和防御复杂的逻辑漏洞。

• 即时响应：一旦检测到攻击，RASP能够立即采取行动，比如阻止攻击、记录攻击信息或采取其他防护措施，减少损害。

• 低误报率：相比WAF（Web Application Firewall）等外部防护措施，RASP由于能够理解应用程序的上下文，误报率较低，减少了对正常流量的干扰。

• 防护未知漏洞：RASP有能力检测和防御0-day漏洞，因为它是基于应用程序的行为和上下文来判断是否为攻击，而不是依赖于已知攻击模式。

RASP的劣势

• 性能影响：由于RASP需要监控和分析所有应用程序的运行时行为，可能会对应用性能造成一定影响，尤其是在高负载情况下。

• 兼容性和支持：不同的应用程序框架和语言可能需要定制化的RASP实现，这可能导致兼容性问题，且并非所有技术栈都能找到合适的RASP解决方案。

• 实施复杂性：虽然RASP旨在简化安全集成，但其部署和配置可能相对复杂，尤其是对于大型或复杂应用，需要细致的规划和调整。

• 内部威胁限制：RASP在应对源自应用程序内部的攻击或有权限的恶意用户时，防护能力可能受限，因为它依赖于应用自身的执行环境。

• 潜在的稳定性风险：作为应用程序的一部分，RASP组件自身也可能引入错误或稳定性问题，需要谨慎选择和测试。

PDG定义

维基百科对PDG的定义

In computer science, a Program Dependence Graph (PDG) is a representation of a program's control and data dependencies. It's a directed graph where nodes represent program statements, and edges represent dependencies between these statements. PDGs are useful in various program analysis tasks, including optimizations, debugging, and understanding program behavior.These dependencies are used during dependence analysis in optimizing compilers to make transformations so that multiple cores are used, and parallelism is improved. Nodes and edges in a PDG may have attributes associated with them, representing variables read from or written to, or the type of dependency they represent. PDGs are used in data flow analysis, slicing, optimization, debugging, and parallelization, providing insights into how program components interact and aiding in understanding and analyzing program behavior.

解释：

在计算机科学中，程序依赖图（PDG）是程序的 控制依赖 和 数据依赖 关系的表示。它是一个有向图，其中节点表示程序语句，边表示语句之间的依赖关系。PDG 在各种程序分析任务中非常有用，包括优化、调试和理解程序行为。在优化编译器的依赖分析期间使用这些依赖关系进行转换，以便使用多个内核，并提高并行执行效率。PDG 中的节点和边可能具有与其关联的属性，表示变量读取或写入、依赖关系类型等。PDG 用于数据流分析、程序切片、程序优化、调试及并行优化，为理解程序语义提供一种直观的表示形式，有助于理解和分析程序行为。

官方的解释如上，需要注意的是，程序依赖图PDG包含两部分，控制依赖图（CDG：Control Dependency Graph ）和数据依赖图（DDG：Data Dependency Graph），分别表示程序语句间的控制依赖关系（如：对于if语句来说，then语句控制依赖于条件判断语句）和数据依赖关系（数据流图中变量间的边指向关系）。

举两个栗子

• 代码块1

if (A) then  // S1    B = C * D  // S2endif

S2语句执行与否取决于S1语句的判断结果，这时，我们称S2控制依赖于S1

• 代码块2

A = B * C  // S1D = A * E + 1  // S2

在S2语句中，对S1语句中的变量A进行了读取，这时，我们称S2数据依赖于S1

Ok，看完两个简单的例子，对控制依赖和数据依赖大概有一个具象化的了解，然后就可以看定义了，在讲数据依赖（DDG）之前，需要先了解一下定义可达性分析算法。

预备知识

定义可达性分析

定义可达性分析也叫Reaching Definitions Analysis

定义

A definition d at program point p reaches a point q if there is a path from p to q such that d is not “killed” along that path

解释：

在程序点 p 处有一个变量的定义 d，如果有一条控制流路径可以从程序点 p 到达 程序点 q，并且在这条路径上定义 d 没有被 “kill” 掉（也就是定义 d 没有被重新覆盖掉），那么就称 p 处的定义 d 可以到达 q（定义 d 可达q）。

分析每个程序点处可以到达的定义的过程 称为 定义可达行分析。

DDG

数据依赖图DDG（Data Dependence Graph）针对的对象是Statement（程序语句）

（参考论文 Christian Hammer 写的 Static Program Analysis Program Dependence Graph，感兴趣的同学可以直接看原文）

Data Dependence定义

• Known from optimizing compilers

• For slicing only “flow dependence” is relevant

• Called data dependence in the sequel

• x → dd y means that a node x computes a value that may be used at node y in some feasible execution

• A node y is data dependent on node x (x →dd y) if

• there exists a variable v with v ∈ Def(x) and v ∈ Use(y),

• and ∃ path P in the CFG from x to y where the definition of v in x is not definitively killed (i.e. x is a reaching definition of y.)

通过定义我们可以知道，程序中的节点x数据依赖于节点y（针对变量v来说），需要满足以下条件：

1.在节点x处对变量v进行了定义，在节点y处对变量v进行了使用

2.从节点x到节点y，存在一条CFG路径，并且在这条CFG路径上没有对变量v重新赋值（not kill）

上文已经讲了定义可达性分析（Reaching Definitions Analysis）的原理，数据依赖图（DDG）的构建过程其实就可以理解为 对每个程序节点的定义做可达性分析的过程。

CDG

控制依赖图CDG（Control Dependence Graph）针对的对象是Statement（程序语句）

Control Dependence定义：

程序天然存在的控制依赖关系

• One statement directly controls the execution of another

• In structured programs equivalent to “indentation level”

while(i<n=) {    sum = sum + i;    prod = prod * i;    i++;}write(sum);

• Statements in the while body are control dependent on the while predicate. The write is no longer dependent on the predicate.

解释：

• 前后语句之间的控制依赖（这也是一种天然的控制流）

• 类似while缩进格式的语句块的控制依赖：while循环体控制依赖于while条件

Post-Dominators控制依赖

Control Dependence Formally

• Standard definition in terms of post-dominance

• A node x in the CFG is post-dominated by node y if all paths from x to exit node pass through y

• A node y is control dependent on node x (x →cd y) if

• ∃ path p from x to y in the CFG, such that y postdominates every node in p (except for x), and

• x is not post-dominated by y

解释：

通过前向支配树（FDT）确定控制依赖关系：

• CFG中的节点x被节点y前向支配：从节点x到程序出口的所有路径都经过y

• 节点x被节点y控制依赖 (x →cd y)：

• 在CFG上存在一条从x到y的路径，在这条路径上，y前向支配 除x外 的所有其他节点

• x不被y前向支配

小剧场（可忽略）：

这块尽力理解了，本想着自己用”人话“解释一下这个定义，但实在是太难了555，希望有懂这方面的大佬在技术交流群里解答一下，或者通过公众号与作者私聊，感谢！

测试代码

package com.test.pdg;import java.io.IOException;public class TestPDG2 {    public void test(Integer n) {        read(n);        int i = 1;        int sum = 0;        int prod = 1;        while (i <= n) {            sum = sum + i;            prod = prod * i;            i++;        }        write(sum);        write(prod);    }    public Integer read(Integer n)  {        try {            n = System.in.read();        } catch (IOException e) {            throw new RuntimeException(e);        }        return n;    }    public void write(Integer n) {        System.out.println(n);    }}

tips：此处暂时就只把论文中提到的结果展示出来，供大家参考。笔者尝试本地做测试，想通过直观的图形化展示生成的结果，但由于cpg框架自身的实现不完善以及本人对neo4j的Cyber命令不是很熟（555，努力进修中），所以最终呈现结果就会显得很乱，基于此，以防混淆视听，就不再做展示啦，感谢大家的理解。

（文末会展示暂时的生成效果，大家有什么更好的解决办法可以多多提哈，感谢~）

DDG结果

CDG结果

Post-dominator Tree

CDG

杂乱的cpg

Tips:测试代码与上文一致

红色边：PDG

蓝色边：DFG

绿色边：CDG

引言

语言前端在对源码进行转换后，生成AST，然后转换为一种初步的CPG格式数据，这种初步的CPG数据在Pass阶段经过一系列的操作，丰富CPG的节点及边的信息，我们本文要讲的EOG（Evaluation Order Graph）评估顺序图就是Pass阶段的一环，EOG在Pass阶段处于相对靠前的位置，之前讲到的ControlFlowSensitiveDFGPass（数据流图构建）、以及日后要讲的ControlDependenceGraphPass（控制依赖图构建）都要依赖于EOG去做。

一、EOG概念

The Evaluation Order Graph (EOG) is built as edges between AST nodes after the initial translation of the code to the CPG. Its purpose is to follow the order in which code is executed, similar to a CFG, and additionally differentiate on a finer level of granularity in which order expressions and subexpressions are evaluated. Every node points to a set of previously evaluated nodes (prevEOG) and nodes that are evaluated after (nextEOG). The EOG edges are intra-procedural and thus differentiate from INVOKES edges. In the following, we summarize in which order the root node representing a language construct and its descendants in the AST tree are connected.

解释如下：

评估顺序图（EOG）是在将代码初步转换为 CPG 之后，在 AST 节点之间建立的边。其目的是遵循代码执行的顺序，类似于 CFG，此外还能以更细的粒度区分表达式和子表达式的评估顺序。每个节点都指向一组之前边：

preEOG

和

nextEOG

（这与之前讲的DFG结构类似）。EOG 是方法内的概念，不涉及方法调用。

EOG会针对以下类型及其所有子类节点构建

• NamespaceDeclaration

• TranslationUnitDeclaration

• RecordDeclaration

• FunctionDeclaration

二、EOG与CFG的区别

• diff1：对于没有显式return语句的方法，EOG 将会构建一条虚拟边，这条边指向行号为 -1 的虚拟返回节点；CFG 则以最后一条reachable（可达）语句结束，不会插入虚拟返回语句

• diff2：EOG 会将代码块 Block 作为一个单独的节点；CFG 则会使用代码块中的第一条实际可执行语句作为起点

• diff3：对于 if 语句，EOG 将 if 关键字和condition（条件）视为单独的节点；CFG 则将其视为同一个 if statement

• diff4：EOG 将method header（方法头）视为节点；CFG 将把方法的第一条可执行语句视为节点

tips: EOG 在我们真正使用过程中很少直接用他去做分析，其更多的是为其他图的构建做基础（如：DFG、PDG等），再加上EOG与CFG（控制流图）很类似，只有一些特殊节点的处理有差异。

因此，关于EOG的分析不会像DFG那样将所有类型的节点都展开做详细分析，我只挑其与CFG的差异化处理部分、以及常见使用场景做讲解。

对CFG（控制流图）的构建不熟悉的同学可以参考这篇文章：

SAST-数据流分析方法-理论

三、EOG的构建

tips: 以下测试过程均采用图数据库Neo4j，通过浏览器可视化生成的效果，对Neo4j不熟悉的同学建议阅读：

Neo4j（待修改，加链接）

在分类讨论之前，不妨先验证一下其是否是方法内的概念

测试代码：

package com.test;public class TestFunCall {    public static void main(String[] args) {        test("SASTing");    }    public static void test(String a) {        System.out.println("Hello " + a);    }}

以上代码转换后的CPG如下：

• EOG做了红色加粗渲染

• DFG做了蓝色渲染

• 黄色节点是方法声明

1.FunctionDeclaration

EOG构建规则：

• parameters: List<ParameterDeclaration>

  : 方法参数

• defaultValue: Expression

  : 参数的默认值（可选）

• body: Statement

  : 方法体

测试代码：

package com.test;public class TestFunctionDecl {    public void nonReturn(String a, int b) {    }}

生成的CPG如下：

Java中不支持给方法的参数赋默认值的操作，所以其他边暂时就看不到啦，这种处理是为了处理支持参数默认值的语言。

2.IfStatement

EOG的构建如下图（各节点见名知意，就不详细展开说明了）：

测试代码：

public boolean check(String str) {    if (str.contains("SASTing")) {        return true;    }    else {        return false;    }}

转换后的CPG如下：

通过转换后的效果可以看到，以下边均可得到验证：

• initializerStatement --> condition|conditionDeclaration

• condition|conditionDeclaration  -> IfStatement

• IfStatement --> thenStatement

• IfStatement --> elseStatement

3.CallExpression

EOG构建规则如下：

• callee：被调方法

测试代码：

public class TestCallExpression {    public static void main(String[] args) {        Caller caller = new Caller();        caller.callee(args[0]); // CallExpression    }}class Caller {    public void callee(String name) {    }}

生成的CPG如下：

通过观察上文提到的EOG构建规则图，可以发现，其实就是生成了这样一条边（为了看起来直观，我们此处只讨论一个传参的情况）：

• callee --> argument --> CallExpression

4.ForStatement

EOG构建方式：

• initializerStatement  循环开始前的初始化语句 （第一个分号前的初始化语句）

• condition  循环条件 (第一个分好后的条件语句)

• conditionDeclaration  条件声明

• statement  循环体

• iterationStatement  每次循环完后要执行的语句（最后一个分号后的语句）

测试代码：

public class TestForStatement {    public void test() {        int a = 0;        int i;        for(i=0; i<10; i++) {            a += i;        }    }}

生成的CPG如下（部分节点已隐藏）：

这张图看起来挺复杂，但莫慌，让笔者带你拆解他！

我们先把这张图划分一下：

这么看是不是就清晰多了

我们再看其EOG的构建规则，其有以下几条边：

• iterationStatement --> condition  （对应上图的  

  ++

  节点 -->

  i

  节点）
• initializerStatement --> condition  （对应上图的  

  =

  节点 -->

  i

  节点）
• condition --> ForStatement  （对应上图中的

  <

  节点 -->

  ForStatement

  节点）
• 其余从

  ForStatement

  出去的两条边也存在，为了不影响整体的观看效果，笔者已将其隐藏，大家可自行验证

5.TryStatement

EOG构建规则如下图：

• resources:Listtry块中需要的值

• tryBlock:Block

  try代码块

• finallyBlock:Block

  finally代码块

• catchBlocks:List<Block>

  catch代码块

测试代码：

public class TestTry {    public void test() {        try {            throwExceptionMethod();        } catch (IllegalArgumentException e) {            e.printStackTrace();        } finally {            System.out.println("finished");        }    }    private void throwExceptionMethod() throws IllegalArgumentException {    }}

生成的CPG如下（已隐藏部分节点及边）：

现在来拆分这张图：

划分模块后，可以很直观地看到以下几条边：

• try --> finally

• catch --> finally

• resources --> try

推荐阅读

代码属性图CPG系列文章（白盒/静态代码分析方向）：超万字的详细讲解，文章理论与实践相结合，示例代码可拿来即用，通俗易懂，这样的文章你爱了吗！ 

• 抽丝剥茧代码属性图CPG-第一弹：CPG介绍

• 抽丝剥茧代码属性图CPG-第四弹：CPG中的DFG-3

• SAST-短小精悍的Benchmark

能够看到这篇文章，就是我们的缘分，坚持输出优质内容是笔者一直在做的事情。若文章对你有帮助，感谢点个免费的 点赞、在看，大家的鼓励是我最大的动力

点个关注，不后悔

引言

越来越多的网安厂商将基于LLM（大语言模型） 工具集成到他们的安全产品中。OpenAI的GPT模型更受厂商的青睐。

我们熟知的微软的 Copilot 使用的也是GPT大模型，在 Copilot 推出的一个月后，微软宣布将使用 40000 份威胁情报数据做针对性训练。

与此同时，OX Security（软件供应链安全厂商）与Ironscales（电子邮件安全厂商）在 6 月份的Infosecurity Europe（欧洲信息安全大会）上发布了基于GPT的网络安全领域的大模型。

许多其他供应商也在探索利用 LLM 的可能性，在欧洲信息安全会议期间，Contxt（API安全提供商）CEO  Mayur Upadhyaya 表示：

我们在 2021 年获得了一笔创新基金，当时基础模型还没有出现，目的是利用专有数据集建立一个用于个人数据检测的大模型。我们现在正在尝试如何更好地利用这些数据集。

大模型背后的算法

各个大模型背后采用的AI算法是不一样的，厂商公开使用的算法如下：

• Egress公司：genetic programming, behavioral analytics-based algorithms, as well as social graphs

遗传编程、基于行为分析的算法以及社交图谱）

• Ironscales公司：a broad range of algorithms, including some leveraging natural language processing (NLP), but not LLMs yet

多模态算法的融合，包括一些NLP（自然语言处理）算法，但目前还没有使用 LLMs

• Google公司：classifiers, a type of machine learning algorithm used to assign a class label to a data input

网络安全领域使用的大多数AI算法都是分类器，这是一种机器学习算法，用于为数据输入分配类别标签

大模型现状

目前的通用 LLM 往往会产生幻觉（看似合理但错误的回答）。

CISO Jon France（ISC组织）表示：

幻觉问题是通用大模型的通病，这对于网络安全领域来说是一个严重的问题，因为准确性和精确性在网络安全实践中至关重要。

但是，通用大模型 LLM 对网安行业也带来了一定的正向作用：如制定一些安全政策等。

Ganesh Chellappa（ManageEngine公司支持服务负责人）表示：

现在很多企业的解决方案都是基于用户行为分析去做的，他们拥有大量的用户行为数据，但这些有用的数据却没有被真正的利用起来，我们完全可以把这些数据给到 LLM 去做训练。

这些数据可以用作异常行为检测（电子邮件安全、终端安全等）、威胁情报分析等领域。

如果真正把这些数据利用起来，发挥他们的价值，相信会达到事半功倍的效果。

如何解决幻觉问题

Chellappa认为:

网安厂商应该充分利用开源大模型，如：Meta的LLaMA，斯坦福大学的Alpaca等，利用这些开源大模型框架去训练自己的数据集，幻觉问题将在很大程度上得到改善。

不过，Niklas Hellemann（SoSafe CEO）表示：

开源模型正在面临一个日益严重的问题：model poisoning。像 LLaMA 这样的开源大模型已经遭受了模型投毒攻击。

模型投毒是一种针对机器学习模型的攻击方式，这种攻击手段通过有意地篡改训练数据集或在训练过程中注入误导信息，从而导致机器学习模型在部署后的行为出现偏差，无法做出准确的预测或决策。

大模型有这么多“问题”，我们如何去解决呢？在此之前，我们有必要了解一下大模型的分类。

大模型分类

我们都知道，大模型一般分两种：

• 通用大模型

• 专用大模型

通用大模型

这类模型具备跨领域、跨任务的泛化能力，能够在多种不同的应用场景下表现出较好的适应性和表现力。例如，GPT-3、通义千问等大模型，它们经过大规模预训练后，能够完成文本生成、问答、摘要、翻译等多种自然语言处理任务。

专用大模型

专用大模型也可以称为小模型，专用大模型通常是为某一特定任务或领域设计和训练的大型模型，虽然其参数量也可能很大，但相较于通用大模型，它们在特定领域的性能可能更为突出，因为在设计和训练时就已经考虑了该领域的特殊性，对特定任务有更强的针对性。

小模型在参数量、复杂度或任务覆盖面上较为有限，是专注于某个具体任务或领域内的模型。这类模型在特定场景下因其针对性强、资源消耗相对较小而受到青睐。

既然通用大模型有诸多不便，我们何不使用相对小型、专业的数据集去训练一些特定领域的小模型呢，小模型的性价比理论上是更高的。

OpenAI 推出了基于 GPT 的网安领域小模型

网安领域小模型

基于GPT的各领域小模型有很多：

以下基于GPT的网安领域小模型被广泛使用：

编码

• Betterscan.io AI Code Analyzer  代码分析器，分析代码质量、是否满足编码规范等

• Code Securely 基于OWASP Top 10的安全开发练习，用户可以识别代码中典型的Web漏洞，提高安全开发能力

红队

• GP(en)T(ester)  渗透测试助手

• HackTricksGPT  根据HackTricks系列书籍提供一些安全建议

• MagicUnprotect 提供恶意软件规避方式，如：反窃听、反取证等。

• Pentest Reporter  编写渗透测试报告

蓝队

• ATT&CK Mate  提供MITRE ATT&CK框架下的最新战术方法

• CVEs  查找CVE漏洞的工具

• Threat Intel Bot 及时了解APT最新威胁情报

• Threat Modelling  威胁建模，识别潜在的漏洞，并提供解决方案

网安行业指导/职业发展

• Cyber Security Career Mentor  为初入网安领域的新手提供一些职业规划

• Cyber Charli  对8-12岁儿童进行网络安全教育

• Cyber Mentor  提供网安进阶学习路线等

• Pentester Interviewer  渗透测试行业面试官

总结

任何一项技术都是有两面性的，大模型无疑是一种革命性的工具，其给我们的日常生活带来了极大的便利，它可以提高我们的工作效率，同时也会伴随着各种安全问题，像利用大模型去做网络攻击、诈骗等。

任何技术在发展的过程中，都应该做到“两条腿走路”，不能只关注其便利性，而忽略它带来的负面影响，二者兼顾才能可持续健康发展。

推荐阅读

• 抽丝剥茧代码属性图CPG-第四弹：CPG中的DFG-3

• GPT-4可自主利用1day漏洞了，0day还会远吗？渗透测试：我慌了！

• 世界上只有两种程序员：1.懂DevSecOps的 2.其他程序员

能够看到这篇文章，就是我们的缘分，坚持输出优质内容是笔者一直在做的事情。若文章对你有帮助，感谢点个免费的 点赞、在看，大家的鼓励是我最大的动力

点个关注，不后悔

写在前面

本文旨在保证"抽丝剥茧代码属性图CPG"系列文章的完整性，笔者认为图数据库Neo4j也是该系列中不可或缺的一部分，本文起到一个抛砖引玉的作用，后续大概率会对CPG中的Neo4j做详细的讲解，大家敬请期待~

引言

为什么要写CPG中的Neo4j呢，在花大把时间肝完CPG中的DFG（Data Flow Graph）后，笔者闲下来再去回顾这些东西时，虽然写得很全面也很细节了， 但看起来还不是那么的直观，尤其是验证各条边的构建过程时，必须在特定代码场景下debug调试，然后从程序断点处寻找我们想要的DFG信息，想必大家在阅读过程中也是比较痛苦的。

所以嘞，笔者打算以后的文章中若涉及到验证或者是需要看CPG的构建效果时，直接给大家上图！

大家可以先看一张图，直观地感受一下图形化展示的效果（此图不是完整的图，是笔者本地测试的一张图，主要是让大家感受下neo4j带来的便利）。

红色的边都是DFG边（neo4j browser提供的渲染，可自定义样式），另外，节点是什么类型，其有哪些属性都可以点击节点，直观地看到。

一、Neo4j介绍

概述

Neo4j 是一款高性能的、开源的 NoSQL 图形数据库。其采用图形数据模型，将数据表示为节点、关系以及节点之间的连接，并且节点及关系都可以携带属性来扩充信息，非常适合那些需要揭示复杂数据间隐含关系的应用场景。其存储的内容如下：

• Node  节点

• Relationship  节点间的关系

• Property  节点属性

特点

• 使用Cypher查询语言

• 支持完整的ACID事务特性（原子性，一致性，隔离性和持久性）

• 支持将查询的数据导出为JSON和XSL格式

• 提供REST API，可以被任何编程语言访问

二、Neo4j本地安装

• 下载地址：https://neo4j.com/deployment-center/#community

• 解压后进入bin文件夹下，执行如下命令：

neo4j.bat console

如下效果即执行成功

• 浏览器访问http://localhost:7474/browser/

输入默认账号neo4j，默认密码neo4j，然后再修改密码后即可正常访问。

三、CPG-neo4j的调用方式

tips:需先本地安装neo4j，并启动neo4j服务

1.gradle打包+命令行

// 克隆cpg到本地git clone https://github.com/Fraunhofer-AISEC/cpg.git// 进入cpg-neo4j目录cd cpg/cpg-neo4j//gradle 构建gralde installDist

• cpg-neo4j

• cpg-neo4j.bat

命令行调用可执行程序：

./build/install/cpg-neo4j/bin/cpg-neo4j  [--infer-nodes] [--load-includes] [--no-default-passes]                    [--no-neo4j] [--no-purge-db] [--print-benchmark]                    [--use-unity-build] [--benchmark-json=<benchmarkJson>]                    [--custom-pass-list=<customPasses>]                    [--export-json=<exportJsonFile>] [--host=<host>]                    [--includes-file=<includesFile>]                    [--password=<neo4jPassword>] [--port=<port>]                    [--save-depth=<depth>] [--top-level=<topLevel>]                    [--user=<neo4jUsername>] ([<files>...] | -S=<String=String>                    [-S=<String=String>]... |                    --json-compilation-database=<jsonCompilationDatabase> |                    --list-passes)      [<files>...]           The paths to analyze. If module support is                               enabled, the paths will be looked at if they                               contain modules      --benchmark-json=<benchmarkJson>                             Save benchmark results to json file      --custom-pass-list=<customPasses>                             Add custom list of passes (includes                               --no-default-passes) which is passed as a                               comma-separated list; give either pass name if                               pass is in list, or its FQDN (e.g.                               --custom-pass-list=DFGPass,CallResolver)      --export-json=<exportJsonFile>                             Export cpg as json      --host=<host>          Set the host of the neo4j Database (default:                               localhost).      --includes-file=<includesFile>                             Load includes from file      --infer-nodes          Create inferred nodes for missing declarations      --json-compilation-database=<jsonCompilationDatabase>                             The path to an optional a JSON compilation database      --list-passes          Prints the list available passes      --load-includes        Enable TranslationConfiguration option loadIncludes      --no-default-passes    Do not register default passes [used for debugging]      --no-neo4j             Do not push cpg into neo4j [used for debugging]      --no-purge-db          Do no purge neo4j database before pushing the cpg      --password=<neo4jPassword>                             Neo4j password (default: password      --port=<port>          Set the port of the neo4j Database (default: 7687).      --print-benchmark      Print benchmark result as markdown table  -S, --softwareComponents=<String=String>                             Maps the names of software components to their                               respective files. The files are separated by                               commas (No whitespace!).                             Example: -S App1=./file1.c,./file2.c -S App2=.                               /Main.java,./Class.java      --save-depth=<depth>   Performance optimisation: Limit recursion depth                               form neo4j OGM when leaving the AST. -1                               (default) means no limit is used.      --top-level=<topLevel> Set top level directory of project structure.                               Default: Largest common path of all source files      --use-unity-build      Enable unity build mode for C++ (requires                               --load-includes)      --user=<neo4jUsername> Neo4j user name (default: neo4j)

我们需要注意以下参数：

• --host   neo4j服务器（默认localhost）

• --port  服务器端口（默认7687）

• --user  neo4j用户名（默认 neo4j）

• --password  neo4j密码（默认 password）

• --export-json  是否输出json格式的结果

• --no-neo4j  不将结果push至neo4j数据库

使用示例：（其余参数默认即可）

 .\cpg-neo4j D:\Example.java --password yourPassword

然后，就可以访问http://localhost:7474/browser查看CPG翻译后的代码属性图了

2.code调用

@Test@Throws(InterruptedException::class)fun myNeo4jTest() {    val cmd = CommandLine(Application::class.java)    cmd.parseArgs("Example.java")    val application = cmd.getCommand<Application>()    val translationConfiguration = application.setupTranslationConfiguration()    val translationResult = TranslationManager.builder().config(translationConfiguration).build().analyze().get()    application.pushToNeo4j(translationResult)}

推荐阅读

代码属性图CPG系列文章（白盒/静态代码分析方向）：超万字的详细讲解，文章理论与实践相结合，示例代码可拿来即用，通俗易懂，这样的文章你爱了吗！ 

• 抽丝剥茧代码属性图CPG-第一弹：CPG介绍

• 抽丝剥茧代码属性图CPG-第四弹：CPG中的DFG-3

• SAST-短小精悍的Benchmark

• GPT-4可自主利用1day漏洞了，0day还会远吗？渗透测试：我慌了！

既然说到DevSecOps，就不得不提DevOps，二者从字面上的差距就是前者多了一个“Sec”，也就是安全的意思。显然，安全在软件开发流程中越来越重要。在讲DevSecOps之前，我们先来回顾一下DevOps。

一、什么是DevOps

DevOps可拆分为两部分：Devlopment与Operations，也就是开发与运营的组合。该流程促进开发人员和运营人员协作，简化了软件开发流程，以确保更快、更高效地部署。

开发人员和运营人员共同参与到软件开发的生命周期中，共同管理维护这个流程，团队协作效率大大提升，避免了很多不必要的沟通壁垒，大大提高了软件的开发效率。

二、DevOps的工作原理

开发和运营是 DevOps 的核心。这两个团队之间有非常紧密的协作关系，开发流程中的其他模块都要围绕这两个部分设计。此外，高效的pipeline也是 DevOps 发挥作用的关键一环。以下DevOps流程图涵盖了从plan（计划）到release（发版）的所有环节，同时也包括软件交付流程

DevOps的核心是敏捷性，其将开发、测试、管理、运营等角色紧密地结合起来，将软件开发生产力推到的一个新的高度。

另外，自动化在 DevOps 中起着至关重要的作用，其可实现软件的快速一键部署。Jenkins、Docker 和 Kubernetes 等工具在开发流程中被广泛使用。

三、什么是DevSecOps

DevSecOps 是development, security, operations三个的单词的组合，也就是开发、安全和运营的组合，是在软件和应用程序开发生命周期中持续集成安全的实践，以确保最佳的安全和性能效率。

DevSecOps的核心是将安全集成到了SDLC（软件开发生命周期）中的每个阶段。简单来说就是：

软件的安全指标会影响软件的开发、测试、发版、运营等各个阶段。举个例子:

在软件发布前会经过一系列的安全测试（包括SAST、IAST、DAST等），若发现了一些中高危的安全漏洞（不满足软件安全性标准），是不允许发布的，必须对漏洞进行修复。

软件达到安全标准才可以进行下一个阶段。

四、DevSecOps的理念

DevSecOps 强调开发、安全和运营团队之间的协作和集成。其强调安全性不应该是事后的想法，而应该从项目的最初阶段就考虑。这是一种责任共担的文化，所有团队共同努力，确保在软件开发生命周期的所有阶段都妥善解决安全性问题。DevSecOps 的核心是专注于自动化和持续集成，这将确保快速、一致地实施安全措施。

五、DevSecOps中的Sec怎么保证

软件开发流程的Security检测有很多方法，大家可以先看一下这张图：

各阶段的Securtity通常会涉及以下部分（包括但不限于）：

1.Plan阶段

• 威胁建模和风险评估：在设计阶段进行威胁建模，识别潜在风险点，并制定针对性的安全策略

• 安全架构设计：最小权限原则、纵深防御、微服务安全边界设计等

• 安全开发规范：编写和更新安全编码指南等

2.Code、Build、Test阶段

• SAST  静态代码分析工具（白盒，分析对象为项目源代码）

• SCA 软件依赖项扫描（旨在发现软件使用的第三方组件中的安全漏洞，通常以分析二进制文件、容器为主，也可分析源码）

3.Deploye阶段

• 权限及配置管理

• 角色权限管理

• 安全配置管理

• ...

4.Operate阶段

• 日志监控及审计

• IDS/IPS/WAF等安全软件

• 漏洞管理与补丁更新

• DAST  动态应用安全测试（黑盒，如：渗透测试）

• IAST 交互式应用安全测试（灰盒，白盒与黑盒的结合，通常通过插桩方式实现）

• RASP（Runtime Application Self-Protection）：软件运行时的保护措施

5.Monitor阶段

• 监控软件行为（日志分析等）

• SIEM（安全信息和事件管理）：SIEM还可以与其他安全工具集成，支持安全事件响应流程（SOAR）的自动化

• 漏洞扫描：发现漏洞及时修复

• 其他安全工具的监控（IDS/IPS等）

六、DevSecOps的优势

1.安全左移

将安全融入开发的早期阶段，而不是等到开发后期或者产品发布之后才进行安全审查。这意味着安全不再是开发流程的附加环节，而是与开发和运维紧密结合，大大减少了因安全问题引发的延迟和额外成本。

2.效率提升

通过自动化工具和CI/CD流水线集成安全测试，比如静态代码分析、动态应用安全测试等，可以快速检测和修复安全漏洞，可以在确保软件安全性的前提下，显著提升软件的交付速度。

3.成本降低

通过预防性的安全措施，减少了后期修复安全问题所需的时间和人力成本。同时，由于安全工作贯穿整个开发过程，可以有效避免因安全问题导致的重构、停机等操作。

4.更快的响应速度

DevSecOps团队在应对安全事件时拥有更快的响应速度，各团队之间紧密合作，安全贯穿始终，团队能够更快地发现、修复安全问题，对应急事件做出更快更有效的响应。

5.安全理念渗透

在安全团队与开发、运营团队协作的过程中，开发及运营人员的安全意识也会得到显著的提高，这对企业来说是一个隐性的潜在价值。安全意识的提升有助于应对突发的安全事件。

研究发现：GPT-4 可自主利用 87% 的1day漏洞

伊利诺伊大学的研究人员发现，GPT-4 可根据 NIST 公布的漏洞描述信息，通过推理、自证等方式成功利用 87% 的漏洞。

研究人员表示：

大语言模型 （LLM） 的代理能力越来越强。相较于GPT-4，其他模型在工具使用能力方面差得多。

研究结果表明，GPT-4 可以自主检测和利用可能被渗透工具忽略的1day漏洞。

美国加州大学洛杉矶分校助理教授 Daniel Kang 希望他的研究成果能用于网络安全防御，但是，GPT-4的这种能力同时也会被恶意利用。

Daniel Kang表示 :

我认为，1day漏洞被利用的门槛会随着 LLM 成本的降低而大幅下降。在这之前，利用 1day 漏洞必须通过人为手动的方式。如果 LLM 足够便宜，这个过程很可能会变得更加自动化。

GPT-4 的自主检测和利用漏洞能力有多强

GPT-4 具备自主利用 1day 漏洞的能力。

GPT-4 代理能够自主利用 Web 和 非Web 的 1day 漏洞，其甚至可以利用模型知识库截止日期之后披露的漏洞。

Daniel Kang表示：

在之前的实验中，我们发现GPT-4在制定计划 并 实施计划方面表现非常出色，GPT-4代理可实时访问互联网，可以及时收集披露的漏洞描述信息与利漏洞用方式等数据。

我们所说的“autonomous”的意思是：GPT-4可以自主制定利用漏洞的方案(计划)，这一项能力非常强大，因为从漏洞描述到真正地利用该漏洞，这中间要做的事还有很多。

许多真实环境中存在的漏洞已经被公布了，如 ACIDRain（造成了超过 5000 万美元的实际损失），然而，想要真正利用这些漏洞并非易事。

在实验的 15 个 1day 漏洞中，只有两个无法利用：

• Iris XSS

• Hertzbeat RCE

作者推测原因：

• Iris Web应用难以预览

• Hertzbeat RCE 的中文描述很难用英文去理解

GPT-4 无法自主利用 0day 漏洞

GPT-4 代理通过漏洞描述信息去利用漏洞的成功率高达 87%，但在不提供漏洞描述时，成功率只有 7%，这表明GPT-4目前还不能利用 0day 漏洞。研究人员表示，这一结果表明：

LLM 利用漏洞的能力远远超过发现漏洞的能力。

成本:GPT-4 vs. 渗透人员

研究人员表示：

GPT-4 成功利用每个漏洞的平均成本为 8.8 美元；而对于一名专业渗透测试人员，每个漏洞的利用成本为25美元（花费半小时）。

GPT-4的相关运行成本会逐渐降低，因为GPT-3.5的成本在短短一年内就下降了三倍之多。

LLM相对于技术人员，具备一定的可扩展性。

GPT-4 自主利用漏洞需要频繁试错

大部分漏洞需要多次操作才能被成功利用，有的多达 100 次。有趣的是，平均操作次数与是否获取漏洞描述没有必然联系，实验证明GPT-4在利用1day和0day时进行的操作次数相差不大。

Daniel Kang表示：

若没有 CVE 描述信息，GPT-4 更容易放弃，因为它不知道该走哪条路。

如何测试 LLM 的漏洞利用能力

研究人员首先从 CVE 数据库和学术论文中收集了一个基准数据集，其中包含 15 个真实存在的1day漏洞。这些可复现的开源漏洞包括Web漏洞、容器漏洞和Python 缺陷包，其中有一半以上风险等级为 “high ”或 “critical”。

接下来，他们开发了一个基于 ReAct 自动化框架的 LLM 代理，这意味着它可以推理下一步行动、构建行动命令、使用适当的工具执行命令，并在交互式操作过程中重复执行命令。开发人员只需编写 91 行代码就能创建代理。

LLM代理不仅支持GPT-4，还支持以下模型：

• GPT-3.5.

• OpenHermes-2.5-Mistral-7B.

• Llama-2 Chat (70B).

• LLaMA-2 Chat (13B).

• LLaMA-2 Chat (7B).

• Mixtral-8x7B Instruct.

• Mistral (7B) Instruct v0.2.

• Nous Hermes-2 Yi 34B.

• OpenChat 3.5.

该代理配备了自主利用系统漏洞所需的工具，如Web浏览器、终端、Web搜索、文件创建和编辑功能以及代码解释器等。它还可以爬取 CVE 数据库的漏洞描述信息。

此外，研究人员为每个代理提供了详细的提示信息，不断探索利用 15 个漏洞的不同方法，提示信息包含 1056 个 "tokens"。

代理的性能衡量标准包含以下几个方面：

• 输入和输出的token数量

• 漏洞利用成功率

• 漏洞复杂性

• 经济成本

为了模拟0day环境，研究人员在不提供漏洞信息的情况下进行多次实验，代理既要发现漏洞，又要成功利用漏洞。

此外，使用 ZAP 和 Metasploit 工具进行对比实验，向工具输入相同的漏洞样本，对比传统漏扫工具与LLM的能力。

最终，研究人员发现：

只有基于 GPT-4 的 LLM 代理才能发现并利用1day漏洞，其他 LLM 和两个漏扫工具的成功率都为 0%。

为何要测试 LLMs 的漏洞利用能力

• 在此之前，人们没有对 LLM自主利用1day漏洞的能力做系统性的研究。

• CVE披露的漏洞信息有很大一部分是不包含exp的，渗透测试人员需要自己去研究漏洞原理从而真正利用或者修复漏洞，该项研究旨在探索LLM

  自主实现

  这一过程的可行性。

Daniel Kang表示：

我们实验室关注的是包括代理在内的人工智能技术在各领域中具备哪些能力，这些能力是否可以真正运用到生产或生活环境中。

网络安全的重要性显而易见，因此，我们最近把研究重点放在了网络安全上。

引言

CPG中DFG（Data Flow Graph）的构建已经讲述完毕了，大家可能会有个疑惑，为什么要如此长篇大论地介绍DFG，有这个必要吗？答案是肯定的，原因如下：

• DFG（Data Flow Graph）是程序分析的基础，在任何程序分析框架中都是非常重要的，其很大程度上影响分析结果的精度，CPG中当然也不例外

• CPG框架通过遍历DFG的方式解决了很多通用型分析，如

  ValueEvaluator

  、

  Out of Bound Check

  、

  Null Pointer Check

  等

读后有收获的同学可以点个赞哦，要是能关注一下公众号就更好啦~大家的鼓励是笔者硬肝技术的动力！非常感谢大家~

文中有错误的地方欢迎大家私信/评论区指正。同时也欢迎大家将自己的想法发布在评论区，希望大家能够畅所欲言，共同进步~

欢迎点击公众号菜单栏"点击进群"，与大佬一同交流技术。

1.介绍

The value evaluator tries to evaluate the (constant) value of an Expression basically by following DFG edges until we reach a Literal. It also evaluates simple binary operations, such as arithmetic operations, as well as simple string concatenations.

The result can be retrieved in two ways:

• The result of the resolve function is a JVM object which represents the constant value

• Furthermore, after the execution of evaluateInternal, the latest evaluation path can be retrieved in the path property of the evaluator.

It contains some advanced mechanics such as resolution of values of arrays, if they contain literal values. Furthermore, its behaviour can be adjusted by implementing the cannotEvaluate function, which is called when the default behaviour would not be able to resolve the value. This way, language specific features such as string formatting can be modelled.

解释：

ValueEvaluator

通过沿DFG边跟踪，直至抵达Literal（字面量，也就是常量），来计算

Expression

的值。它还能处理简单的二元操作，如算术运算，以及简单的字符串连接。

获取计算结果有两种方式：

• resolve

  方法返回一个代表该常量值的JVM对象
• 在

  evaluateInternal

  方法执行后，可以通过

  evaluator

  的

  path

  属性获取到当前求值路径

另外，

ValueEvaluator

还包含一些高级机制，例如：可以解析数组的常量值。此外，若解析常量失败，可以通过实现

cannotEvaluate

函数来自定义一些方法行为。这样，就可以模拟诸如字符串格式化等语言特定特性。

2.实现

2.1.常量传播算法

node is Literal<*>

2.2.判定节点是否为常量

2.2.1.VariableDeclaration

tips:这里应该很好理解，一个变量声明的常量值自然就是其初始化赋予的常量值；同时还会传递一个

depth+1

参数，表示当前递归的深度，这里是为了控制递归的深度，防止影响算法性能

2.2.2.Reference

2.2.3.UnaryOperator

2.2.4.BinaryOperator

2.2.5.SubscriptExpression

• initializers

  为

  KeyValueExpression

  时，先对元素进行过滤，然后存储到一个

  ArrayList

  中，然后再从这个list中取值（其实现细节不是本节讨论的重点，感兴趣的童鞋可以自行研究源码），然后

  return

• initializers

  是常量，直接返回其

  value

• 表达式 的

  arrayExpression

  是

  SubscriptExpression

  ，将其作为递归参数传递

2.2.6.ConditionalExpression

很明显，这里的处理是有bug的，试想一下，若

condition

是一个

BinaryOperator

，但是其

operatorCode

是

!=

，那得到的结果岂不是刚好相反了嘛。先保留这个疑问，后续对其进行验证。

2.2.7.AssignExpression

• 先求

  lhs

  与

  rhs

  的常量值
• 再对

  lhs

  与

  rhs

  做运算操作，返回运算后的值

3.验证

tips:笔者本来是想对第二小节的所有节点类型作一一验证的，但是验证过后，得出一个结论：

ValueEvaluator

分析能力很low，所以都搬过来也没什么意义。所以就只验证了其是否支持过程间分析，以及上文提到的bug。

3.1.Reference

测试代码：

package com.cpg.dfg.analyze.valueevaluator;public class TestReference {    // interprocedural test case    public void test() {        int a = 1;        a = getA(a);        System.out.println(a);    }    public int getA(int a) {        a++;        return a;    }}

测试结果如下：

3.2.ConditionalExpression

测试代码：

package com.cpg.dfg.analyze;public class TestValueEvaluator {    public void test() {        int a = 1;        a = a != 1 ? 2 : a;  // there is a bug when ValueEvaluator run        System.out.println(a); // the value of a is 2,it's error.It should be 1    }}

测试结果如下：

总结

• CPG自带的

  ValueEvaluator

  的常量传播能力很有限
• CPG自带的

  ValueEvaluator

  是过程内的分析

• ConditionalExpression

  的处理有bug
• 慎用CPG自带的

  ValueEvaluator

  ，但是若需要使用DFG做checker开发时，可以借鉴

  ValueEvaluator

  中对DFG的使用

引言

2024年全球威胁报告（2024 Global Threat Analysis Report）是由Radware公司发布的权威性研究报告，该公司每年都会统计去年的网络攻击事件，总结攻击行为的特点、趋势并对安全防护提出指导性建议。

Radware是全球领先的物理、云端和软件定义型数据中心网络安全与应用交付解决方案提供商。其有口皆碑的解决方案组合通过为世界各地的企业提供基础设施、应用程序和企业IT保护以及可用性服务来确保数字体验。Radware的解决方案助力全球范围内超过12,500家企业和运营商客户快速适应市场挑战，维持业务连续性，并在降低成本的同时实现生产率最大化。

网络安全是当今数字化社会中至关重要的议题，随着技术的不断发展和网络攻击手段的日益复杂化，各种威胁和攻击对个人、组织甚至国家安全构成了严峻挑战。

2024年全球威胁分析报告（2024 Global Threat Analysis Report）总结了2023年的网络安全事件，并提出了未来安全事件的发展趋势，对我们理解当前威胁形势、制定有效防御策略有着重要的参考意义。本文将对该报告进行全面解读，以问答的形式展开叙述。

1.2023年网络安全事件的发展趋势是怎样的？

• 针对DNS和HTTPS协议的攻击显著增加

• DNS洪水攻击是最常见的攻击方式

• NTP放大攻击产生的攻击量最大，几乎占全球攻击总量的一半，并且其利用率最高

• 美国发起的非请求网络活动（可理解为网络攻击行为）最多，占所有网络活动的45%（美国2022年同样占比最多，为42.5%）

• Web应用程序及针对API的恶意攻击行为相较于2022年增长了171%。很大一部分原因是2023年上半年DDOS攻击行为大幅增加。

• 随着大语言模型（LLM）及生成式AI的迅速发展，网络攻击行为的门槛也随之降低，同时，攻击者可以利用这些新型AI技术完成高复杂性、高成功率、大规模的攻击行为。

2.各行业遭受DDOS攻击的情况

各行业遭受DDOS攻击占比：

• 金融 30%

• 科技 22.2%

• 医疗保健 14.2%

• 政府 11.5%

• 运输和物流 8.64%

• 游戏 3.09%

3.各行业遭受DNS洪水攻击的情况

• 研究与教育 31.5%

• 电子信息 24.9%

• 科技 18.7%

• 金融 9.53%

• 医疗保健 6.02%

4.各国家遭受网络攻击的情况

如图所示，各国家遭受网络攻击次数的排名如下：

• 以色列 （排在首位，遭受1480起网络攻击）

• 印度

• 美国

• 乌克兰 （俄乌冲突影响）

• 波兰 （俄乌冲突影响）

5.2023年重大网络安全事件

• Log4jShell（2023 top10 中占据6个，利用JNDI实现RCE）

• DNS-named-version-attempt（利用服务器信息泄露获取DNS服务器版本信息）

• ZMAP扫描 （替代Nmap，是工具top10中的第二位，高速扫描、识别已知漏洞、端口扫描等）

• SIPSAK工具（针对SIP协议设备做多种测试，top10中第6位）

• SIPVicious（发现SIP服务器、密码暴力破解等，top10中第10位）

6.被扫描的UDP端口top10

被扫描和利用的 UDP 端口/服务 top10 如下：

• SIP

• NTP

• SSDP

• SNMP

• Memcached

• mDNS

• 80 (2023年新增)

• MSSQL

• IPSec(IKE) (2023年新增)

• BitTorrent P2P (2023年新增)

2022年top10中的 LDAP、NetBIOS 及 CoAP在2023年未进top10。

近期，一个黑客组织声称，他们成功窃取了一份机密数据库”World-Check“，其中包含数百万条记录。公司会利用该数据库对潜在客户进行筛选，以确认客户是否参与金融犯罪或其他犯罪行为。

GhostR（黑客组织代号）声称：

我们于3月份从 ”World-Check“ 数据库中获取了530万条记录，这些数据信息会在网上披露。

World-Check 数据库主要用于 "know your customer"（KYC）,也就是通过该数据库对客户身份进行确认，防止客户中混入一些潜逃罪犯或者高风险人群（如：参与洗钱、被政府制裁等）。黑客表示，他们从一家有 World-Check 数据库访问权限的新加坡公司窃取了数据，但没有透露该公司的名称。

维护该数据库的伦敦证券交易所发言人Simon Henrick表示：

这不是由我们系统（LSEG）的安全漏洞造成的。第三方公司数据库中也会保存World-Check数据库的副本。显然，这是黑客组织从第三方系统中非法获得的。我们正在积极与第三方公司联系，同时通知相关责任单位，确保我们的数据得到合法保护。

Simon Henrick 没有透露第三方公司的名称，但也没有否认机密数据泄露的事实。

该黑客组织披露了一小部分数据，其中包含大量现任和前任政府官员、外交官及一些贪污腐败人群等，名单中还包括一些犯罪分子、恐怖分子、情报人员等。

World-Check数据库中包含姓名、护照编号、个人账户、银行卡账号等信息。

伦敦证券交易所 2021年以270亿美元收购了金融数据提供商Refinitiv。该集团从外界收集信息：包括公开的制裁名单、政府来源和新闻媒体等。

World-Check数据库中不仅会存储敏感人群的信息，普通人的身份信息也会被存储进去，显然，这是不合法的。

其实早在2016年，一家第三方公司的安全漏洞被黑客利用，World-Check数据库的一份副本就已经泄露。值得注意的是，当时该数据库中英国前顾问被贴上了"恐怖主义"的标签。由于此次数据泄露，汇丰银行冻结了几个大的银行账户，原因是World-Check数据库中他们被贴上了“恐怖主义”标签。

英国数据保护机构办公室发言人目前没有就此次信息泄露事件发表评论。