Add CodeQL Workflow for Code Security Analysis

Add CodeQL Workflow for Code Security Analysis

This pull request introduces a CodeQL workflow to enhance the security analysis of our repository. CodeQL is a powerful static analysis tool that helps identify and mitigate security vulnerabilities in our codebase. By integrating this workflow into our GitHub Actions, we can proactively identify and address potential issues before they become security threats.

We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
- Runs on every pull request (functionality to run on every push to main branches is included as a comment for convenience).
- Runs daily.
- Excludes queries with a high false positive rate or low-severity findings.
- Does not display results for git submodules, focusing only on our own codebase.

To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.

Once this pull request is merged, the CodeQL workflow will be active and automatically run on every push and pull request to the main branch. To view the results of these code scans, please follow these steps:
1. Under the repository name, click on the Security tab.
2. In the left sidebar, click Code scanning alerts.

Additional Information:
- You can further customize the workflow to adapt to your specific needs by modifying the workflow file.
- For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation ( and

Signed-off-by: Brian <>
1 file changed
tree: 62586df63139125d22b7e159de5cfe078004ec02
  1. .github/
  2. conan-wrapper/
  3. docs/
  4. examples/
  5. extra/
  6. generator/
  7. spm-test/
  8. spm_headers/
  9. tests/
  10. tools/
  11. .gitignore
  12. AUTHORS.txt
  13. BUILD.bazel
  15. CHANGELOG.txt
  16. CMakeLists.txt
  19. library.json
  20. LICENSE.txt
  21. Package.swift
  22. pb.h
  23. pb_common.c
  24. pb_common.h
  25. pb_decode.c
  26. pb_decode.h
  27. pb_encode.c
  28. pb_encode.h

Nanopb - Protocol Buffers for Embedded Systems

Latest change Weekly build

Nanopb is a small code-size Protocol Buffers implementation in ansi C. It is especially suitable for use in microcontrollers, but fits any memory restricted system.

Using the nanopb library

To use the nanopb library, you need to do two things:

  1. Compile your .proto files for nanopb, using protoc.
  2. Include pb_encode.c, pb_decode.c and pb_common.c in your project.

The easiest way to get started is to study the project in “examples/simple”. It contains a Makefile, which should work directly under most Linux systems. However, for any other kind of build system, see the manual steps in README.txt in that folder.

Generating the headers

Protocol Buffers messages are defined in a .proto file, which follows a standard format that is compatible with all Protocol Buffers libraries. To use it with nanopb, you need to generate .pb.c and .pb.h files from it:

python generator/ myprotocol.proto  # For source checkout
generator-bin/nanopb_generator myprotocol.proto        # For binary package

(Note: For instructions for nanopb-0.3.9.x and older, see the documentation of that particular version here)

The binary packages for Windows, Linux and Mac OS X should contain all necessary dependencies, including Python, python-protobuf library and protoc. If you are using a git checkout or a plain source distribution, you will need to install Python separately. Once you have Python, you can install the other dependencies with pip install --upgrade protobuf grpcio-tools.

You can further customize the header generation by creating an .options file. See documentation for details.

Running the tests

If you want to perform further development of the nanopb core, or to verify its functionality using your compiler and platform, you'll want to run the test suite. The build rules for the test suite are implemented using Scons, so you need to have that installed (ex: sudo apt install scons or pip install scons). To run the tests:

cd tests

This will show the progress of various test cases. If the output does not end in an error, the test cases were successful.

Note: Mac OS X by default aliases ‘clang’ as ‘gcc’, while not actually supporting the same command line options as gcc does. To run tests on Mac OS X, use: scons CC=clang CXX=clang++. Same way can be used to run tests with different compilers on any platform.

For embedded platforms, there is currently support for running the tests on STM32 discovery board and simavr AVR simulator. Use scons PLATFORM=STM32 and scons PLATFORM=AVR to run these tests.

Build systems and integration

Nanopb C code itself is designed to be portable and easy to build on any platform. Often the bigger hurdle is running the generator which takes in the .proto files and outputs .pb.c definitions.

There exist build rules for several systems:

And also integration to platform interfaces: