AppSecNews
SAST Open source Established

Infer

by Meta

A static analyzer built on separation logic that proves properties about memory and concurrency, catching null dereferences, leaks and data races.

Visit fbinfer.com (leaves AppSecNews, opens in a new tab) Leaves AppSecNews for the vendor's own site.

No endorsements yet

Run Infer in production? A named recommendation helps the next team shortlisting it.

Recommend this tool

Endorsers verify their identity through LinkedIn. Titles and companies are self declared, shown as they were when each person signed, and reviewed by an editor before anything is published. Endorsements are never paid for.

What we still need to verify : 1 point in this profile is not yet confirmed against vendor documentation.
  • Current frontend language support, which varies by analyzer: confirm against project docs

Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.

What it does

Infer is a program analyzer grounded in formal methods rather than pattern matching. Its original engine uses separation logic with bi-abduction, a technique that infers the preconditions a function requires about the heap and the postconditions it establishes, then composes those summaries up the call graph. The practical consequence is that Infer analyzes functions independently and reuses their summaries, which is what lets it scale to very large codebases and, importantly, analyze only what changed between two commits rather than the whole tree.

Several analyzers ride on that foundation. Pulse handles memory lifetime issues including use after free, null dereference and leaks. RacerD reasons about lock ordering and shared mutable state to report data races without needing the race to occur at runtime. Eradicate checks nullability annotations for consistency, and cost analyzers flag complexity regressions. Infer hooks into the build by wrapping the compiler invocation, so it sees exactly the translation units your build produces, and reports findings with a trace explaining the reasoning path.

Where it fits

Infer runs in CI, most effectively in differential mode on pull requests: analyze the base, analyze the head, report only findings introduced by the change. That mode is how it was designed to be used at scale and it is what keeps the signal usable on a codebase with existing issues. It requires a working, wrappable build, which is a real prerequisite. The owner is usually a platform or build engineering team rather than security, since the defect classes overlap heavily with correctness.

Strengths

  • Catches concurrency and memory lifetime defects that testing rarely reproduces and that pattern-based scanners cannot see at all.
  • Compositional summaries make differential analysis on pull requests practical even on very large repositories.
  • Low false positive rate by static analysis standards, because findings rest on inferred preconditions rather than heuristics.
  • Proven at large scale on mobile and server codebases.

Limitations

  • Its focus is correctness and memory safety, not web application security. It will not find SQL injection, cross-site scripting or authorization flaws, so it is not a replacement for a security scanner.
  • Build integration is fiddly, and unusual or non-reproducible build systems can make getting a first clean run a multi-day exercise.
  • Language support is uneven across analyzers, and some frontends are much less mature than the Java and C family ones.

Who it suits

A strong fit for teams shipping large native or Android codebases where crashes and races are the dominant risk. It is the wrong tool if your threat model is a web application taking untrusted input, where you need taint analysis that Infer does not provide.

Used Infer? Recommend it under your own name and title.

Recommend this tool