48 posts tagged with "代码审计"

In 2026, large-model capabilities are widely seen as having entered a plateau: the brute-force aesthetics of simply piling on more compute now yields sharply diminishing marginal returns, and high-quality human training corpora are nearing exhaustion. Confronted with this bottleneck, the industry's focus has begun to shift. There is a growing consensus that the era of competing purely on models is fading, and an era of competing on Harness Engineering has arrived. It is much like building a car: once you have squeezed the engine's horsepower to its physical limit, further gains in overall vehicle performance can no longer come from staring only at the engine — your attention must turn to the systems that actually harness that engine, such as the drivetrain and the steering wheel.

Quick Overview​

• Applicable scenarios: Security teams that need to perform phased code audits on large projects, organize vulnerability evidence, and get assisted SyntaxFlow rule generation.
• Implementation approach: First explore the project and build a scan plan, then audit by category, verify each piece of evidence one by one, generate a report, and produce PoC examples or rule suggestions driven by risk.
• Key conclusion: The value of AI lies in organizing exploration, verification, and reporting into a traceable workflow; high-risk conclusions and PoCs still need to be reviewed in isolated, authorized environments.

FAQ​

Does AI audit jump straight to vulnerability conclusions?​

No. The workflow described breaks project exploration, scan planning, categorized audit, evidence recording, and report generation into independent phases, requiring conclusions to trace back to specific evidence.

Can auto-generated PoCs be used directly against production targets?​

No. PoCs are intended for risk reproduction and verification within an authorized scope; their inputs, impact, and execution boundaries should be reviewed in an isolated environment.

As Memfit AI's new features expand and the related mechanisms mature, we can now extend existing AI capabilities to our other products. This article focuses on the new attempts we have made in the AI-powered extension of the IRify tool.

Over the past few months, Yaklang has completed its second relatively systematic round of performance optimization along four lines: SSA, CodeScan, SyntaxFlow / SFVM, and ANTLR / front-end.

If you look only at the commit log, it reads like a string of scattered fixes, refactors, and experiments; but when you put all of this work together, you find it actually revolves around the same goal:

Make IRify genuinely able to compile more stably on large projects, scan more efficiently, and execute rules more controllably — while giving the subsequent third and fourth rounds of optimization clear points to land.

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

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

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

我们正在解决 IRify 处理大项目时的性能问题，当前 IRify 在处理大型项目时面临的主要性能瓶颈：

为了解决这些问题，我们引入了智能的依赖追踪 + 变更检测机制，实现「有变编译，无变复用」的高效构建模式。

【前文回顾】

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

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

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

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

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

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

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

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

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

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