Hot take (?): No company should be the CNA for their own products.

[cr0w@infosec.exchange]

RE: https://infosec.exchange/@boblord/116075393614821884

Hot take (?): No company should be the CNA for their own products.

[winterknight1337@infosec.exchange]

@cR0w for some reason I thought CNA == Camapgin for North Africa not CVE Numbering Authorities.

[cr0w@infosec.exchange]

@winterknight1337 Now it's getting interesting.

[ckure@infosec.exchange]

@cR0w @boblord one thing I like about self-CNA is that vendors know their own products best and are uniquely positioned to deconflict or perform better merge-split decisions.

One thing I dislike is the system’s capacity to deny issuance if the company captures reporting and doesn’t follow through with providing a CVE.

[meatzie@infosec.exchange]

@ckure @cR0w @boblord that's at least getting better with the research CNAs calling things out and getting CVEs.

[cr0w@infosec.exchange]

@ckure @boblord Yep. And which one is in the vendors' best interests, especially with such a corpo friendly US regime? I am completely back in the full disclosure train. It's the most effective and efficient way to protect critical infrastructure.

[cr0w@infosec.exchange]

@meatzie @ckure @boblord If they don't get rejected by the CNA. I'll try to remember to search through the rejected ones. I bet there are 50+ from Fortinet alone in 2025.

[brahms@chaos.social]

@cR0w @ckure @boblord thats why I like the term "responsible" disclosure. because you can argue case-by-case, whats the most responsible way. Of course it is also important to ask responsible for whom.

in most cases the most responsible is, imho, to disclose publicly asap

[meatzie@infosec.exchange]

@cR0w @ckure @boblord rejected can mean a lot of things though. Some CNAs used to do that for records they didn't use, although they shouldn't be doing that as much anymore. Some stuff gets reserved early and turns out not to be an issue.

[cr0w@infosec.exchange]

@brahms @ckure @boblord It's a fair point but I dislike it specifically because if the arguing about it. Full disclosure means people are either patching / mitigating or they're whining.

[boblord@infosec.exchange]

@cR0w How do other sectors handle safety-related product defect notifications? I'm thinking about sectors covering planes, trains, automobiles, food, medicine, etc., all of which have achieved dramatic improvements in safety for both their customers, as well as the general public. 🙏

[cr0w@infosec.exchange]

@boblord First and foremost, they hold manufacturers responsible for poor engineering. In tech it's just "LOL patch if you can." Without that, respectfully, the comparison is not valid.

[boblord@infosec.exchange]

@cR0w If we want to improve the safety of software like we have for other sectors, we need to figure out how to build software informed by those truly incredible successes. That road may be long, but we can do hard things! 💪

[cr0w@infosec.exchange]

@boblord I believe you want to improve things, I really do. But I think in order to get there, computer science needs to be engineering-focused rather than business-focused. And it's not. Especially in academia.

[hotsoup@infosec.exchange]

@boblord @cR0w what was that when Boeing famously took over their safety inspections by providing trained inspectors to whatever acronym it was. I heard that went famously well for them. The kind of well that documentaries were made about it.

Edit: there to their

[boblord@infosec.exchange]

@hotsoup @cR0w It's true that no system is perfect, but we don't let car makers opt out of filing defect reports, for example. We should ask what types of incentives would create more transparency from commercial software makers. As we see from all those other sectors progress is possible. Which tactics would work best in the software?

[cr0w@infosec.exchange]

@boblord @hotsoup Fines. Look at the auto industry. Transmissions fail to park, gas tanks explode, Lancias rust like a trans girl's GitHub history, you get the idea. But they were fined. Publicly traded corporations only care about the feelings of their investors. Kick them in those plums and they'll start trying to improve instead of finding cheap ways to hide their cheap failures.

[hotsoup@infosec.exchange]

@cR0w @boblord those industries have actual, real, Big E, Engineers. With Standards. And stamps. And liability. And consequences.
They are held personally responsible for their mistakes, and are thus incentivized not to make mistakes. (And like you implied, maybe not intentionally, they are also incentivized to hide their mistakes. Which is why inspections need to be done by unbiased third parties).
That is what software needs. Standards, Regulation, enforcement, consequences. And third party inspections. Real Engineering.

Edit: part to party

[cr0w@infosec.exchange]

@hotsoup @boblord Exactly. So much in tech says it's engineering but it's not. Engineering requires an understanding of how things work. But tech is about how to make money the fastest.

[boblord@infosec.exchange]

@cR0w @hotsoup Great points! A really great book that describes these incentive structures is Geekonomics by David Rice from 2008. I highly recommend it. David identifies numerous gaps between other sectors and the software sector. It's worth a read!