NCSC CTO: Broken market must be fixed to usher in new tech National Cyber Security Centre (NCSC) CTO Ollie Whitehouse kicked off day two of Britain's cyber watchdog's annual shindig, CYBERUK, with a tirade about the tech market, pulling it apart to demonstrate why he believes it's at fault for many of the security problems the industry is facing today. In a speech-cum-call to …
"We have levels of technical debt, extremely high levels in organizations, and in technology more generally. And the vulnerability when it is found, that technical debt is often really, really quite shallow."
To me at least, the meaning of this statement is not at all clear, particularly the second clause. My experience shows that the primary source of the 'vulnerability boom' is lack of attention to low level detail at all stages of the dev cycle, including blind reliance on 3rd party libraries, design on the fly, minimal testing and pressure to release.
I'm wholeheartedly in favour of formalising vendor liability, but it will only be the first incentive for change. It will take a very long time to show real effect as we have some forty years of bad practice to overcome. Maybe that's what he means by 'technical debt', but its root cause is really cultural rather than technical.
The things you mention are certainly problems with software development. But there is also a great deal of shallow technical debt in existing codebases — the sort of things that are called out in texts like 24 Deadly Sins of Software Security. These are things like missing bounds checks and error checks, input validation, and the use of string concatenation and interpolation to build commands for external processors (leading to SQL and command injection, etc).
The existence of the former doesn't mean the latter is irrelevant. And indeed many of the less press-worthy but still quite damaging vulnerabilities we see are simply the result of this sort of technical debt.
So, yes, practices need to be reformed. We need to break the addiction to third-party code and related ills such as the reliance on fetching components from toxic public repositories without performing due diligence. We need to institute SDLC practices across the development cycle. We need to make security a priority over adhering to tight release cycles. I've worked for organizations which have made some of these changes and are working on others, and it does improve code quality and safety.
But we also need to address the huge amount of technical debt in legacy codebases. And much of that is quite straightforward; it's just not sexy. Adding guards, refactoring, making code more readable and maintainable may not strike most programmers as fun, and it doesn't play well for product marketing ("we made our godawful crap less terrible!"), so developers and managers avoid it. But it needs to be done.
What on Earth is it that continually and persistently prevents governments and their self-serving sinecure organisations from realising and accepting the notion and motion that they and their damning proposals are the present problem currently proactively being addressed by the future and ITs leading actors they now find themselves struggling with, and failing to correctly identify whilst claiming them to be a hostile enemy, and even a fantastical existential threat to humanity as a whole, rather than just something novel and unique, tasked to accurately target them and their leading personnel providing assistance and supplying resistance?
Is it stupidity ..... as Einstein suggested was rampant in humanity ? .... “Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.”
And although one wouldn't be the first to say, in reply to something which one may both either like and/or dislike ......"Better to remain silent and be thought a fool than to speak out and remove all doubt" ...... one wouldn't be the last to think it about a silence on such an instance freely shared for personal comment/subjective opinion and remote peer review of the evidence failing to prove the notion and motion false and unworthy.
Seat belts in an automobile are measurable. You have them, or you don't.
"Security" in a product is not quite so measurable. Sure you can do some penetration testing, design reviews, code reviews, age-of-code inspection (hello linux 2.8), and general bill-of-materials reviews.
But it's not true/false "secure".
Assigning liability is the important change that is needed. Bridges and highways have an engineer-of-record who is personally responsible for the safety of the design (and therefore demands and gets multiple reviews of designs, reviews of construction, and acceptance testing. Often with the end-customer pushing for the same reviews.) The standard for liability is often set at "skill of an engineer of average abilities" which actually is quite high. No jokes please.
Get rid of the (no-) liability lawyers and replace them with lawyers who can write clauses with shared risk between the vendor and the buyer. (After all, the buyer needs to purchase with eyes open.) And with risk comes responsibility and therefore liability.
Then you might see some change.
About to retire - got sick and tired of the "ain't broke, don't fix it" mentality of manglement.
1500+ lines in one function of 30+ year old C code, with single and double letter variable names, reading unsanitized input from user supplied files - just one example. Nobody even fully understands what those lines of code actually do and nobody has ever heard of unit tests. Pure luck that nothing serious has gone wrong yet.
Just because "it ain't broke" doesn't mean it shouldn't be updated. And nothing will change until somebody at the top gets serious trouble because it is quicker/easier/cheaper to just ignore it.
Almost as bad is the "just hack it in and we will do it properly later" - except later never arrives.
wholly inadequate in practice.
I keep banging on this. Sure, businesses respond to the market, and consumers have no way to value, let alone evaluate security. So the only way to bring balance will be to pass and enforce some highly unpopular laws, and, at least in the US, upend a whole lot of case law regarding what you can put in a contract. Heck, it will take a decade just for it to get to the Supremes, that is after you somehow get a law passed in this environment.
I'm not saying that it's not worth a try. Because nothing short of strong government intervention is going to matter. It's only after some major companies go broke and/or their directors go to jail that even the search for the solution is going seriously start, except that the people in charge are incapable of believing the truth.
If you want to secure the 'net, the first thing you have to do is ban 95% of the current "programmers", and bring back the Meritocracy.
For code to be secure, it has to do exactly what it is supposed to. The only way to know that is with a mathematical proof. Mistake one bit, miss one corner case, and you're toast. You need at least a masters in mathematics from a class-1 institution to do that. (NOT computer science, by the way--very few programs these days come close to requiring the rigor.)
With a clear mandate to be secure, the Meritocracy still won't be able to produce completely secure code, but just few mathematicians will be able to exert enough influence that finding holes will be something that will take a lot more than a kid with an AI fuzzer to find.
Of course, this doesn't address the sshd compromise--to do that, we're going to have to take a long, hard look at OS architecture.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
