(Beta) C/C++ analysis for Conan and vcpkg for SonarQube Advanced Security

SonarQube Cloud Announcements
,
1

Hello folks!

We introduced SonarQube Advanced Security to extend the core SonarQube values of quality and security to include the use of third-party dependencies, so developers can focus on building better, faster. Today we’re happy to announce extending that value to more of our customers’ projects.

We are announcing beta support for C and C++ projects built using the Conan and vcpkg package managers.

What’s included

This includes detection of publicly posted vulnerabilities, and analysis of license risks, in dependencies of projects built using either Conan or vcpkg

How to use it

During our beta period, you must enable this at the analysis level, by passing the sonar.sca.cfamily=true argument to the scanner. This can be done either on the scanner commandline, or via the sonar-project.properties file. This restriction will be removed once this feature is GA.

This will cause the analysis to look for conanfile.py/conan.lock (Conan) or vcpkg.json (vcpkg) to determine your dependencies.

For how to set parameters, see the analysis configuration documentation for more details o

For more information on how to configure SCA analysis in SonarQube Advanced Security, see the Advanced Security documentation.

This is a beta

We are collecting feedback from our customers on their experience with this feature. Share your thoughts in the comments, or reach out for a meeting.

This is available now for SonarQube Cloud, and will be available for SonarQube Server in the 2025.6 release.

2

I just updated a pipeline with a mixed C++/C# solution build with the build wrapper (Azure ppleline, Windows, build wrapper download during build). I added the new property to the SonarCloudPrepare@3 task.

          - task: SonarCloudPrepare@3
            displayName: 'Prepare analysis on SonarCloud'
            inputs:
              SonarCloud: 'SonarCloudEnterprise'
              organization: <MyOrg>
              projectName: <myName>
              projectKey: <myKey>
              projectVersion: '$(Build.BuildNumber)'
              extraProperties: |
                sonar.cfamily.vscoveragexml.reportsPath=$(Agent.TempDirectory)/**/*.coveragexml
                sonar.junit.reportPaths=**/test_details.xml
                sonar.junit.reportPaths=**/test_details.xml
                sonar.cfamily.compile-commands=$(SonarOutDir)/compile_commands.json
                sonar.cfamily.reportingCppStandardOverride=c++23
                sonar.cfamily.enableModules=true
                sonar.sca.cfamily=true

Unfortunately, in SonarCloud indicates in the dependencies page still only NuGet as package manager, vcpkg is not mentioned. (gtest is included by vcpkg.) And gtest is not found in the dependencies.

3

Interesting. Would really need the scanner log to debug further.

4

One thing to note is that for full vcpkg information we do have to run vcpkg list –x-json at analysis time to resolve the dependencies; is this analysis running in an environment where:

  • vcpkg is available
  • it can connect to the vcpkg repository to resolve dependencies

?

5

Hello Bill,

yes, vcpkg is available and used in the build. It is used in manifest mode, if this matters. I’ll send you a private message with logs.

6

I would like to thank @bill.nottingham for the support and investigations.

Sonar quickly fixed a bug and now the vcpkg analysis works also for our build of the mixed C++/C# solution on Azure DevOps using msbuild, Microsoft Visual C++ 2022 compiler (stdcpp23) and SonarCloud build wrapper.

7

Hello, thanks for supporting C/C++ analysis for Conan. It is a very important feature for us and we cannot wait to test it. Could you please recommend, which version of SonarQube Server Version is necessary to carry out the Beta test? Thanks.

8

Whoops, it helps if I mention that. I’ve edited the announcement, but to answer here: This is available now for SonarQube Cloud, and will be available for SonarQube Server in the 2025.6 release.

9

Thank you Bill. I also noticed it a while later, as the topic is SonarQube Cloud relevant. Looking forward to testing it in the 2025.6 release version. Kudos to the team!

10

Does SQ Advanced security supports transitive dependencies for C++ conan?

11

Yes, transitive dependencies from the conan.lock file are supported.

12

We are looking for a tool that will analyze our code and identify our Open Source Software (OSS) based on what we are actually using, not a package manager. We don’t use a package manager because we are a Linux house and it is more efficient (less space and download time) to store our tools in a centralized, controlled NFS location. Although the policy is to use the centralized, controlled location for 3rdparty tools, some developers add tools from other locations. Hence the need for a tool to figure out what we are using. We are currently using a version of Mend to do this and it works reasonably well. We are considering Sonar SCA because we are using Sonar Scanner and our developers would only have to go to 1 tool instead of 2. The package manager requirement is a barrier to adoption for us and doesn’t satisfy our need to determine what we use from code analysis.

13

When you say a ‘centralized, controlled location for 3rd party tools’, are you for a given dependency like Qt or some other open source library:

  • keeping a repo of third-party library source code to build in each app
  • keeping a repo of pre-built third-party libraries to link into each app (if so, where are those built?)
  • linking against whatever version of libraries are in your underlying Linux system
14

In /rapid/rapid_tools///- we keep 1) tools that we have downloaded and custom compiled for our OS/compiler needs and 2) tools that we have downloaded and unpacked for general use 3) tools that were given to us by the developers without provenance (kept in a separate section called /rapid/rapid_tools/legacy). To use your QT example, we have compiled open source QT for our particular OS/compiler needs and have 4 or 5 different compiles of at least 3 different QT versions. For the Intel compiler we just download it and unpack it to /rapid/rapid_tools to make it available to all of our various projects. The building of the tools takes place under /rapid/rapid_tools/downloads//---. The source is generally unpacked once under /rapid/rapid_tools/downloads//- so that multiple build directories can use the same source code. There are also rogue locations for tools, the most common of which is that users have randomly checked in the source code for the tool into IBM’s EWM and then modified the make so that the tool is built every time that part of the product is built. (which is a serious waste of resources and unnecessarily lengthens product build times). Additionally, our products ship with an OS kickstart that we will need to account for in the SBOM but is completely separate from /rapid/rapid_tools although it may use some tools from there. Note that developers ask us to download and build tools but then later decide not to use them or that tool is later replaced by a different tool that suits their needs better. So scanning /rapid/rapid_tools isn’t the answer. We need to know for each of our products, which tools it uses. It would also be helpful if the SCA tool could identify changes in tool usage, that is tool x has been dropped and tool y added. At the moment Mend can’t do that for us; it can only report what we are using now.

Thanks,

Alexa

15

Thanks, I’ve noted this feedback for potential future feature development.

16

Feature request: let SCA target a custom vcpkg install root (–x-install-root)

Context
We’re using the beta C/C++ SCA support (sonar.sca.cfamily=true) against a C++ project that consumes dependencies via vcpkg in manifest mode, built through the CMake toolchain integration on Azure DevOps (Windows, MSVC 2022, scanner CLI + build-wrapper). SonarQube Server 2026.3.

What we observe
SCA discovers our vcpkg.json and, to resolve the manifest’s version ranges to exact versions, runs vcpkg list --x-json from the manifest directory. Our manifest pins ranges (e.g. “nlohmann-json”: “>=3.11.2”), so resolution depends on reading the installed tree. The scanner’s invocation passes no --x-install-root, so vcpkg list falls back to its default of /vcpkg_installed, finds nothing there, and every dependency comes back “not resolved to an exact version.”

Root cause
With the CMake toolchain, manifest-mode dependencies install to ${CMAKE_BINARY_DIR}/vcpkg_installed — for us build/x86/vcpkg_installed/x86-windows-static-md — which is the conventional out-of-source layout. That directory holds the fully resolved versions (our build log shows nlohmann_json 3.11.3, OpenSSL 3.3.0, etc.). But the scanner reads only the manifest-adjacent default, so the resolved data and the location SCA inspects never meet.

There’s currently no way to reconcile this through config: Sonar exposes no SCA parameter for the vcpkg install root, and vcpkg’s --x-install-root has no environment-variable equivalent (microsoft/vcpkg#16098), so the scanner’s flag-less invocation can’t be redirected. Our only workaround is copying the vcpkg_installed directory after the build before the Sonarqube analysis runs, or a directory junction from the manifest dir into the build tree.

Request
Expose the install root to the scanner. The cleanest form would be an analysis property — e.g. sonar.sca.vcpkgInstalledDir — that the scanner forwards to vcpkg list as --x-install-root . Alternatively, discover vcpkg_installed directories beneath the configured build directory, or accept a path glob. This would let CMake-toolchain users keep the conventional out-of-source layout and simply tell SCA where the installed tree lives, consistent with how every other ecosystem in the supported-managers table already exposes resolution controls.

17

[quote=“Alan, post:16, topic:153426, username:canuck123”]
We’re using the beta C/C++ SCA support (sonar.sca.cfamily=true) against a C++ project… [/quote]

Thanks, I’ve noted this feedback.