Hi Osquery team, may i know all the libs under osquery/libraries/ are only used for building osquery, is that correct?

Do you want to know a complete list of them?

Do you want to know a complete list of them? can you offer it?

We have a list, just a moment

the reason i am asking this question is because we are scanning the code of osquery for static code analysis, and we found there are a lot of warning from libs under this folder, can you make sure all the libs under this folder only used for building, because we can ignore these warning if that is the case.

We recently set up our own monitoring of known CVEs for libraries, and so we are aware of many of them and have been delaying updating of some that are known not to affect osquery. Static analysis can sometimes be a false positive because it detects a library but doesn't know how much of it is used or in what way.

I’m curious though @wennan.he what you mean with “only used for building”, as opposed to what? Those are third party libraries that are linked against the osquery binary to provide core functionality and table functionality. The osquery community doesn’t develop them/maintain them, a part from one that comes from ToB (ebpfpub).

They are used to build, linked in, and the the result is run.

@Stefano Bonicatti i messed it up, i just thought they are only tools used for building and yes they are included in the package.

We don't scan the code itself, we have a CI job to check a public database for any news on a list of topics called CPEs that correspond to the manually created list of libraries (the manifest)

i dont get it

No, we search for CVEs of the third party libraries we use on the NVD database, using the information in the libraries manifest that we update manually (https://github.com/osquery/osquery/blob/master/libraries/third_party_libraries_manifest.json), to create a query using the CPE format.

ok so what third party osquery leverages?

Third party … libraries? The list is the one provided previously by Mike, and it’s basically the same you can find under the

libraries/cmake/source

folder (+

openssl

which is in

libraries/cmake/formula

).

I think we were having a miscommunication, but, to be clear, the libraries in

osquery/libraries

in the source tree (that are git submodules, and populated during the 'configure' step of the build) are built into the compiled osquery. Because osquery only uses some of the functionality of each library, sometimes only part of the library's source code is built into osquery. This is one reason that static analysis can indicate a CVE in the libraries in the source tree, but it is not present in osquery. Another reason is that osquery doesn't use the library in a way that would ever be impacted by the vulnerability. For instance, a compression library like

zlib

that has a vulnerability in compression, but osquery only ever uses it to decompress and would not be affected. Or vice versa.

that make sense, and one more question, why is NVD, how could you be confident this is most comprehensive data source of cve?

We evaluated several vulnerability knowledge repositories, and chose this one. If a vulnerability has a CVE, we are confident it will be published at the NVD. For vulnerabilities without a CVE, they are effectively unknown and there is nothing we can track. For libraries without a CPE, if there are any, then NVD will not work well to track CVEs in those libraries. Did you have a different database in mind to suggest?

i don't have it more.