跳到主要内容

48 篇博文 含有标签「代码审计」

IRify / SSA / SyntaxFlow 静态代码分析与代码审计实战

查看所有标签

方法论:Harness Engineering 与 IRify 规模化研发实践

· 阅读需 14 分钟
Yak Project
网络安全垂直语言团队

2026年,大模型能力被普遍认为进入了高原期:单纯依靠算力堆积的暴力美学,其边际收益已经大幅降低,同时高质量的人类训练语料也趋近枯竭。面对这一瓶颈,业界的焦点开始发生转移:大家普遍认为,单纯比拼模型的时代正在远去,比拼Harness Engineering(驾驭工程)的时代已经到来。这就好比制造汽车时,将其发动机的马力已经压榨到物理极限了,再想提升整辆车的性能,就不能只盯着发动机,而要把目光投向传动系统、方向盘等驾驭发动机的系统上。

性能优化:IRify 第二轮全路径性能重构(SSA/SyntaxFlow/ANTLR)

· 阅读需 20 分钟
Yak Project
网络安全垂直语言团队

过去几个月,Yaklang 在 SSA、CodeScan、SyntaxFlow / SFVM、ANTLR / front-end 这几条线,做完了第二轮比较成体系的性能优化。

如果只看提交记录,会觉得这是一串零散的修复、重构和实验;但把这些工作放在一起看,会发现它们其实围绕的是同一个目标:

让 IRify 真正能够在大项目上更稳定地编译、更高效地扫描、更可控地执行规则,并且让后续第三轮、第四轮优化有清晰的落点。

代码审计:AI 结合 SSA 数据流分析检测密码泄露

· 阅读需 10 分钟
Yak Project
网络安全垂直语言团队

AI Agent 这两年正以不可思议的速度发展着。这种由大语言模型(LLM)驱动的自然交互模式,正在重塑静态应用安全测试(SAST)领域。基于 AI Agent 的自动化代码审计方案,已逐渐成为当前安全工程实践的重点探索方向。

在现有的 AI Agent 代码审计框架中,系统获取代码上下文的主要检索手段通常依赖 grep (纯文本正则检索)、tree-sitter (抽象语法树/AST 解析)以及 LSP (语言服务器协议)等工具。这些技术在处理基础的符号定位和局部代码提取时具有绝对效率优势:grep 负责极速的关键词定位,tree-sitter 负责精准的语法结构识别,而 LSP 则提供了“转到定义”或“查找引用”等基础语义导航能力。

然而,面对深度的安全审计需求时,这套组合拳显现出了结构性的局限。grep 仅能进行字面量匹配,无法解析逻辑依赖;基于 AST 的解析虽能识别静态特征,却难以跨越函数与物理文件边界;LSP 虽具备一定的语义关联能力,但本质上仍是“点对点”的静态跳转,它无法刻画变量在复杂控制流和赋值逻辑中的“生命周期”,也难以追踪数据在经过集合封装、对象透传或跨过程调用后的真实流转。

功能发布:IRify 代码审计报告生成功能

· 阅读需 8 分钟
Yak Project
网络安全垂直语言团队

在日常代码安全审计工作中,生成一份清晰、专业的审计报告是必不可少的环节。IRify 作为 Yakit 生态中的静态代码分析平台,提供了强大的报告生成功能,帮助安全工程师快速输出标准化的审计成果。本文将详细介绍 IRify 的报告生成功能及其使用方法。

代码审计:使用 SyntaxFlow 规则检测逻辑漏洞

· 阅读需 10 分钟
Yak Project
网络安全垂直语言团队

逻辑漏洞往往隐藏在业务代码深处,传统扫描工具难以覆盖。本文以 fuint 和 forest 两个开源项目中被分配了 CVE 编号的真实漏洞为例,分享如何通过 IRify 的 SyntaxFlow 语法编写规则,快速定位 Token 伪造与未授权访问等高危逻辑漏洞。

在代码审计和安全研究中,逻辑漏洞(Logic Vulnerabilities)一直是最难攻坚的堡垒。不同于 SQL 注入或 XSS 这种有明显特征的漏洞,逻辑漏洞通常依赖于具体的业务上下文,例如权限校验缺失、关键数据被篡改等。

最近,我们在对开源项目的审计中,利用静态代码分析工具 IRify 及其查询语言 SyntaxFlow,成功发现了几个严重的安全隐患,并被分配了 CVE 编号。今天就通过这三个 CVE 案例,来聊聊如何用“代码”来找“代码中的漏洞”。

代码审计:C 语言静态分析规则编写实践

· 阅读需 8 分钟
Yak Project
网络安全垂直语言团队

C 语言历经数十载发展,始终在编程语言领域占据重要地位,其设计理念深刻影响了后续众多编程语言的演进。在编写 C 语言安全规则时可以发现,其漏洞更多源于对语言本身特性的不当使用,而非网络层面的安全问题。许多著名的 CVE 漏洞都源于一些特定的编程场景:

遗憾的是,当前 IRify 对控制流的信息处理非常有限,不能像 Fortify 那样进行指针别名分析和深入的污点传播,因此像内存重复释放和空指针解引用这种需要精确控制流信息的漏洞就很难使用 Syntaxflow 规则精确定位。

目前正在做的工作是尽可能完善 C 语言的底层逻辑,让它尽可能和当前的编译逻辑相兼容。

性能优化:IRify 内存占用优化复盘(三)

· 阅读需 11 分钟
Yak Project
网络安全垂直语言团队

之前我们发布了 IRify 性能升级的第一篇技术文档,在文中详细阐述了针对 IRify 编译后端进行的一系列基础性架构优化。通过将指令间的引用从内存指针迁移为持久化 ID,并引入 Fetch 和 Save 异步 I/O 抽象,我们成功地将编译器的核心计算逻辑与缓慢的数据库持久化操作解耦,在数据库模式下获得了约20%的显著性能提升。

然而,性能优化的征程永无止境。解决一个瓶颈,往往会使下一个瓶颈凸显出来。当后端的数据库持久化不再是主要制约因素后,我们发现,编译器前端在文件处理和 AST(抽象语法树)解析阶段的固有串行性,成为了限制编译总吞吐量的“新墙”。

本文将聚焦于我们进行的第二阶段深度优化,详细介绍如何通过构建一个高效的异步处理管道(Pipe),彻底重塑了前端编译流程,并进一步完善了后端的并发数据处理模型,以应对前端带来的数据洪流,最终将 IRify 打造成真正意义上的高并发编译引擎。