Most maddening for open source projects is the number of false positives exacerbated by multiple people trying to 'help' by running effectively the same security audit as a bunch of other people have done and trying to open issues that are duplicate...

Huge pain in the ass dealing with contributions from people who don't understand enough to analyze their LLMs "findings" and just pass them through "in case they are helpful".

Might be nice once the fad of "everyone contribute by running duplicate reviews" subsides though.

Note that this isn't even new to AI, the kernel has always been a flood of CVEs. The AI spotlight puts a bigger spotlight on it, but it has been a mess.

The real problem is that the average security team is mismanaged and forced to use terrible tools that report on yet fail to reconcile the status of the CVEs on behalf of the user and instead drives the team to have to figure out how to take care of it themselves.

Some twisted security mindset of going direct with CVEs as 'the most thorough vendor neutral approach' without instead leveraging distribution security advisories. So you end up with a security tool claiming you have thousands of security issues on an up-to-the-minute patched instance of the latest enterprise linux distribution because they backport and tools don't understand the version numbers.

In the industry, so many security teams mandating CVE management software that is absolutely stupid and pushes off all the hard bits to the user.

It sees 6.12.0-211.34.1.el10_2... Well... none of that makes sense so it just assumes that it's just plain 6.12.0 and demands the user reconcile the reality. Now the security vendor *could* maybe integrate with the major linux distributions advisories... But no, more CVEs is better, when you demo that your product finds hundreds of CVEs, that just proves it is being thorough as far as upper management is concerned.

They offer up sound guidance here, skip direct CVE management and lean on your distributor. If you are doing CVEs direct, at *least* use the patched files to cross-reference against your build to see if it even in theory could matter. However the problem is the business of the security industry doesn't prioritize those, and so we have stupid tools inflicted on people, and pushing back against those tools carries a stink of "must not care about security then".

You didn't? I grew up a computer geek. I actually read this kind of stuff for fun... .

But my point only applies to the functions you are using -you don't need to know all of glibc by heart, but if you are including #menumaker_4.0c you should step thru it before trusting it to not be malicious. When you include it in your app -YOU- are accepting responsibility for what it does on your clients machine.

Depends on the number of realistically 'false positives'.

I've known a few people who find the kernel CVEs particularly unreasonable as they tend to aggressively assume security implications. If they grant a CVE to a 'mere bug', no one is going to get too grumpy over that specific item. If someone believes they have a vulnerability and do not see a CVE, then people get riled up. So some feel the kernel is just granting CVEs to avoid pushing back.

The other headache is the monolithic nature of the project. "Linux" covers just everything. A potential security issue in a device never seen outside of PA-RISC systems 20 years ago? It's a "Linux" issue, so every x86 system will be flagged as 'affected' by security software that cannot deal with nuance

Of course, we are here mainly because the kernel team largely recognizes the practice of trying to apply only security updates while avoiding 'only bug' fixes as pretty insane. So err on the side of caution make CVEs extra unmanageable because realistically it was a pretty crappy strategy for such a complex project anyway.

Broadly speaking, CVEs are usually pretty bogus, but a small percentage are very real and critical issues. You can't use the 'score' to really measure this either, it's not very good in the first place, and for example I saw the exact same issue in a C library and a python binding for that C library, and for whatever reason they graded the C library as 'minor' and python binding for that library 'critical', despite the python binding being nothing but a ctypes wrapper around the c library...

The answer to this problem is the same as for every other piece of software:

Stop embedding other peoples code into your code if you have not fully vetted and understood it.*

When you embed or link other people's code into your code, it becomes your responsibility. If you are not competent to understand/vet/maintain the full code base, then you are not competent to be in charge (lead developer/maintainer/architect/whatever-you-want-to-call-it).

This is not to say that less proficient coders cannot be part of the team, but someone has to be on top of ALL of the code in the product, no matter who authored it. Larger projects may need multiple people each responsible for portions of the code.

*I know this is inefficient. I know it is counter to modern coding practices. It is the only way to be confident your work is secure: Trust but verify. Verify everything, every time.

Not sure you quite get how dopamine works.

You expect very slop happy software developers to create effective safeguards?

Which is the bigger problem IMHO.

Thanks for the heads up.

Have you tried setting up something like a whitelist (see below)? I feel like that would make my life a lot better - just having a process that filters out the obvious SEO sites so that I don't have to do it.

https://github.com/searxng/sea...

Two words:

Parallel construction.

https://en.wikipedia.org/wiki/...

"An example from one official about how parallel construction tips work is being told by Special Operations Division that: "Be at a certain truck stop at a certain time and look for a certain vehicle." DEA would alert state troopers and they may wait for that certain vehicle and use drug searching dogs to identify illegal drug-related activity, giving the appearance the search was conducted randomly.[4] "

This example also would be a form of evidence laundering. By the time the case is presented to courts, the fact that this all resulted from a warrantless search would be nowhere to be found.

So someone is going to jail for it?

Because if ordinary people do something that is very very illegal, they do.

Had to do a little searching, but found this. https://www.thinkchina.sg/tech...

Sounds like you are correct. One of the big factors seems to be China's ability to make inexpensive Lidar, 200 bucks. Contrast Google at 7500. And of course tesla with cameras. There is a graph showing just how behind tesla is with their "Number of disengagements/crashes" graph. Tesla is at 100 hours. The worst China one is 1000 hrs and waymo and the 2 best Chinese ones are at 10000 hrs. The article claims 1000 is around human performance. Maybe about right. Say commute is 2 hrs/day x 50 x 5 is 500/yr so not crazy to think the average person has an accident every other year I guess although it sounds at least 3X too high to me. I'd expect average is more like 6 or even 10 years between crashes for the average person. 10 years would put people at 5000 hrs between accidents. I'll bet the insurance co's know a very accurate number...

401K may have money market as an option. My IRA and SEP both offer a "cash" option which is currently paying around 3.3% I'm probably 90% cash at the moment. I think 401K you are at the mercy of the corp administrator.

VoIP doesn't work when the power is out. At least mine doesn't. The router in house is out, the fiber to Ethernet box on the power pole is out, and the fiber switch on the corner is powered by the same power lines so it's out too.

It's batteries only.