However, as projects adopt systemd-proprietary APIs, distros are forced to choose between maintaining ongoing forks of those projects, dropping those projects, or adopting systemd. E.g. I suspect Slackware only avoided being forced to adopt it because they'd already decided to not support gnome.
Compared to the Linux kernel, systemd's CVE rate is very low.
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
https://www.cvedetails.com/product/38088/Freedesktop-Systemd...
For a piece of software used by millions of machines, that's a very low CVE count.
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... https://www.cvedetails.com/vulnerability-list/vendor_id-7971...
So far in 2019, the gap has narrowed: "only" 45 CVEs so far for the Linux kernel, and 7 for systemd.
This contributes to the low rate of CVEs in systemd relative to Linux (for which many less-important bugs get CVEs).
My conclusion is that the systemd project is not its own CNA and therefore not in a position to authoritatively decide which systemd bugs get CVE numbers assigned and which do not.
Now compare systemd CVE's with OpenRC or runit CVE's or any other init system and then you have an argument. But comparing it to the kernel with hundreds of people commiting changes is weak.
This comment is not defending nor attacking systemd.
(Though the implication that systemd is an OS Kernel is ... interesting.)
Prove it. As someone else pointed out, there were 5 CVEs for systemd in 2017 and 7 so far this year most of which are low severity. If you think the mess of shell scripts and programs that systemd replaces had less than that you're simply delusional.