osquery

Versions over the last several years are available https://osquery.io/downloads/

The project uses GitHub issues to track bugs, known problems, questions, and feature requests https://github.com/osquery/osquery/issues

This is achieved via GitHub project Security Advisories https://github.com/osquery/osquery/security/advisories?state=published

This is documented in the Security Policy on GitHub https://github.com/osquery/osquery/security/policy

The project uses a Clang Format configuration to communicate coding policy https://github.com/osquery/osquery/blob/master/.clang-format and enforces this via CI

See above and the corresponding build requirement https://github.com/osquery/osquery/blob/master/.github/workflows/build.yml that enforces style checks.

Met, with the use of CMake throughout the project.

There are several options to control the debug flags https://github.com/osquery/osquery/blob/master/cmake/options.cmake but the standard CMake options for building debug versions is the supported and recommended method.

The inter-directory dependencies are explicitly stated for each build target within CMake.

Building the project on Linux, then removing all build configuration and artifacts and retrying the build produces the same bit-for-bit binary artifacts.

The convention is to use the published packages for various operating systems (deb, rpm, msi, pkg).

CMake allows a person building and installing the software to select the installation root.

Facilitated by CMake.

All of the third-party libraries are defined in CMake https://github.com/osquery/osquery/tree/master/libraries

Updates to dependencies are updated in response to known vulnerabilities and new desired feature requests.

Here is an example of the above https://github.com/osquery/osquery/commit/0e9efb1497037ded21e8679dda09547d5b0fecd0 demonstrating how one may update a third-party dependency.

This is done to the extent possible, however it is a product feature for osquery to be "widely deployable" meaning support on Linux for glibc 2.12 and greater.

This is facilitated by CMake and CTest, instructions are found within the building documentation https://osquery.readthedocs.io/en/latest/development/building/

The Pull Request template asks contributors to check that their features include tests https://github.com/osquery/osquery/blob/master/.github/PULL_REQUEST_TEMPLATE.md

See the Pull Request https://github.com/osquery/osquery/blob/master/.github/PULL_REQUEST_TEMPLATE.md

See the cmake configuration for the project https://github.com/osquery/osquery/blob/master/cmake/flags.cmake, Wall and pedantic among others are set.

The contributing guidelines and "first principles" implement a safe by default policy https://github.com/osquery/osquery/blob/master/CONTRIBUTING.md#guidelines-for-contributing-features-to-osquery-core

To the extent possible the project enforces best practices for TLS connections https://github.com/osquery/osquery/blob/master/osquery/remote/transports/tls.cpp#L146

Please see above

Please see above

Please see above

The published packages are signed to the extent possible and documentation is on the website https://osquery.io/downloads/official/4.7.0

See above

There are various controls for restricting SQLite functionality, which tables are available at runtime, but the goal is to support any SQL input.

Stack protectors, full relro, and other compiler-available hardening options are used https://github.com/osquery/osquery/blob/master/cmake/flags.cmake

We have a document in the root directory that explains all of these points. https://github.com/osquery/osquery/blob/master/ASSURANCE.md

cppcheck and clang-tidy, merged in https://github.com/osquery/osquery/pull/5730

osquery has multiple fuzzing harnesses run by oss-fuzz periodically. You can find the configuration in the oss-fuzz GitHub repo https://github.com/google/oss-fuzz/tree/master/projects/osquery and the logs from the fuzzers on the oss-fuzz build status page https://oss-fuzz-build-logs.storage.googleapis.com/index.html#osquery