I expect quite a few folks here are going to question the figure, "a million dollars per line changed."
1. The airlines operate under a huge amount of regulatory oversight, and structure the development of avionics or engine control software accordingly. The terms ARP4754 and DO-178C are to aviation as ISO9002 is to business models. They provide guidelines on creating a rigorous development process, and regulators are keen to track how well companies develop logic and physical designs in line with best practices described by those guidelines.
2. If you summarize DO-178C in one sentence, it might be "document the rationale for every change, and the means you employed to ensure it is the right change." Most companies follow a V-shaped change model where you trace from high level requirements to lower level requirements to implementation details, and then verify the code does what is expected and then validate that the requirements are being met (and the requirements are even proper in the first place). Once you have that framework in place, you have to document every step of the chain of review.
3. For every change to a high level requirement, a low level requirement, an implementation, and sometimes even a change in a verification method, there typically has to be an independent review: you cannot trust the implementors to check that the change was appropriate and done correctly as it's easy to be blinded by your own thought process during development.
So in a case like this, the customer needs to inject several new top-level requirement (which shockingly may not have been there in the first place), "the system shall be hardened against unauthorized changes in configuration/operation/state" and that has to flow down to subsystems "the component XYZ shall be hardened..." and that has to flow down a few more tiers before you even identify the protocols or chips or attack vectors to be changed. Then you have to verify the code change works in each component. Then a system-level review. Then a regulatory review to have the updated design certified as safe for test flight and finally safe for revenue service.
Does this sound like a desktop software change control process? Sure, maybe you're really disciplined, but it's a matter of degree. It really can take fifty people or more, from regulators to systems engineers to coders to integration testers to work the process. And that all adds up in terms of time, opportunity costs, tools and tooling, lab test, systems test, hours and hours of live aircraft flight test, and so on.