SoylentNews is people
SoylentNews
The National Vulnerability Database (NVD) is a US government-funded resource that does exactly what the name implies-acts as a database of vulnerabilities in software. It operates as a superset of the Common Vulnerabilities and Exposures (CVE) system, operated by the non-profit Mitre Corporation, with additional government funding. For years, it has been good enough—while any organization or process has room to be made more efficient, curating a database of software vulnerabilities reported through crowdsourcing is a challenging undertaking.
Risk Based Security, the private operator of competing database VulnDB, aired their grievances with the public CVE/NVD system in their 2018 Vulnerability Trends report, released Wednesday, with charged conclusions including "there is fertile grounds for attorneys and regulators to argue negligence if CVE/NVD is the only source of vulnerability intelligence being used by your organization," and "organizations are getting late and at times unreliable vulnerability information from these two sources, along with significant gaps in coverage." This criticism is neither imaginative, nor unexpected from a privately-owned competitor attempting to justify their product.
In fairness to Risk Based Security, there is a known time delay in CVSS scoring, though they overstate the severity of the problem, as an (empirical) research report finds that "there is no reason to suspect that information for severe vulnerabilities would tend to arrive later (or earlier) than information for mundane vulnerabilities."
(Score: 2) by jb on Friday March 01 2019, @05:23AM (1 child)
Oh, come on. Your straw man doesn't even come close to holding up.
strncpy(3) has been around for at least as long as C has been standardised (C89, 30 years ago). Granted it doesn't appear in my 1978 copy of K&R, but no new programmer should be learning C from anything that old today (and if that's really the latest thing you've read about C, you should at the very least get up to speed with C89 before writing anything in C for production use).
Better still, srtlcpy(3) has been around since OpenBSD 2.4 (Dec 1998, 20 years ago) and if your libc of choice doesn't have it, you can implement it yourself trivially in less than 10 minutes, or just copy OpenBSD's (it's only about 25 lines long, permissively licensed and easy to find here [openbsd.org]) assuming you're willing to give credit where credit's due.
If the symptom you're seeing is inappropriate use of strcpy(3), the problem isn't the C language (nor even the C library), but rather an inexperienced (or 30+ year out of touch) programmer...
Those exist for any given language.
(Score: 2) by DannyB on Friday March 01 2019, @03:38PM
Yes, my opinion of C was formed quite a long time ago. But other criticisms I would have of it for high level applications are still valid. I'm not saying nobody should use C. I'm not saying C should go away. I am saying that C is not the best choice for applications at or above the command line level.
My point is that there have been and are now ever more languages that enforce much greater safety right in the language.
The lower I set my standards the more accomplishments I have.