Hacker News Reader

Comment by jcarrano | Hacker News Reader

As I mentioned a couple days ago [1], this problem will get much worse in the EU with the upcoming CRA. Either the only software vendors left will be big ones with the capacity and leverage to counter these CVEs, or companies will turn to obscure, bug-ridden software which have no CVEs because no one bothers to research them.

[1] https://news.ycombinator.com/item?id=37582808

View on HN

expect closed-source analog of GNU, and a license that forbids showing source code, plus tools for obfuscating binaries, masked as "optimizers". there will be ademand for anything that reduces chance of CVE discovery and that reduces open source SBOM entries.

open source most likely becomes a liability under CRA

Yes, and the next step is that the vendor will sue researchers for posting CVEs which they consider "bogus", accusing them of hurting their business.

It's not so much as open source becomes a liability, but rather "well known", whether open or not, becomes a liability. If you pull a random json library from github that does not even appear on any vulnerability database then you will probably be fine.

Shit, I think the best way to fight this is to file bogus CVEs against propertiary software vendors. You'll see the industry demand CVEs be fixed within a month.

You can after-all, file CVEs anonymously. It takes no effort to stand up a fake "research firm", or two, or three doing so.

Bonus points if the CVEs are against all the shitty cybersec scan tools.

You can file CVEs anonymously, but CNA don't have to assign a CVE number if they consider submission bogus. Depending on the CNA they may also verify the submission themselves or contact the vendor before assignment (usually vendor has to confirm the vulnerability before the publication, often CVE publication date is decided together with the vendor if the vulnerability is not already public).

Of course there are shitty CNAs that don't care. But honestly CVEs are a useful tool for communication, people (both security people and non-security people) should stop obsessing over them.

So what kind of good outcome you propose? If I correctly understand what you are talking about: - demand open source projects to fix all CVEs within short fixed time AND all projects integrate all upstream and dependency changes almost immedeately (or else, maintain array of older versions that are still used by someone) - demand proprietary software vendors to avoid using any open source project that does not provide the above, and in a short, fixed time switch from using any such dependency that has ceased providing these guarantees (e.g. maintainer quit) to another one that does.

which still leaves you with the risk of breaking stuff on upgrade, because now your product is basically baby debian sid, because you must pull newest versions all the time, and cannot stay on a stable version (that will not get patches)

agree on "well known" part. also, it will depend on particulars, how the developement must be disclosed.

e.g. if vendor drops copy of public domain libtom into its git, changes it up a bit — is that still a separate dependency? what if vendor goes "hey, siri, copilot gpt4, write me tls handshake implementation" and uses whatever is the resulting garbage, is that ok?

Reply on news.ycombinator.com