Apple Brings Whole-Program C++ Hardening to Clang

Apple has added a new tool to the upstream LLVM project that could change how teams harden large C++ codebases. The clang-ssaf-driver, merged into LLVM Git this week, analyzes an entire project as it builds and then rewrites source code based on what it finds.

The driver is part of Clang’s Scalable Static Analysis Framework (SSAF). It’s expected to ship with LLVM 24 next spring.

What SSAF Does

Most static analysis in Clang today works one translation unit at a time. That’s fine for catching local bugs. But it misses context. A function in one file may receive a pointer from another file, and the analyzer can’t see how that pointer was created or how big the buffer behind it is. That gap leads to false positives, missed issues, or both.

SSAF tackles this with summaries. Jan Korous of Apple’s Static Security Tools group laid out the idea in an RFC on the LLVM forums. The framework extracts facts from each translation unit, links those summaries into one view, runs whole-program analysis on that view, and pushes the results back to each file.

Apple stated two goals in the RFC. One was a source-rewriting tool that applies security hardening across entire C++ codebases. The other was giving the Clang Static Analyzer cross-file reach to improve accuracy and cut false positives.

To make that work, SSAF needs stable names for functions, parameters, and other program entities that hold up across separately compiled files. It uses Clang’s Unified Symbol Resolution identifiers for that, extended to cover parameters and return values.

The Driver Ties It Together

Earlier SSAF pieces already landed upstream, including an analyzer tool and Clang plumbing for generating source edits. The new driver is what makes the pipeline usable on a real project.

It drives make-based builds through a companion orchestrator. As the project compiles, the driver collects proposed edits and writes them out as a patch. It prints a transformation report the way a compiler prints diagnostics. It also writes the report in SARIF, the format many code scanning and security dashboards already read.

Pass the –apply flag and the driver applies the edits using clang-apply-replacements. Then it checks that the source files match what the patch says they should. That check matters. Automated rewrites are only useful if you can trust that what landed is what was proposed.

In the pull request, Korous said the aim is a general-purpose analysis and transformation driver that isn’t tied to any single use case.

The First Rule: Bounded Buffers

SSAF is built to accept new transformation rules. One of the first is cpp-bounded-buffers. It finds raw C++ pointers and arrays that need bounds and rewrites them to use bounded_ptr and bounded_array.

That goes straight at one of the oldest problems in C and C++. Out-of-bounds reads and writes are still a leading source of serious vulnerabilities. The fix is known in principle: carry bounds with the pointer and check them. The hard part is doing that across millions of lines of code without breaking anything.

Doing it by hand is slow and error-prone. Doing it file by file misses how data moves between components. Whole-program analysis is what lets a tool figure out which pointers need bounds and where those bounds come from.

Why DevOps Teams Should Care

Memory safety has moved from a research topic to a policy and procurement issue. Government agencies have pressed software makers to show how they plan to reduce memory safety bugs. Rewriting everything in Rust isn’t realistic for most organizations with large C++ estates. Hardening the code they already have is.

SSAF fits that path. It runs as part of the build and produces patches and SARIF reports, so it slots into workflows teams already use. A pipeline could run the driver, post the report to a code scanning dashboard, and open a pull request with the patch for human review.

Trust is the real hurdle. “Teams will trust automated source rewrites the way they trust any automation: through a record of patches that land clean and break nothing,” said Mitch Ashley, VP and Practice Lead, CTO & Tech Buyers Software Lifecycle Engineering at The Futurum Group. “SSAF checks each applied patch and reports in SARIF, so teams can build that record inside the pipelines they already run.”

There’s a Swift angle too. Apple has proposed a “Scalable Analysis” build action for swift-build that would run SSAF’s extract, link, analyze, and edit steps during a build. That suggests Apple wants this to work across build systems, not just make.

What to Watch

This is early. The driver supports make-based projects today, and the first rule targets one class of bug. Teams will want to see how it handles large, messy codebases with custom builds, how noisy the proposed edits are, and how much whole-program analysis costs in build time at scale.

The framework is also open and extensible, which raises a bigger question: who writes the next rules?

“Watch for the first transformation rules that come from outside Apple,” Ashley said. “That is when SSAF stops being Apple’s tool and becomes the Clang community’s.”

For now, the takeaway is simple. Apple is putting serious engineering into automated, whole-program hardening for C++, and it’s doing the work in the open. Teams with large C and C++ codebases should keep an eye on LLVM 24.