PengZheng commented on PR #845: URL: https://github.com/apache/celix/pull/845#issuecomment-5903072742
> I am struggling a bit with this. So am I. > I can understand that we say/document something like: "The latest Ubuntu packages from the LTS used in Apache Celix are our reference for monitoring upstream vulnerabilities. Usage of Conan is also possible, but it is up to the user to resolve/select the final dependency versions." And maybe document how you can run a conan audit scan. In this case, I would expect that, if we do something with SBOM generation and vulnerability scanning, we do it based on the APT-based CI builds. We can do it for both Ubuntu and Conan builds, which provides our users clearer security status of these builds. Except: * For Conan build, it is just a single command to generate SBOM and get audit report. * For Ubuntu build, some work is needed to generate SBOM, and more work for audit report. A clickable link to these audit reports in README.md (as the codecov) will be very helpful. > Alternatively, we could make Conan and Conan package version resolution our reference and use a lockfile. I think it is also Ok to update the lockfile more frequently, and at the same time a lockfile could help during heavy development to prevent too many dependency changes between builds. > I am a bit worried about the maintenance burden once we have more insight into upstream vulnerabilities. So I am not sure what the best approach is. From a "minimize the burden" perspective, I think it would be better to follow the APT package approach and rely on Canonical LTS security maintenance, instead of depending on multiple Conan Center recipes and therefore multiple maintainers. Maybe something with syft is possible and then scanning the CI build dir. When dealing with CRA requirements, Conan is a very powerful tool. In my day job, we have a private Conan deployment within the enterprise. It is not always possible to update to the latest upstream open source component to fix security issues. For example, projects as Civetweb are not actively maintained, or we must stick to a very old version like libcurl 7.x. We can rely on Ubuntu LTS or other Linux distributions' security patches to generate patched revision of such conan package. Then an ultimate downstream `--require-override` will fix security issues without touch any other components. > For me, the main question is therefore which dependency ecosystem we want to treat as the reference security baseline for Apache Celix. We can spend most of efforts to get SBOM/audit work on Ubuntu LTS, and then provide easy access to audit reports for both Ubuntu and Conan build. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
