# IKOS: NASA's Abstract Interpretation Static Analyzer for C and C++

> IKOS is a sound static analyzer for C and C++ built on abstract interpretation, distributed by NASA's Software Verification and Validation group. It proves the absence of runtime errors in bounded programs, and its precision comes with a real learning curve.

**NASA-SW-VnV/ikos** — Static analyzer for C/C++ based on the theory of Abstract Interpretation.

- Repository: https://github.com/NASA-SW-VnV/ikos
- Stars: 3,170 · Forks: 222
- Language: C++
- License: NOASSERTION
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/nasa-sw-vnv-ikos

## What IKOS solves for C and C++ codebases

Most C and C++ analyzers trade soundness for speed. They report what they can prove and stay silent about the rest, which means a clean run is not evidence that the program is free of undefined behavior. IKOS takes the opposite position. The README describes it as a static analyzer based on the theory of Abstract Interpretation, and it implements scalable analyses for detecting and proving the absence of runtime errors. The word proving matters here. IKOS reports a check as safe, error, unreachable or warning, and the README is explicit that a warning may mean the statement fails for some executions, that the analyzer lacked information, or that the analyzer was not powerful enough to prove safety. That third case is the honest part: IKOS tells you when it does not know. The intended audience is engineers working on safety-critical or embedded C and C++ who need more than a style checker. It is also a library. The README states that IKOS started as a C++ library for building sound static analyzers, providing control-flow graphs, fixpoint iterators and numerical abstract domains, and that it is independent of a particular programming language. So there are two products in one repository: a usable analyzer and a toolkit for people who want to build their own.

## How the analysis pipeline works from source to report

The README shows the pipeline directly in the output of a run. IKOS compiles the source, runs ikos preprocessor, runs ikos analyzer, translates LLVM bitcode to AR, then runs liveness analysis, widening hint analysis and interprocedural value analysis before checking properties for each entry point. That sequence tells you a lot about the design. The frontend is LLVM, so IKOS sees the program as LLVM bitcode rather than raw source, which is why it accepts both .c and .cpp files and .bc bitcode files. The abstract interpretation core lives in the ar directory of the repository, and the analyzer that wraps it lives in analyzer. The widening hint analysis is a precision step: widening is the mechanism that forces fixpoint iteration to terminate, and hints let IKOS narrow the result before it converges, which reduces false warnings. The interprocedural value analysis means IKOS follows calls across function boundaries rather than analyzing each function in isolation, and the README lists an option to switch between interprocedural and intraprocedural analysis when you need speed over precision. Results are written to a result database, output.db, in the current working directory. That database is the artifact you inspect later with ikos-report or ikos-view, which is a sensible split: the analysis is expensive, the reporting is cheap and repeatable.

## Installing IKOS with Homebrew and running a first analysis

The README recommends Homebrew for Linux and macOS, and points Windows users at Windows Subsystem for Linux. Install Homebrew first, then add the NASA tap and the formula. The project does not ship a Windows binary, so WSL is the supported path there.

```bash
brew install nasa-sw-vnv/core/ikos
```

The README's own example is a ten-line C file named loop.c with a global array of ten integers and a loop that writes indices 0 through 9 before writing a[10] after the loop. Save it as loop.c, then run the analyzer on the source file directly:

```bash
ikos loop.c
```

The output starts with compilation and preprocessing lines, then reports the analysis stages. The summary in the README shows seven total checks, five safe, two definite unsafe, and zero warnings, followed by the line "The program is definitely UNSAFE". The two errors point at line 8 and line 9, both described as buffer overflow trying to access index 10 of a global variable of 10 elements. If the report is too large for a terminal, the README gives two alternatives: ikos-report output.db for a terminal view and ikos-view output.db for a web interface. For a whole project rather than a single file, the README points to ikos-scan, documented in analyzer/README.md.

## Where IKOS gives you warnings instead of answers

The four-status scheme is the most important thing to understand before trusting a run. Safe means proven. Error means the statement always fails or is unreachable. Unreachable means the statement is never executed. Warning is the catch-all, and the README lists three distinct reasons a warning can appear. Only the first is a real defect for some inputs. The second is a dependency on external input the analyzer cannot see. The third is analyzer weakness. That third category grows with the complexity of the code, and it is the reason IKOS ships a model library mechanism: the README points to modeling library functions to reduce warnings, which means calls into libc and similar code are a known source of imprecision out of the box. The analysis assumptions page in analyzer/README.md exists for the same reason, because IKOS reasons under stated assumptions about the environment. If your code depends on hardware addresses, the README lists a hardware addresses option, and if you are analyzing firmware built with a cross-compiler, there is a dedicated section for that. None of this is hidden, but it means the first run on a real project will not look like the loop.c example. Expect to tune domains, entry points and modeling before the warning count becomes meaningful.

## IKOS compared with Cppcheck and clang-tidy

The two tools people usually reach for first are Cppcheck and clang-tidy, and they solve a different problem. Cppcheck is a pattern-based checker: it looks for known risky constructs and reports them quickly, with no fixpoint computation and no numerical domain. clang-tidy is a linter built on Clang's AST, aimed at style, modernization and a set of bug-prone idioms. Both are fast enough to run on every commit, and neither claims soundness. IKOS computes a fixpoint over an abstract domain to establish that a property holds for all executions it can model, which is why it can print safe next to a check and why the run takes longer than a lint pass. The trade is precision and proof against speed and coverage of style concerns. A practical arrangement is to run clang-tidy or Cppcheck in the edit loop and reserve IKOS for release candidates or for modules where a runtime error would be costly. IKOS will not tell you that a variable name is poor or that a construct is deprecated, and Cppcheck will not prove that an array index stays in bounds. They are complements, not substitutes.

## Licence, maintenance and the cost of upgrading

IKOS is released under the NASA Open Source Agreement version 1.3, and the repository carries LICENSE.pdf and LICENSE.txt at the top level. NOSA 1.3 is not a common licence, and it is not the Apache or MIT text many teams have already cleared with legal. It includes terms that differ from permissive licences, so if you plan to redistribute IKOS or build a product around it, read LICENSE.pdf rather than assuming it behaves like a standard open source licence. This is not legal advice. On maintenance, the last push to the default branch was on 2026-05-31, and the most recent release is v3.5 from 2024-12-31, following v3.4 in October 2024 and v3.3 in April 2024. The release cadence visible in that list is roughly one tagged release per few months, and the repository is not archived. The build instructions in the README target advanced users who want to package IKOS or experiment with the codebase, and the dependency list starts with a C++14 compiler. Building from source is a real cost if Homebrew is not an option on your platform, and the README itself steers everyone else toward the package. Upgrading between releases means re-running your analysis and re-checking your warning baseline, because abstract domain improvements change which checks are proven safe and which become warnings.

## Conclusion

Adopt IKOS if you need sound proofs over bounded C or C++ code and can invest time in understanding abstract domains, entry points and the warning semantics. Do not adopt it as a drop-in replacement for a fast linter, and do not expect it to reason about unbounded concurrency or heap shapes it cannot model. Before committing, install it with brew install nasa-sw-vnv/core/ikos, run the loop.c example from the README, and check whether the warnings you get are errors, warnings or unreachable checks in the summary. The status definitions in the README are the first thing to read, because a warning is not the same as a bug.

## FAQ

### How do I install IKOS on Linux or macOS?

The README recommends Homebrew and gives the command brew install nasa-sw-vnv/core/ikos after Homebrew itself is installed. For Windows, the README suggests using Windows Subsystem for Linux rather than a native build.

### What languages and file types can IKOS analyze?

IKOS provides a C and C++ static analyzer based on LLVM, and the ikos command takes a source file with a .c or .cpp extension or an LLVM bitcode file with a .bc extension. The underlying library is described as independent of a particular programming language.

### What does a warning mean in an IKOS report?

The README lists three possible meanings: the statement results in an error for some executions, the analyzer did not have enough information to conclude, or the analyzer was not powerful enough to prove the absence of errors. A warning is therefore not automatically a confirmed defect.

### How do I inspect a large IKOS analysis report?

The README says to use ikos-report output.db to examine the report in a terminal, or ikos-view output.db to examine it in a web interface. The output.db result database is created in the current working directory when you run ikos on a file.

### What coding language is used at NASA?

The repository does not answer this. IKOS itself is written in C++ and analyzes C and C++ programs, but the project material says nothing about which languages NASA uses elsewhere.

## Sources

- [Issues](https://github.com/NASA-SW-VnV/ikos/issues)
- [NASA-SW-VnV/ikos on GitHub](https://github.com/NASA-SW-VnV/ikos)
- [README](https://github.com/NASA-SW-VnV/ikos/blob/master/README.md)
- [Releases](https://github.com/NASA-SW-VnV/ikos/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nasa-sw-vnv-ikos