OpenVINO Intel NPU Compiler

The project provides a clear upgrade path between releases. While older versions are not maintained long-term, each new release includes release notes documenting changes, compatibility considerations, and any required updates for users. Upgrading typically involves installing the new version and rebuilding the relevant artifacts, which is the expected and supported workflow for the project.

GitHub issues are used https://github.com/openvinotoolkit/npu_compiler/issues. Customers can also report questions and issues to https://community.intel.com/t5/Product-Support-Forums/ct-p/product-support-forums

N/A — No publicly reported or disclosed vulnerabilities have been resolved in the last 12 months, so there were no reporters to credit.

The project has a documented vulnerability response process. The procedure for reporting, triaging, and responding to security issues is described in the SECURITY.md file, which provides clear instructions for responsible disclosure. https://github.com/openvinotoolkit/npu_compiler/blob/develop/Security.md

The project defines the required coding style guidelines in its CONTRIBUTING.md document. Contributors are expected to follow these guidelines for all major languages used in the project.
URL: https://github.com/openvinotoolkit/npu_compiler/blob/develop/CONTRIBUTING.md

The project automatically enforces С++ coding style. We use clang-format integrated via pre-commit and run it in GitHub Actions CI, so contributions are automatically checked (and can be auto-formatted) to comply with the configured C/C++ coding style.

The project’s CMake-based build system honors standard compiler and linker environment variables such as CC, CXX, CFLAGS, CXXFLAGS, and LDFLAGS. User-provided values are respected and incorporated into the build, with CMake extending (but not replacing) them as needed. This fully aligns with the requirement for native binary builds.

The project’s CMake-based build and installation system preserves debugging information whenever it is requested through the build type or compiler flags. Debug symbols (e.g., -g) are not stripped unless explicitly configured by the user, so the build system aligns with the recommended practice.

The project’s CMake-based build system does not recursively build subdirectories in a way that breaks cross-directory dependencies. CMake’s target-based dependency model ensures correct build ordering and avoids the issues associated with recursive make builds, fully satisfying this requirement.

The project’s build and release processes are stable and CI-driven, and rebuilding the same source with the same toolchain typically produces functionally equivalent binaries. However, we do not currently guarantee strict bit-for-bit reproducible builds (e.g., due to timestamps, build paths, and toolchain variability). We plan to reduce sources of non-determinism and document a fully reproducible build process in the future.

The project provides standard mechanisms for installing and uninstalling the software. Users can build and install from source using common CMake workflows (e.g., cmake --build . and cmake --install . with a chosen prefix).

The project’s CMake-based installation system follows standard conventions for selecting installation locations. Users can specify custom paths through CMAKE_INSTALL_PREFIX and other standard variables. This fully satisfies the requirement for conventional installation path control.

The project provides a standard and straightforward way for developers to install all components needed for development, including build dependencies, tests, and the test environment. Using commonly-used conventions such as CMake configuration and build workflows, developers can quickly install the full environment (cmake .., cmake --build ., cmake --install .) and run the automated test suites. Documentation describes the required steps, making it easy to onboard new contributors.

The project lists its external dependencies in a computer-processable way. Third-party components are tracked via Git submodules and the thirdparty/ directory, which are defined in the repository’s .gitmodules file.
URL: https://github.com/openvinotoolkit/npu_compiler/blob/develop/.gitmodules

The project monitors its external dependencies for known vulnerabilities. In the private upstream, SDL and Black Duck (BDBA) scans are routinely performed to detect and assess vulnerabilities in third-party components. Identified issues are triaged, and exploitable vulnerabilities are fixed or verified as non-exploitable as part of the standard security review process.

The project makes it easy to identify and update reused externally maintained components. External dependencies are clearly tracked through Git submodules and the thirdparty/ directory, which allows updating them in a controlled and transparent way. When a vulnerability is detected in an external component, it can be updated or patched directly via the submodule or third-party snapshot update process.

The project makes an effort to avoid deprecated or obsolete APIs when FLOSS alternatives are available. We actively monitor deprecations in our technology stack and update code accordingly during regular maintenance and refactoring. This ensures that contributors and users rely on modern, well-supported functionality.

The project runs an automated test suite on every check-in to the shared repository. Our GitHub Workflows CI builds the software and executes both gtest-based and LIT-based tests on at least one primary branch. Each run produces a full pass/fail report that is publicly visible in the CI results.

The project adds regression tests for a significant portion of recently fixed bugs. Many issues resolved in the last six months include accompanying gtest or LIT regression tests to ensure they do not reoccur. These tests are integrated into our automated CI test suite. This practice is also enforced by code reviewers and code owners.

The project has a formal written policy requiring that tests be added for any major new functionality. This requirement is documented in the CONTRIBUTING.md guidelines, which state that new features must include appropriate gtest or LIT tests as part of the review and acceptance process.

The project documents the expectation that new functionality should include corresponding tests. This requirement is reflected in our contribution and review guidelines, where change proposals are expected to include appropriate unit or LIT tests when introducing new features.

The project actively addresses compiler and tooling warnings. Our build configuration treats many warnings as errors (e.g., via -Werror or equivalent), ensuring that they must be resolved before code can be merged. Remaining warnings are tracked and regularly reviewed through our CI pipelines to maintain code quality.

The project implements secure design principles where applicable. Our development process is guided by established SDL practices, with a Security Champion involved in reviews and design discussions. We apply principles such as least privilege, defense in depth, input validation, and avoidance of undefined behavior, and we use Coverity, CodeQL, ASan/TSan, and other tools to ensure secure implementation throughout the codebase.

The project cryptographically signs all release artifacts intended for widespread use using Sigstore Cosign with keyless signing (Fulcio + Rekor). This ensures that no private signing key is stored on or distributed through public systems. Release notes document how users can verify signatures and obtain the corresponding public certificate and transparency log entries. Public verification instructions and links to Sigstore records are included in each release.

The project validates all inputs that may originate from untrusted or external sources. Model files, configuration parameters, and command-line inputs are checked for correctness and consistency. The OpenVINO, NPU Compiler and MLIR infrastructure include extensive validation passes, verifiers, and diagnostics, and invalid inputs are rejected with clear error messages. This ensures that only well-formed and allowed inputs are processed.

The project uses hardening mechanisms to reduce the likelihood that software defects lead to security vulnerabilities. For native binaries, we rely on compiler and linker hardening options provided by our toolchains (e.g., stack protection and other mitigation flags in release builds), and we use sanitizers such as ASan/TSan in non-production configurations to detect memory and concurrency issues early. These measures complement our general secure development practices.

The static analysis tools we use include built-in rulesets for detecting common vulnerabilities in our language and environment. CodeQL provides security-focused queries that identify typical weakness patterns, and Coverity includes comprehensive checkers for memory safety, concurrency issues, and other vulnerability classes.

The project includes software written in memory-unsafe languages (C/C++), and we routinely use dynamic analysis tools to detect memory safety issues. In the private upstream codebase, AddressSanitizer (ASan) and ThreadSanitizer (TSan) are run in nightly pipelines, providing continuous detection of memory errors such as buffer overflows, use-after-free, and data races.