Keeping it closed seems like a full admission that "there are probably a bunch of bugs in here and we don't want people to see them"
Most executives care about profits, security is simply not important. Even if an engineer explains that he needs more time to properly secure something, he will be asked to cut corners. Then, when shit hits the fan the executive will make a "pikachu face" and engineer will get fired for not properly implementing security.
Open sourcing the codebase doesn’t mean that all it’s vulnerabilities will be discovered, and it’s certainly not the only way for a company to manage them. Out of all the options that are available, it’s really one of the worst ones from the company’s perspective.
Now, imagine they did open-source their code: I imagine those codebases are humongous and it would take months if not years for security issues to be found by the community. How do you make sure that a bad actor doesn't find a flaw before the community does and uses it?
So open-sourcing sounds totally unrealistic to me.
Ultimately your argument applies to all life or death code, even code we put inside our bodies, which as you mentioned, is also highly specific and specalized.
Because the bar is higher there should be less review is a contradiction.
APT (often not a State) conversations are pointless where plausible deniability is ignored as a desirable property.
No one really would benefit from open sourcing it without being able to (security) test it in realistic scenarios. Obviously security researchers would profit in discovering bugs which may have no relevance in reality, to increase their fame.
There are always bugs in software, some people depend on keeping them secret.
One problem with opening the source code is then Boeing would have to dedicate a team of engineers to deal with every armchair crank claiming the software is going to crash the airplane.
(ex-Boeing, OS+support code for embedded LRUs)
Because yes, it seems the problem is with incentives. If attacks on such things happen seldom enough, that will never trickle down into incentives for managers at all levels to prioritize security high enough.
Then, somebody could argue that if it happens seldom enough, that is reason to not prioritize it that highly. But I don't think the actual risk translates into actual incentives for managers in a very linear, nor fact-based manner, especially when the number of occurances is very low, while still with catastrophic consequences.
We definitely attempted to write the best code as we could given the circumstances, but we had issues doing so:
* airline margins are razor thin, so salaries are comparatively low, which means
* the best employees frequently left for other opportunities, causing
* management to institute an over-reliance on process and tech debt from poor engineers to build up like crazy, and then
* management's priority was always "keep the lights on" rather than repay any tech debt or start new ventures.
Eventually we were working on an unmaintainable codebase, spending way too long to ship each feature, and the situation was not improving.
It was not a wonderful environment to work in (hence my departure).
Excluding executive pay, of course. Oh and excluding stock buybacks (which increases shareholder value, consequently greatly increasing the value of executive compensation).
https://www1.salary.com/AMERICAN-AIRLINES-GROUP-INC-Executiv...
https://www.sec.gov/Archives/edgar/data/4515/000000620118000...
Razor thin margins which result in $200 million (give or take) in quarterly profits are not exactly sad stories.
In summary, the non-executive employees are paid as little as possible to keep the company operating. And by operating, I mean that the bottom line/shareholder value is all that matters. Safety is really just a bottom line consideration. If an accident or two happens, and an eventual death payout is made, as long as the bottom line is not greatly affected, there will be no change in corporate behavior with respect to paying people properly and not cutting corners.
Secondly stock buybacks are similarly tiny compared to how much money a company actually has to give to its employees. Run the calculation some time. You need to be looking at revenues, not profits.
Airframe software is a totally different ballgame than airline operations management software.
When I worked on the 757 on flight critical systems (stab trim) the engineers I worked with took great pride in making the designs as good as possible. Nobody wanted to sign off on a design that they'd get a phone call on years later as being the cause of a pile of dead bodies.
I personally am proud that none of the stuff I worked on or any of the guys I knew worked on has been a factor in any incidents I've ever heard of.
Not a matter of pride, but you don't want to help your competitors offer the same capabilities as you for $0 R&D costs
Would depend on licensing but in any event, once you start showing how the sausage is made others can find inspiration to develop their own code, at which point you can start getting into a costly legal battle over whose idea it originally was, whether certain algorithms are protected, etc...
My point is simply that there's no upside for Boeing to open source their code.
You wrote 'Airbus' as though Boeings R&D in their software would somehow magically translate into an advantage for Airbus. But Airbus should also open source their code, and for exactly the same reason. In fact Airplane certification institutions such as the FAA and counterparts could easily mandate the open sourcing of every last bit of software to create a level playing field.
The reason to have code open source would be to get public confidence perhaps, but I doubt that makes it a net positive in their eyes.
If you write code that takes an input and increments a number, and you're worried that someone might exploit your code, someone else should have wrote the software.
Attach a printer that shows the voter a paper receipt before the receipt goes in a box, and it should be able to prevent against most any electronic attack.
Edit: better link https://opensource.apple.com/