Software developers should be held personally accountable for the security of the code they write, said Howard Schmidt, former White House cybersecurity advisor, on Tuesday.
Speaking at Secure London 2005, Schmidt, who is now the president and chief executive of R&H Security Consulting, also called for better training for software developers, many of who he believes don't have the skills needed to write secure code.
"In software development, we need to have personal quality assurances from developers that the code they write is secure," said Schmidt, who cited the example of some developers he recently met who had created a Web application to talk to a back-end database using SSL.
"They had strong authentication, strong passwords, an encrypted tunnel. The stored data was encrypted. But, when that data was sent to the purchasing office, it was sent as a plain text file. This was not an end-to-end solution. We need individual accountability from developers for end-to-end solutions so we can go to them and say: 'Is this completely secure?'," Schmidt said.
Schmidt also referred to a recent survey from Microsoft which found that 64 percent of software developers were not confident they could write secure applications. For him, better training is the way forward.
"Most university courses traditionally focused on usability, scalability, and manageability, not security. Now a lot of universities are focusing on information assurance and security, but traditionally Web application development has been measured in mouse clicks — how to make users click through," said Schmidt.
Companies that develop software also have a role to play, said Schmidt, by checking that prospective employees have relevant security qualifications before hiring them.
The British Computing Society (BCS) agreed that there should be accountability in software development, but argued that companies should be held responsible for the security of the code written by their employees, rather than the employees themselves.
"Howard has gone to an extreme by saying software developers should be held personally responsible for the security of the code they write, but we broadly agree with the direction he's taking. I know a lot of developers who would be very uncomfortable with that level of accountability, especially if that were legal accountability. It is a company's responsibility to make sure the security features of its software are tested with rigour," a security spokesperson for the BCS told ZDNet UK.
"There is also the point that code isn't static — once purchased it can be modified," the spokesperson added, pointing out this would reduce individual accountability.
In addition, many security attacks succeed because users have not installed the latest patches, or installed a system incorrectly.
Businesses themselves should accept some responsibility for the security of the software they purchase, according to the BCS.
"There is an element of 'caveat emptor' — buyer beware. Before buying any software an enterprise should check whether a vendor uses their own security software. They should also be accredited with a CMM [Capability Maturity Model] standard — it's like a kitemark. CMM level three, four or five is an indication the software has been developed by quality developers," the BCS spokesperson said.
"The software has to be shown to be fit for purpose. This is essential for producing a trustworthy online environment."
Do you agree with Schmidt's views? You can have your say by voting in this poll.
Talkback
If you are writing programs for a specific OS then your employer should be held responsible for your code. But, what if your code is secure but the OS is not? If the OS lets a hacker in and he uses your program to his own end, who then is responsible?
BUNK! Absolute bunk! Unless Schmidt acknowledges that most bugs exist in software because of budget, time, and political constraints that are completely out of the programmer's hands, he has absolutely no idea what he's talking about. A software development environment is built around a programmer that has him pressured on every side to work faster, to cut corners, to produce more code at the expense of quality, and you then want to punish him for the lack of quality in his code? Absolute senselessness.
This is nonsense. The company should be liable for flaws -- and not only security flaws. This is already the case (at least in some countries) for software that is entirely sold to a customer, but it should also be the case for licensed software. It does not make sense to make developers liable for many reasons, one of the most important being that to come up with secure and bug free code you need a good organization, not just good coders. Also, it does make a difference what language you use for development, what analysis tools, what testing methods etc. All this is usually not influencable by a single coder but something that the company decides, often based on cost/profit calculations. If the company faces the risk of getting sued, these calculations might look a bit different. If a coder really sabotages all good efforts by the company, he could be liable towards the company, but the first partner for a liability case to the user should be the company.
Dammit!
I'm so fscking SICK of these people who treat as if it's something that can be permanently gained by doing A, B, and C.
BULL!
Security is about understanding your platform.
It's about knowing the strengths and weaknesses of said platform.
It's about maximizing the strengths and limiting/minimizing the impact and exploitability of the weaknesses.
It's about doing A, B and C, to get going. Then next week, you do D and E. Then think about implementing F. But make sure that it doesn't conflict with B.
Also, they need to understand that security is NOT about keeping people out of the system. Face it. If someone wants to get into your systems bad enough, they WILL get in. Regardless of your protections.
It's about making it so difficult to access it in an unauthorized manner that:
A: The invader gives up and moves on to easier targets.
B: Spends so much time trying to gain access that he gets noticed eventually.
C: Has to utilize truly heroic (and traceable and wildly obvious) means to gain access that he gets noticed right away.
So please, people! STOP with the damn pipe-dreams about "totally secure" systems already!
The only "totally" secure system is one that's been rendered down to shavings and disbursed in random geographic locations via wind, water, and other means of distribution.
Customers want developers to write software that does everything for a low cost. Employers have to meet tight margins which don't allow small IT firms the luxury of training their staff. The cost of training courses and materials aside, we cannot afford the time away from work.
Add to that, the fact that most tenders have only the vaguest of specifications, which lead to enormous amounts of remedial coding after delivery.
Security? All very well, unless you have users who can't remember their password from one day to the next and write it on the desk. Either that or have everyone in the office log in as "Admin".
In most cases, the developer does not own the code. The company does. If the company owns the code, the company is responsible for it.
Developers don't make the decisions as to what is put/not put into a product.Seems like a way for the decision makers/management to shift responsibilty from their decision and blame the powerless developer.
I am sure he writes code every day!! Here is another dump ass that does not know his head from a hole in the ground. When you manager says you have three days to write some code and you know it will take longer. Then things are going to get overlooked.
I would really like to know the alternate reality this guy is in, it must be a nice place..
This won't work for several reasons:
** Since most companies have developers relinquish their rights to the code, it doesn't make sense that they should be liable.
** The developer has little / no input into the QA process and can not be expected to find their own bugs. Since a company can choose to minimize QA or eliminate it --its not fair to penalize the developers.,
** Few Developers design the architect or write the specifications. How can you single out a developer who is writing to specification?
Software is extremely complex and will always be complex - This CEO person, I don't believe, understands the fact that you'll always suffer from factorial explosion. There is just too much to test to assure 100% reliability.
Also, the article mentions CMM as a sign of quality - It is ins't.
Consumers should be (and ultimately are, through lower security) held liable for security holes in software. The fact of the matter is, many security holes exist because companies need to be first to market with a particular idea, or risk not making a profit on the software. So, testing is skimped, developers are told they need to finish a particular feature in less hours than they think it really will take. They are asked to work nights and weekends to finish a product, all in an effort to be first to market. If, however, consumers refused to buy buggy products, then development companies would be forced to take the time to really make sure their software is solid. No developer wants to write software with security flaws in it, but when their time to finish a feature is cut, they don't get time to analyze the myriad of ways that the code will be exercised in the real world.
If we take this to its logical conclusion we have two scenarios:
1. There are no more developers except those that have signed contracts with their target audience, which limit damages and responsibility.
2. Software development slows to a crawl and most projects are scraped. It is almost impossible to secure a piece of software from seurity breaches. Case in point: sendmail. This program has been around since the early seventies. It was written and rewritten many times. It still has problems with security to this day. Its not that its authors are bad programers but that security is a very difficult thing to nail down.
The only way this gets any better is to have well written and documented requirements for each and every project out there. This has historically not been the case.
Well this will certainly have the effect of getting
rid of security holes. Developers all leave the field
after the first few lawsuits, no software gets written,
no bugs are introduced.
Security holes are often the function not of
developers work but of managements, and/or
software integrators. I doubt any one developer
at microsoft is responsible for the ease with which
spyware is installed. The fact that users can easily
run code off the net is not a bug, its a design
feature. The code works as its supposed to, the
problem is that management puts convience far
above security in its priorities.
However in a complex system its very hard to
insure that it is secure, or even define what
secure means. For example your home provides
only symbolic security. Glass is easily broken,
locks are easily picked or drilled, etc. making
software truly secure would be like building a
fortress that can stand up to all attacks
unguarded. It simply can't be done. Users must
take some responsibility when it comes to
security just as a home owner must in the real
world.
CMM doesn't represent how good your developers are. It just represents how much time and money is wasted on the process, as opposed to the quality of the code.
CMM 5 organizations still launch satellites that are completely non-functional. CMM 5 organizations still produce software with security holes.
The fact of the matter is if your reputation as a company is built on secure software then you just _PAY_ for several experts in the field to review every piece of code, or have them write it. The problem is these greedy bastards just want to send the software to India, and you only end up with half ass work.
Howard Schmidt sounds like yet another egghead who hasn't wrote any software. There is not a "theory of security" that can prove mathmatically a software let-a-lone a system of hardware, firmware and software is secure. MD5 is being successfully attacked today by a group in China. Should the author of MD5 be stretched on the rack?
Insecurity is the outcome of not treating hardware, firmware and software as a system in need of optimization. What current functions that have been happily executing in each of these three boxes since the 1950s need to be moved, spit or enhanced? The "no execute" bit was recently rediscovered by Intel and AMD but Alpha had it on day one. VMS uses descriptors to define strings while the insecure operating systems of the world don't. Back in the 1970s the idea of opcode encryption was used to prevent theft of software while later research has shown the idea prevents virus injection. The political aspects are important in this discussion as well.
The bottom line Howard's proposal would lead to malpractice insurance for programmers and possibly eight years of school and two years of residency before they could start writing software. We all know what this has done for America in terms of doctors. This would drive development overseas. Keep in mind, American sofware is an important asset that must be maintained by loyal Americans and not by foreign nationals here on H1B visas like so many Congressmen want so they can stroke their rich company friends. H1B visa holders will eventually (hopefully) go home possibly leaving eastereggs in the software they wrote here. What would happen if stock market, hospital, banking or power plant software went offline due to attack? Can you trust foreign nationals?Threatening programmers with personal liability is not the answer. Exporting programming jobs is senseless and makes security impossible just like importing foreign nationals here to do the work.
Howard, the sign on the wall says Good, Quick and Cheap. You get to pick two of the three.
WHAT CONSTITUTES A SECURITY HOLE? WHAT ABOUT MISUSE OF GOOD CODE? This guy is a moron. How would you enforce something like this? How do you make the differentiation between a security hole and a feature? How can you guarantee that decent code embedded in a poorly designed application is free from blame? The obvious answer is that you can't. His proposal is completely unworkable.
I hate guys like this. I have an appendum to his suggestion: stupid idots should be liable for the stupid things they say. Then maybe we can get rid of clowns like this. Good job america! Schmidt was the White house cybersecurity advisor? Well he's even dumber than his boss. I just want to know how does he feeds himself.
I'd love the time to make all my code completely secure - now tell my boss that it's going to take twice as long (or more), and then tell the client. I don't get to make that decision, so I'm damned if I'll be responsible for it.
One thing not mentioned in the article was the client's responsiblity - if you want REALLY secure, you're going to have to pay for it. That means stepping away from 'always buying cheapest' or 'screw them in the contract' mentalities that so many companies take. I guess, in short, if you want something reliable you've got to get real about your investment.
There are huge problems with this idea:
a) developers are only one part of the TEAM that produces the code; what about those that were involved in the code inspections? What about those in verification? What about those that chose the features in the first place? What about a CEO that chooses to ship when a product isn't ready?
b) developers are in a hugely economically disadvantaged situation compared to the company they work for. The developers would need to take out personal liability insurance that would either push people out of the industry and/or push up the wages, so the company would end up paying for it anyway. In many cases it's more expensive to buy insurance than for the company to self insure.
c) companies can put enormous pressure on developers to agree to sign off on things the developer knows aren't fully tested. What would you do, agree to ship or get fired? Probably ship. Basically, in practice, the code always ships when the companies says, and the company would do this knowing they aren't carrying the can for damages.
All ways around, it's a stunningly, appalling, terrible idea.
Training is just one of the variables in this equation. I believe cost is the other. Typicaly, software projects are under the contraints of costs and tight timelines. In those situations, it is Inevitable that quality is sacrified somewhere. Cost, time and resources are the tripod of software development supporting quality. If you kick one of the three, quality is the one that suffers.
This is a clearly a bureaucrat tooting his own horn. There are so many reasons as to why this statement is ignorant and quite frankly, impractical. The boisterous gentlemen has obviously never written a line of code, had deadlines and business decisions sway his design intentions all to get a product out the door, etc... Developers right code… Business dictates how secure it is.
In his defense, security should always be placed in high regard. It is easy to sit back an criticize and place blame on individuals when we really don't understand what they do or how they make their living...much like when a normal citizen criticizes those in power and public office when they govern for self promoting, sound bite quality, and loud talk show worthy reasons in order to get the mindless ranting of the ever-so-rating-conscious media to play along instead of enacting common sense law. So easy to do….
Brilliant...This is the fastest way I can think of to encourage the best security programmers to leave the field. Inept programmers, having no clue they are inept, will be writing security code.
External design and code reviews accompanied by extensive black box testing is the only way to ensure that the code performs properly, and companies are responsible for this, not developers.
Howard Schmidt is a security expert? If this is an example of how he reasons I wouldn't trust him to guard my Yugo.
Kiss my donkey Mr. Schmidt!! I wouldn't accept such responsibility even if I had absolute authority to decide deadlines, budget, products and platform used, the client's operating environment, and so on.
Let me introduce you to The Real World(tm). I am required to have a system up and running in an unrealistic timeframe (which I never approved), so the system does not get the amount of testing that I'm happy with. I am assigned new and inexperienced programmers to work on the project, so I end up spending lots of time checking their work and helping them along. I am required to produce a system for an operating system and platform that I personally have exorcised from my own computers. When the system goes live, I immediately have to start on the next project which has an even tighter deadline so I have no time to keep an eye on the system as it starts to be used. Of course, once it's up and running the only time it will be revised is if the client requires some change to the system, so often there's no ongoing tests and improvements being done to the overall quality of the system. And if any changes get done they may well be done by someone else because by now I'm working on something else. Not to mention that there are people out there constantly trying to discover new ways of breaking other people's software - which were not known at the time the software was written.
Of course if my employer were to try to do things properly, with the right amount of testing and code reviews and so on, then we'd never make any money because the same clients who are so concerned about security are even more concerned about how much they're paying for their systems.
Want security? Take regular backups and have a duplicate installation ready to be rolled out.
Not to speak lowly of a mans education, but Mr. Schmidt's background is not even on Software Engineering or Computer Science: "Mr. Schmidt holds a bachelor’s degree in business administration (BSBA) and a master’s degree in organizational management (MAOM) from the University of Phoenix." His credibility is thrown out for me...
Has this person ever worked in a 'real world' programming environment which involves legacy code, deadlines, limited budgets, dynamic specifications and sales people who want the product out yesterday?
It reminds me of the Y2K problem. I remember, back in 1985, taking flack from my superior because I was concerned with how the year 2000 would affect a system I was modifying. My superior made the comment that he wouldn't be at the company when the problem hit, so I shouldn't be concerned with it.
Ten years later, the year 2000 problem got hyped as Y2K and hundreds of millions of dollars was spent on making sure that it wasn't a disaster.
Accountability needs to go up the chain to all parties involved, not just the developers.
Mr. Schmidt is gone senile
Software products will take longer to deliver, cost twice as much, and get obsolete even faster.
Should a developer be held accountable for a security hole? Maybe, that is assuming that we are going all be paid high six figure salleries and we are going to be given the needed time needed for designing, developing and testing the code we write.
I today's market the companies, for which the vast majority programmers work, lack a true design team. You kow the guys whose sole job is to take a concept and fit it into an applications design model and make sure that it will work correctly without creating security holes.
They lack the documentation experts who write the functional specifications and the code specifications that tell the developer exactly what needs to be implemented, how it needs to be implemented and where it needs to be implemented.
They lack a properly trained QA team that does nothing but test the application for bugs.
So in most cases the Developer becomes all these jobs rolled into one. I'm not saying it is right but it is the way that most companies work.
And on the end of training, most companies don't or rather won't send their developers out for trainining due to the cost. This would imply that we need to find a way with our hectic schedules and tight deadlines to recieve the training ourselves. I know I franly I can't afford to be going to training seminars once a month or even every few months just to stay on top of the latest in security techniques. Many companies have gotten around this problem by sending one or two developers to training and then bringing them back to train others but this is kind of like whisper down the lane from when we were children.
I'm by far not saying that as a programmer you should not have to write secure code but under the conditions which we work it is a rather imposible feat to be perfect every time. Especially since usually more then one programmer is modifying the same pieces of code.
I don't think he is wrong in his thinking but he is looking at things from an ideal perspective. If a programmer has the time, all the proper support teams, and all the needed training at their disposal then there is no reason they should not writing secure code.
And as for the feature portion of code that is something that should be documented somewhere as a feature asked for by the customer at which point the coder is not liable if it is a security hole introduced by a feature the customer specifically asked for.
Here's why Schmidt is an idiot.
Individual developers can not know whether an end-to-end system is secure. They can only know their own piece of it. So his argument falls down right there. Sure, there can be a person who has the role of verifying end-to-end security, but that is only one of the team, and he/she probably won't be a developer.
How about this. In his scenario, the end-to-end failure was a sin of ommission. They failed to implement one leg of all the meny potential routes in a system. So why not make developers responsible for ALL sins of ommission? Hell, someone might look over my shoulder while I'm typing, so the screen should have animated dancing anti-eavesdropping fonts that can only be read by squinting. While we're at it let's make lawmakers individually responsible for any problems in the laws they pass. We'll do a full review of the historical record every time a law is revised. And for laws they don't pass, and for laws they fail to draft, or fail to think of.
This is pure insanity and a perfect example of a political official attempting to pump a "hot" issue. Where does it stop? Do you blame the software testers for not detecting the securty hole before release? What if the security hole is in a third party library? Do we need to conduct a witch-hunt to determine WHICH developer is responsible? What if both the component and the application that consumes the component are both safe on their own, but rather it is the combination of the two that opens up the security hole? How about operating system changes? What if you wrote a piece of software back in 1996 using technology available at the time but today when run your software on modern operating system a security hole is opened that could not have been forseen when the software was written?
Mr. Howard Schmidt has no clue about software development and the dynamics that go into developing a system. We are always compromising functionality, security, performance, and staffing all to fit within a given timeframe and budget. It is normally executive decisions that are the cause for poorly written systems.
Who do you hold accountable for the system that included 50+ developers? It is utterly ridiculous to hold an individual responsible for something that they typically have little control over. Roll the responsibility up to company that produces the product, sets the budget, and determines the timeframes and ultimately benefits from the sale of the product.
Let me guess... BUSH White House advisor.
The article says he is a "former White House cybersecurity advisor". Heh, I bet I know which administration.
Maybe we should pass a law making all cronies liable for all ill effects and opportunity costs of cronyism, including the expense of determing how to detect it, how to compute the costs, and carrying those out. Call it a "crony tax". It works like this: yes, you can have this cush job in your uncle's gold buddy's department, as long as you sign here agreeing to pay your crony tax.
Sounds like a great idea to me... What about other industries? Who else can we sue for our problems?
Lets say someone breaks out a window in my house to gain entry and steals everything I own. I guess this would mean I can hold the mechanical engineer who designed the window liable for my losses? Or maybe the poor shlub who is pushing buttons at the glass factory? Or how about the architect who decided to use this particular window when building my house?
Wow, it's a regular shooting gallery of people I can blame! How about blaming the person who exploited the "securty flaw" in my house?? Nah, we won't blame them...
Bad idea. Here's why:
1) Developers generally take marching orders from middle managers who are better at managing deadlines than the quality of code that is developed. A ship date is unlikely to be missed because of an obscure, hard-to-explot vulnerability.
2) To make developers personally liable would make software development prohibitively expensive. Not only would you have larger teams to handle all the new security requirements, I would guess that younger people would be less inclined to enter software development due to the increased personal liability. Students are running away from the medical field for the same reason. So, a lower supply of workers will drive up wages too.
3) What about the kind of errors that originate between the keyboard and chair? Idiot users can be a security risk themselves. If they use tools incorrectly are developers to be held liable? There is only so much bulletproofing one can do.
I highly suggest the book Beyond Fear by Bruce Schneier to the author of this article.
If this guys is an "expert" I'm a pink flying elephant. All systems are vulnerable. This is the type of guy who thinks the number of codes a developer writes is directly proportional to how productive he is. Seriously this guy could only work in the government. He'd get laughed out of the private sector.
Mr Espiner,
Thank you for publishing this article and bringing Mr Schmidt’s remarks to the attention of myself and my fellow software developers. It’s true that some developers are underqualified for positions they are asked to fill. However, most of them have a sincere sense of responsibility for what they develop but must work to the deadlines required by their management. In many cases, developers bring bugs to the attention of their management but are not allowed to take the extra time to fix them because delayed releases are bad for business. Quality development is primarily a product of clear specification, proper management, and quality assurance, not initial development. It is incredible that Mr Schmidt does not understand that, and I question his competence to lead a computer security firm. I find his suggestion to be extremely hateful and severely out of step with the reality of software development. It is tantamount to holding individual construction workers liable for the collapse of the WTC towers.
Is an auto designer personnally liable for a design flaw? How about the chemist working at a tobacco company? ..... Howard Schmidt is either unclear about the established liability process or has a personal grudge against software developers.
I love this idea!
You see, I own and manage a software consulting company. If this idiocy became law (so that ALL potential bidders, including offshorers, on a project were under the same level of litigation risk) my developers and I would make out like bandits!
Let me explain. My company has only a few developers. Each and every one of them has a great deal of experience in writing high quality, secure apps.
We would get Errors & Ommissions Insurance, at whatever cost the market will provide., then double, or, triple or quadruple the costs of that insurance, and pass it along to the customers in the hourly rate.
We would also, as I'm sure the insurance companies would require, lengthen the project by a factor of two or three, to make sure we have the time to test the SW adequately.
This is likely to make the project cost five to ten times as much, and take two to three times as long. But that's OK, because most of the other developers will leave this field, and the customers will HAVE to pay us whatever we need to charge. Just like in 1998-2000.
So I say: bring it on!
To quote an unknown cynic: "Any change you make is likely to have consequences you will not like."
just as soon as ass-hat politicians and televangelists are held liable for the crap they spew.
If Developers should be liable for security holes then individuals at ALL levels of government should be liable for failures of their departments. Look at the players in the FEMA debacle for example.
Holding developers liable is ridiculous. Employers buy stupid operating systems, bloated needless tools, and then try to pressure developers to get more done than possible with such imprediments and this cyberidiot wants developers to pay? Hey... remember DP101? Authority flows downward... responsibility flows upward. Oh but now developers don't really have any authority but let's pass laws to "stick it to them" and give them the responsibility.
Typical of the government. Look at all the crooks in congress.. they have the authority but, for the most part, aren't held responsible... but want to stick it to people that actually do the work... not the suits.
Oh yeah... CMM is a big laugh too. One contract I was on they cared more about coaching us what to say if they were audited. At the time they were really only Level 1 (chaos)... and couldn't recreate their mess. CMM is great in concept but, in practice, it's just a way for high priced software firms to "buy" their way (through accreditation) to a degree of certification so that only they get the government bucks.
another idiot suit who got his job through cronyism, trying to legislate morality for the benefit of big business who promise to give him kickbacks. disgusting this nepotism and irresponsibility. why don't we sue the makers of sledgehammers when they are used by a criminal to break a window to gain access? clearly we should go after those who use tools in anti-social ways, not those who have created potentially useful tools. idiots.
It's freaking' time... the difference between free software and commercial cosftware should be not only that one makes a livign out ofn it but at the same time the one makes a living out of it should be held liable for its money-making product.
I must add that buck would stop at the company, not the developers (usually not one person), just like you would sue the hospital for malpractice, not the doctor himself.
I love the idea. But if I wonder if any employer will accept the conditions set by developers daring and will to develop secure code.
If one puts the full obligations (because that is what happens when you make people personally liable for business risks) with the developers , then these obligations will be balanced by rights.
And this rights will be expressed in salary and a say in the functional specifications, used tools, platforms, in short everything.
Security is not a separable notion!
On the economical side. Isn't the company not the insurer for the risk caused by the developer. Developers accept lower wages and allow companies take the larger profit.
In an commercial environment security can only be an economical issue.
If the developer is legally liable for his own code, then the developer should have the copyright and IP rights on that code. Traditionally, anything developed as an employee is the property of the company. If the company has the rights on the code, the company has the liability on the code.
Also, how far does this liability go? Can I sue my car maker for the glass windows when a thief smashes one and takes my radio? Didn't they understand that glass can be broken by a crowbar, tire iron, or sledgehammer. Suppose there are no windows. If a crook uses a plasma torch to cut the roof off and take the change in my cup holder? Should it have been made of 1" steel? Where's the line between secure and insecure? Where's the line between good and good enough?
This is a standard business tatic...the company wants to take all the reward, and shift all of the risk to someone else
It is getting to the point where you can not do honest work without a waiver from tort liability
Even if I owned the source code, I would NEVER make any guarentee as to the fitness or warrantability of the software./
agree with software application security - the developer needs to and can test its code of vunerabilities prior to deployment but it is upper managments responsibility to put the responsibility on the developers along with providing the tools and ensure all of the departments are using all of the tools to ensure COMPLETE SECURITY
Developers want to deploy and go on to the next project - does anyone come back to them and say - excuse me Sam - you have 10 lines of code that are wrong - B of A was just hacked into and has someon has gone into my bank account and transferred money - that developer is already on the next project -
Use Verisign for your hardwalls - ues Fortify Software for Source Code Analysis, reporting & testing of SECURE Code, make sure you have encryption - you need more than 1 product to ensure Security -
Bill - Let me guess... the additional product would be a... Cisco product? I'm packet sniffing a nice sales pitch. Speaking of which... considering the internet and its protocols were orginally meant for data sharing rather than secure commerce... a nice analogy might be saying "Let's bake a turkey in a microwave oven..." yeah you can make it work... but don't let your expectations get the better of you.
Poor Howard embarasses himself with this one.
CEO's should be liable for company failures. The ONLY reason why they pay CEOs that much money is because people want results, quick. Most of the time it doesn't work because they lack the skills, or just because they have no clue what to do. No profit? No big salary. It's that simple.
Howard Schmidt obviously has no understanding of how software is developed in the real world.
Most programmers would love to write stable, secure software but the constraints placed on them by management make that next to impossible.
Programming is several orders of magnitude more complex than he, or most other non-programmers can appreciate. No programmer will ever be able to identify every potential fault that could concievably happen with their software. There is always a trade-off between time/cost vs features/reliability. If he can't accept the risks then he should stop using software altogether.
Great idea if ....
- You want to ensure that all software costs 5x more than it does currently
- You want to cut out any public domain software development
- You want to ensure that only huge developer houses can afford to develope software
- You are quite happy running DOS on your new 64 bit processor because nobody can realisticly develop a security free OS
Here's an idea - How about we require software houses to commit to standardized licensing terms that allows them to return the product if they aren't satisfied with it... OH WAIT ... WE ALREADY HAVE THAT
Step up to plate Developers - don't just hide behind the screen - demand it from your managers that you have the tools you need - show them the proof they need - what would you do if their was a bonus structure for secure code - get someone like Fortify to come in and test it - those who pass get a bonus, those who don't get fired - the world is different, people are malicious - they will take the money out of your bank account, your credit could get runined - look at the statisitcs on rising Identity Theft - 911 would not have happend if this was being done