Think the root is that folks see GenAI as their ticket to unskilled participation in a very highly paid industry.
However things go, that will not be the outcome, and I at least look forward to people being disinterested when it doesn't work that way (either they don't get to participate, or the industry won't be a high pay one anymore).
Problem is that ultimately, the CVEs tend to lose meaning. The relative risk of a CVE becomes impossibly diluted because most of them aren't of practical security consequence. It's a lot of work to keep up the charade that CVEs are something that need to be handled as "more than bugs" and that you can somehow get a better consistent experience by avoiding bugfixes but still get CVEs to maintain security..
Very critical things have CVEs that are really important, but the CVE facet of it does not really set off alarm bells since they've been overused. We instead create "brands" for the "actually important" vulnerabilities.
Maybe a good tool for entities like linux distributions to start their advisories, but it's a complete disaster for end-users to think they should be managing CVEs directly, which is precisely what the security community frequently demands. Also precisely why this is vaguely controversial.
Evidently they do at least have a rationale for that.
Instead of LIDAR in every car, they push LIDAR maps that they maintain by regularly driving the supported roads.
Of course, a LIDAR unit in the car would bring it back to a one-time purchase making sense, but initially that was too expensive, and now... well... they like the recurring revenue....
It was once that GPS maps was an annual purchase, but now we have phone integration, that's not a thing any more. If they'd made their car infotainment systems better, perhaps we wouldn't need phone integration quite so much, but they didn't and so here we are.
GM has a 'fix' for that:
https://news.dealershipguy.com...
Why make infotainment systems better, when you can just make phone integration worse?
I can't speak to it as I don't have a GM car, but do note they removed Android Auto and Apple Carplay from many of their vehicles, precisely to drive people to buy OnStar to have the big driving friendly displays be able to do the things many folks just started using their phone for when CarPlay/Android auto became a thing.
This is why they removed Android Auto and Apple Carplay from their vehicles. They are betting people are so loyal to GM that they'll pay for OnStar instead of just using their phone apps on the big screens like everyone else does.
Emboldened by the fact that Tesla similarly dismisses that feature and people bought Tesla's just fine.
Seems to be working based on the numbers, and the fact that someone at work who is a supreme fan of GM who has always just bought GM is disappointed that his next car won't work with his phone the way he likes, but doesn't see giving any other vendor a shot as a viable option. They do have some folks with crazy blind brand loyalty.
My latest project is a 16,000 line script done in Python. It was pretty big for one person.
16kloc is a small project.
I should soften what I said before: You can get away with seat-of-the-pants work if one or more of: (a) your projects are small, (b) your projects are non-critical or (c) you invest in massive testing and validation.
In my old job, if I made one kind of mistake it could prevent three billion Android devices from being able to boot. If I made a different kind, it could result in the same number of devices being insecure against data extraction and other attacks (of course, OEMs often made those mistakes for me). In my new job, if I make mistakes vehicles can crash and people can die.
I want all the help the tooling can give me, and I spend a fair amount of my time building additional tools to prevent mistakes. None of it eliminates the need for testing, of course, especially when lives are on the line, but bugs that get caught by the compiler cost almost nothing. Bugs that get caught by QA, or, far worse, in the field, are very expensive.
Note that there are big systems built in Python. Instagram has millions of lines of Python code. They also mandate explicit type declarations everywhere and they built their own static typechecker, Pyre. Lots of other people have built typechecking libraries and tools for Python, trying to fix that problem. Maybe the next time I write Python I should try some of those tools.
Though I probably won't ever write any Python again. I really only use it for quick and dirty scripts, and these days I tell AI to write those for me, and I don't even bother to read the code. If it works, fine. If it doesn't, I tell the LLM to figure out why, and fix it.
Is there any other kind?
Sure there are. Some bug reports, you look at them and dig in and say "Damn, that's obscure. It depends on subtly-wrong but arguably-correct-in-isolation mistakes in four different places. How the hell did they even find that?".
Granted that it's more common to glance at it and just be ashamed, or to look at it and say "Really? You think an attacker can do A, B, C, D, and E, all at the same time? Oh, and to do B or D they'd already have to have the system mostly compromised. Okay, I'll fix it, but no way in hell is that actually exploitable."
Yeah I don't need help from the tools.
Sorry, but you're wrong.
I think you're right.
I'm surprised they're projecting profitability as soon as 2030, actually. That's only 3.5 years away.
I would guess they are ignoring some expenses there as well.
Maybe... if the projections are in formal filings I don't think they can do that without risking SEC penalties. They can be optimistic about revenues or falling costs or things, because who can tell? But straight up ignoring things, probably not.
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".
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...
And it's not exactly an ad for US models when HuggingFace had to rely on a Chinese model to analyze their logs because the US model they tried refused to answer.
It is if the customer is the US military.
* US model is capable enough to hack its way out.
* China's model was able to detect it.
*
Nope. You misunderstood. It's not that the US model wasn't able to detect it, it's that the US model's guardrails prevented it from explaining. This doesn't demonstrate a capability gap against Chinese models, it demonstrates a two-sided failure of the safety protections of the US models. On the one side, the safety guardrails on the OpenAI model failed to prevent the attack. On the other side the guardrails on whatever US model(s) they tried blocked the model(s) from explaining the attack (presumably to protect against the explained-to people from learning how to perform it).
Nope. I didn't misunderstand. You may have misread what I said, or attributed the previous comment to me.
You said that this creates an arms race, which implies that it's a question of capability.
Put not your trust in money, but put your money in trust.
