Code Audit

1. What Is a Code Audit?

A code audit is a systematic examination of software source code aimed at discovering security vulnerabilities, logic flaws, and coding standards violations.

It is the core practice of white-box testing in cybersecurity. Compared to penetration testing (black-box, attacking from the outside), a code audit looks directly under the hood and can uncover deeper, hidden risks.

Core Objectives:

• Uncover security vulnerabilities: identify high-risk threats such as SQL injection, cross-site scripting (XSS), command execution, and more.
• Inspect business logic: discover privilege escalation, payment tampering, process bypasses, and other issues that automated scanners miss.
• Ensure compliance and quality: verify that code meets industry standards (e.g., China's Information Security Classified Protection 2.0) and eliminate hard-coded passwords, dead code, and the like.

In practice, the typical approach combines automated tooling (SAST scanning) with in-depth manual review.

• Automated scanning: tools quickly sweep the entire codebase to flag known risk patterns (e.g., format string vulnerabilities).
• Manual audit (the core): a security expert traces tainted data flows — following user input all the way into sensitive functions — and carefully reasons through complex logic such as authentication and cryptographic implementations. Business logic flaws, in particular, can almost only be discovered by a human reading the code.

When to Perform a Code Audit:

Audits are typically conducted before go-live or around major version releases. For systems in finance, government, and internet infrastructure, a code audit is a mandatory compliance “ticket to entry.”

2. The Audit Process

2.1 The Standard Five-Step Audit Process

• Information gathering: confirm the tech stack (Java/Python/Go/JS, etc.), framework versions, and dependency inventory (to identify components with known vulnerabilities).
• Static scanning: run automated tools (e.g., Fortify, SonarQube) for an initial “health check” and triage high-severity alerts.
• Manual verification: deduplicate false positives, focus on tracing taint propagation paths (from source/sink parameters → function processing points), and dive deep into auditing the core permission checks and cryptographic logic.
• Exploitation verification: for suspected vulnerabilities, write a PoC (proof of concept) and actually test it to confirm the flaw is truly exploitable, ruling out environmental factors.
• Report delivery: compile the list of findings, accompanied by remediation advice and verification screenshots.

2.2 Mainstream Audit Tools

• Heavyweight Commercial (Enterprise-grade)
• • Fortify (comprehensive rule set, well-suited for Java/C++) and Checkmarx (interactive scanning with a relatively lower false-positive rate).
• Lightweight Open Source
• • SonarQube: focuses on code anomalies.
  • Semgrep: customizable rules, ideal for tailored audits.
  • CodeQL: exceptionally strong semantic analysis, suited for zero-day hunting.

2.3 Points to Note

“High-Risk Zones” Beginners Most Easily Overlook

• Identity and privilege escalation: checking only whether a user is logged in, without verifying that the “operator ID” matches the “resource owner ID.”
• File operations: allowing uploads with JSP/PHP extensions, or path strings containing ../ that lead to directory traversal.
• Framework-specific quirks: e.g., unauthenticated access to Spring Boot Actuator endpoints, Shiro deserialization vulnerabilities.

2.4 Deliverables

Typically include a “Vulnerability Risk Classification Table” (Critical/High/Medium/Low), code remediation examples (not always mandatory but expected as standard practice, with a diff comparison), and secure coding guideline recommendations.

2.6 Code Auditing in the Current Market

• Traditional manual audit school: Some projects have extremely high confidentiality requirements and strictly forbid the use of public-cloud AI models. Yet, at present, these teams lack their own on-premises large model, leaving them with no choice but pure manual effort.
• LLM-only audit school: Feed the code directly to a large language model and let it find vulnerabilities.
• • The advantage is that it can understand business logic and uncover deep logical flaws. However, it faces engineering challenges such as "attention dilution (model hallucinations)," poor results from unfiltered full-code dumps, high output variance, and steep costs.
• Static Analysis (SAST) + AI Augmentation
• • This is currently the most mainstream and pragmatic path. Traditional tools like Semgrep and CodeQL perform a rapid first-pass scan, and then AI conducts in-depth triage on the findings, dramatically slashing the false-positive rate.
• Going further: AI is evolving into AI Agents with full closed-loop capability
• • Deep mining: Analyze cross-file data flows, call chains, and complex business context.
  • Auto-verification: Write PoC (proof-of-concept) code and verify the vulnerability's authenticity inside a sandbox.
  • Smart patching: Auto-generate and test patches, pending final confirmation from the developer.

The integration of AI and code auditing has entered the deep waters of "human-machine collaboration." The most effective model today combines the deterministic reliability of traditional SAST tools with the semantic understanding of large language models.

The future of code auditing will increasingly depend on AI Agents capable of autonomous planning, verification, and remediation. While challenges still remain, these agents are steadily reducing the heavy and repetitive workload of security experts, allowing them to focus more on tackling increasingly complex business-logic vulnerabilities.

III. Dangerous Component Detection

3.1 Inspecting pom.xml

3.1.1 Introduction

• This file manages: source code, configuration files, developer information and roles, issue tracking systems, organizational information, project licensing, project URLs, project dependencies, and more.
• A complete pom.xml file is placed in the root directory of the project.

3.1.2 Secure Component Versions

fastjson secure version:

• Requires version 1.2.80 or above

Shiro secure version: 1.8.0

• Prior to 1.8.0, when Apache Shiro is used with Spring Boot, a specially crafted HTTP request may lead to authentication bypass.
• Prior to 1.7.1, when Apache Shiro is used with Spring, a specially crafted HTTP request may lead to authentication bypass.
• Versions prior to 1.7.0 contain an authentication bypass vulnerability; a specially crafted HTTP request may lead to authentication bypass.

Log4j2 secure versions

• Java 8 and above: >= 2.17.1
• Java 7 and above: >= 2.12.4
• Java 6 and above: >= 2.3.2

XStream secure version

• 1.4.14 or above

🖥️ Web Servers & Proxies

🗄️ Application Servers

📨 Messaging Middleware

💾 Caching & Database Middleware

☁️ Microservices & Cloud Native

🧩 Development & Integration

📚 Common Components & Libraries

🌐 Frontend & Full-Stack Frameworks

🏢 Commercial & Domestic Middleware

For commercial or domestic middleware, version information is often not publicly available. The most reliable approach is to contact the vendor for security updates.