First of thank you for making my ears go pink 8)
Secondly I agree with you about incentives being the best way to get things achived (the old saw about "A willing man is worth five pressed men" comes to mind).
However like Quality I fully expect Security to show dividends long term, providing it has buy in from the very top all the way down and it's a process that is started before the product is even thought about and stays untill the product is fully retired.
But like Quality, Security is not something that shows an immediate return. Nor does it have a simple ROI calculation and it does not "keep up with the competition". Which are all negitives for those with a shorterm outlook on walnute corridor.
Even worse if you ask lots of people in the industry you get the same sort of answer that Security in software is like safety features in cars. That is everybody says that you should have them, but as customers they won't pay for them and the reality is they will buy a car on power performance top speed or just about any other feature than safety.
So security to managment is a difficult sale at best over feature buzz and zip.
Hence part of the idea around the scripting is to get managment buy in on less production time and less maintenance which are the biggies cost wise, have fairly easy ROI to calculate, which shows a quick return, whilst also keeping up with the competition on delivery times.
Also some of us remember "Rapid Prototyping" and how the "script version" got the end user buy in and delivered a working prototype very quickly. However the "C++ version under MFC" usually looked nothing like what the end user had agreed too, was buggy as hell usually late and incompleat and often ran slower than the script version...
This issue I found was got by the wrong incentives from managment (ie lines of code a day and extra flashy features).
So it's kind of a catch 22 managment won't go for security incentives unless you can prove the benifit immediatly or in the very short term. You cann't show the benifits in the short term because it takes time for the process to work it's way through the system and show it's real value to the bottom line over the entire life cycle.
I'm sure it's something Nick P will comment on because it's the same issue with using formal methods and provable verification of design etc. Even the "clean room technique" which has been shown (counter intuitively) to work rarely gets a look in.
I used to work with a developer that used Z he took twice as long to produce his first cut code as the gung ho code cutters, but he only took half as long again getting final code, where the gung ho mob would go round the wash rinse cycle five or six times taking maybe six times as long to debug as their initial code cut. Oh and his code never came back from test, where as the gung ho code used to come back every time for atleast another wash and rinse cycle.
"About 90% of the people in our IT security group can't write a "Hello, world!" program in any language, let alone understand anything more complex."
So what do they do all day?
If I read your point 1 correctly the same issue applies to bugs in the compiler or assembler of other program writing methods.
It's just that the bugs will be higher up the stack as it where. Now this might or might not actually increase security depending on how the scripting language is designed to work (which is a chat I've had with Nick P int the past on this blog).
Your point 2 is correct, but it depends on how you view/do things. For instance if those "best of breed" programers are used to develop the components of the scripting language then their skills get spread across many projects at no extra cost.
When I thought about it originaly my starting point was "how do I leverage the skills of the best secure code writers across all projects even though theres only enough of them to do one project in a thousand?".
The result was to think about a process involving a scripting process that had a hypervisor running in tandem that had a security signiture prototype an ordinary coder effectivly filled in. The hypervisor would "watch" the script and cause an exception if the signiture bounds were broken.
With regards the fundementals I'm right along side you in that battle, and if you look back on this blog you will see I've said so many times.
The problem starts with the education establishment, few are truly independant of industry, and when a large employer in the area starts dropping hints and money about what they want to see in graduates it's a brave organisation that ignores it. Partly because it's in their interests to go along with it but also it's sort of in the graduates initial interest short term (ie they get their first job).
However "teaching the tools" not "teaching the fundementals" is a very bad idea in the medium to long term. As you note the tools go out of fashion and if the student has no fundementals to fall back on then they have to start from the very bottom again which is not good for them nor is it good for industry.
One thing that often annoys me is "teaching to program in X" not "teaching to program in general". Any programing language has certain features that it excells at and teaching a student how to get the best out of language X is doing nobody any favours short term or long term.
A piece of advice I read somewhere is "learn a new language every year" not because you have any intention of using it but because like travel it broadens you perspective and understanding.
Or to put it another way there are two parts to speaking any human language, the mechanics of speach and the peculiarities of a specific language.
If you learn only one laguage when young you might as with certain languages not learn some of the fundimentals of speach. I'm painfully aware of this when many people who learnt to speak english after they were about ten try to speak my name (the C of Clive, and the R of Robinson).
However I likewise have lost out because I'm not "pitch perfect" like most Westerners, where as being "pitch perfect" is almost a requirment for some languages.
Mind you fundementals can be hard to learn, it takes about four years to learn to write neatly, about another three years to do technical drawing, and a life time to be able to draw artisticaly. All of that involves the use of what most consider the most basic of tools the pencil/pen.