If you want formal engineering outcomes, you need formal engineering standards. But in the same way that redoing a home bathroom doesn’t require the same multimillion dollar process as building a bridge, not all software projects can fall under the same umbrella. Any scheme like this has to take into account where certification is actually needed and what the goals and costs are.

And guess what: this already exists. DO-178C for aviation, ISO 26262 for automotive, IEC 62304 for medical, etc. But these standards are specialized to the industry because, no surprise, there is no appropriate one-size-fits-all software development approach. You can’t just say “software must be bug-free” and leave it at that. That’s been shown to be impossible. Even formally verified software can have spec bugs.

There’s already formal standards that CAs must meet, and they get audited too. Maybe those standards aren’t rigorous enough. But even with those standards, what authority is going to punish a CA who breaks them, other than browser/OS vendors? If it damages the host nation, you might see something. But if the host nation is complicit, and used the rogue CA for intel purposes—or if the company has political connections—then I don’t think you’re getting the punishment you want.

It makes sense to have these heavy standards when you’re talking about software whose failure could immediately cost actual lives. I’m hesitant to expand it elsewhere as it could threaten the viability of open source and software freedom in general. Nobody should ever need a license to run a compiler or deploy an application to their own server.

▲

AlotOfReading an hour ago | parent [-]

26262 is a process standard (a voluntary one at that), not a software standard. It barely even talks about software outside a couple specialized sections. You can also think of the CA program as a process standard that comes with active enforcement.

▲

iamnothere 34 minutes ago | parent [-]

The process of developing software has an impact on the outcome, especially if the software is tied in with physical systems. If you’re looking for software that meets specific criteria, built to an engineering standard, you need a formal process around it.

Also, a purely software-focused standard doesn’t make sense for CAs, as they also operate and maintain infrastructure. The failure with this CA was a process failure.

I probably emphasized software too much in my reply, but that’s usually where I see people call for standards to be forced on the “tech” industry.

	▲	AlotOfReading 9 minutes ago \| parent [-]
		Sure, not going to disagree that processes affect outcomes. As someone who lives with standards-following-practices every day though, I always have to caution people that following the process is often a vastly different thing than improving the outcome. For example, (most) certified compilers are great from a process perspective, and awful if your goal is less buggy software. My opinion is that all the process in the world won't help if the people doing it don't care about the outcomes.