Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions about known vulnerabilities #1022

Open
NinjaCross opened this issue Mar 24, 2025 · 1 comment
Open

Questions about known vulnerabilities #1022

NinjaCross opened this issue Mar 24, 2025 · 1 comment

Comments

@NinjaCross
Copy link

NinjaCross commented Mar 24, 2025

I love Boost very much, but recently I had problems embedding it into some projects, because many customers started raising concerns related to cybersecurity and dependencies management.

In recent times, many industrial sectors have been (or will be in the very near future) impacted by regulations related to Quality Assurance and Cybersecurity (i.e. the EU Cyber Resilience Act).
This forces companies that produce and release software, to keep track of the used dependencies and their vulnerabilities.
For compiled packages released through centralized repositories (i.e. NuGet, NPM, Maven, etc), keeping track of known vulnerabilities is easy, there are plenty archives that enumerates their CVE/CWE codes by package version.
Even GitHub itself contains the GitHub Advisory Database

For a project like Boost, it's hard to keep track of every included library, and even harder to keep track of their individual potential/known vulnerabilities.
I understand that there is a Formal Review Process and some testing involved in the production of a Boost version, but as far as I can see, there is (almost) nothing related to cybersecurity and potential vulnerabilities.

Am I wrong ? Is there some sort of well-known vulnerabilities list for every version of Boost ?

Also, since Boost is released as source, and not as packaged & versioned binaries, it's non-trivial to use it in projects where the company is enforced to keep track of every dependency identity (sources could be changed, thus diverging from the "official" release)

Without such information, a company that use Boost could be forced to perform from scratch its own vulnerability assessment directly on the sources, and as you can imagine, this would be a huge effort.

Any suggestion would be greately appreciated, thanks !

@mclow
Copy link
Contributor

mclow commented Mar 24, 2025

You will get a lot more visibility if you post this to the boost-developers mailing list. See https://lists.boost.org/mailman/listinfo.cgi/boost for more info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants