Slashdot Mirror
What is Responsible Disclosure for Security Flaws?
Silverdot writes "In an article on ZDNet, the author brought up a few cases of uneasy relationships between security researchers and software firms. While those who report the bugs should first seek to notify and work with the software firm to resolve the flaw, One researcher commented: "All researchers should follow responsible disclosure guidelines, but if a vendor like Microsoft takes six months to a year to fix a flaw, a researcher has every right to release the details." Should the onus be on the software firm to manage each issue and the relationship well, or does it fall to the morally responsible user?"
The cost of secrecy is high. Reasonable response times ( up to, say, 3 months) before disclosure should be allowed - even for firms that seem to be sitting on their hands, and if the firm is close to a patch and they are willing to communicate and work with the researcher a longer time may be reasonable. Overall, disclosure of a problem is always in the USERS best interest, and secrecy is always in the SOFTWARE FIRMS best interest. The longer a known security issue exists, in secret, the more likely it is that someone else has found it - and that puts everyone at risk. The rights of users ( who are victims of the software firms bad code) should always come before the rights of the software firm. Always. So this means disclosure should be seen as a blessing. Those who complain about irresponsible researchers putting everyone at risk are wrong - everyone is already AT RISK. Failure to let me know what risks I face should be seen as the problem. I need to know.
I have nothing to hide. So, why are you spying on me?
"Responsible disclosure" is a propganda term propogated by the software firms to a) get as much time as possible to fix security holes, and b) indemnify themselves as much as possible against any public disclosure of said security holes by labeling the disclosers as 'irresponsible'.
If a security hole exists, it exists, despite how much public discussion about said hole is quashed. Today more than ever, there are unscrupulous people out there laboring to find and take advantage of these holes. Muzzling the virtuous hackers, who only wish to make things more secure, is counterproductive in the extreme. The only 'responsible disclosure' is full and immediate disclosure.
____
~ |rip/\/\aster /\/\onkey
I'd be the first to tell people about my security flaws, hell i'd advertise them. I'm just going to make some half-ass excuse and blame someone else anyway. at least thats what all the k00l keds do dez d4yz.
i don't care
Someone tells you that you have a security hole; you fix it - A.S.A.P!!
Evil people don't think they're evil. - George Lucas, Making of Ep III
If you find a security hole in someone else's code you can either:
1) use the DJB approach: reveal the hole in a public forum, preferably with a working exploit.
2) use my preferred approach: fix your clients' copies of the program, and otherwise keep quiet. Consider it a competitive advantage when the next Apache/SSH/PHP worm hits.
Any other approach is an utter waste of time, for everyone except the vendor.
If you reveal the flaw only to the author, you are:
a) Working for someone else without getting paid.
b) Saying "it's okay" to write software with security holes, because shucks, some kind soul will fix it for you.
c) Not telling the rest of us, the sysadmins of the world, how to protect our own systems. You see, the company or author has already demonstrated incompetence. Why help them? Of course you don't owe anybody anything (see point #a) but if you're going to tell anybody, tell the people with the most to lose!
Of course, I'm assuming we're working with software where you have the source code. Secure software without source code is an oxymoron. And no, I don't think the license makes code more secure, since maybe 95% of the coders out there can't code properly. My ability to audit is what makes it more secure, and yes, I do as much of that as I can.
Let me make the point clear: I don't care if the author fixes the code or not, or how quickly he can "patch". I need to know the details of the problem so I can solve it myself. That's what's important.
People who advocate "irresponsible disclosure" (my term for any disclosure that doesn't inform the end-user first) are really secretly afraid that someone will someday find flaws in THEIR systems and embarrass them. But that's the point: embarrassment is a cost, and people will try to minimize costs any way they can. At some point they will actually try writing secure software. And maybe at some point, users will start demanding secure software.
I think we can all agree that the security situation is getting worse, not better. Most of the software I see these days is garbage, to put it mildly. Bloated, complex, insecure.
Constantly holding the hand of authors via irresponsible disclosure is not going to solve the problem. Do you want to wait until the government regulates software, basically punishing everybody for the sins of the incompetent? Or should we let market forces do their thing?
This is a very tough one because it is multi-faceted. The most common argument against researchers publishing is it practically guarantees an exploit will surface in the wild sooner rather than later, possibly before a patch is available. OTOH, if they don't publish, it might be discovered by criminals first and exploited more quietly, gaining a foothold in the wild before anyone even knows the hole is there. Sort of a damned if you do, damned if you don't scenario.
But when a vendor is sitting on the report and not issuing a patch, it can grow increasingly frustrating for the researcher. They not only have to watch people trundle along, blithely unaware of this gaping hole in their systems, but they cannot get their proper credit for the discovery. It's a bit like publishing for academics. Getting to take credit for the discovery of a security vulnerability has certain perks that the researchers are denied as they sit quietly and wait for some corporation to decide when to go public with the announcement of the hole and the patch for it.
Probably the best solution would be to have a set of universal guidelines set at one of the major conferences. Something that takes fairness to the researcher, fairness to the software vendor, and fairness to the public into account. I know, I sound like a politician saying "let's form a committee to study this", but I doubt that any one person has a solution that makes everyone happy or could even be considered a fair compromise by all involved parties.
- Greg
Start a happiness pandemic
I mostly agree with your overall analysis, but I'm compelled to point out that this one statement seems self-contradicting. What is the difference whether a security issue is "known...in secret" rather than simply "unknown"? I submit that a better way to say this would be that "the longer any security issue exists, the more likely it is that someone else has found it," without regard to how known or unknown it may be during the interim.
The only way this is not true is if you consider the (perhaps non-trivial) cases where the "secret" is leaked, intentionally or otherwise.
The trick to proper security flaw reporting is understanding what is the tactful way to state it vs. tactless way.
An example of a tactful way first report it to the software developers and see if there is a patch. If not then get a little more forceful and release to the public that there is a flaw in a feature on this product and it seems to effect this range of people.
An example of a tactless method is to make a root kit that takes advantage of that flaw. Or tell the general public how to reproduce it.
You will need to remember what you say publicly will be used by people who will do good things about it and bad things about with it. So if you give them enough information to say block a port or temporarily turn off a feature vs. giving giving the bad guy a way in while the person will need to figure out what you did in your root kit then find that is the problem.
Be mindful when you report the flaw to the software company as well. You are telling them that they have an ugly baby and most people don't want to hear that. Try to be friendly with them but stern on the severity on the flaw. When it comes to reporting flaws you are no longer dealing with computers but with people and if you piss them off to much they will be less then helpful.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Responsible disclosure from Microsoft's perspective: You tell us and only us. We'll tell the rest of the world when we think it's necessary (if ever).
The NSA: The only part of the US government that actually listens.
And what about users that would be able to do something against the security risk (not use a certain program, disable a vulerable service or firewall it in for example), if they only would be aware of it?
Common Sense is sometimes violated egregiously by one side or another, and then this is raised as an issue. If a security researcher sends one email to some ill-checked "bugs@" address and gets no response, then just releases a couple weeks later, that's irresponsible.
When someone emails a vendor many times at many addresses, finally gets a response where they tell him, "We're looking into it", and then proceeds to cease communicating for 45 days, that's irresponsible by the vendor, and the researcher has every right (and some would say, a responsibility) to publish.
Where's the middle ground? Well, it's a wide open space. Those without bad ulterior motives (ie, publicity-hungry or vendor-hating researchers, or head-in-sand or deny-first-ask-questions-later vendors) don't really have much difficulty negotiating the middle ground, because there's a lot of room. The problem, of course, is that the only time you *hear* about disclosure issues is when someone is being a muttonhead - either vendors trying to keep secrets, or researchers who feel no sense of responsibility or make the most token efforts to make contact. For the rest, there's little debate, because it's just easy to do it right.
I can't believe that this question:
"should the onus be on the software firm to manage each issue and the relationship well, or does it fall to the morally responsible user?"
is even being seriously asked. Of COURSE the onus is on the software compnay...they made the damn thing and are making the money from it, right?
This could only be a question in the software world. Before making the jump to IT, I built acoustic guitars for years. If I BUILT it wrong, not only did I hear about it, and not only did a lot of my potential clients hear about it, but I HAD to fix it, and not next week, but ASAP.
I'm honestly curious as to how the rules got changed for software.
Boycott everything - they're all trying to fuck you one way or another
I really love the Full public disclusure advocates. They seem to have a romantic view of the black hats. Rather than a selection of small groups, they seem to imagine a vast international consipracy.
The justification seems to be that they might already know of the vulnerability. A weak argument if ever there was one. Just because some black hats know of it doesn't mean all of them do. And there's no evidence that any of them know of the vulnerability before the flaw is revealed.
We change from a possibility that some blackhats know of a flaw to a certainty that all blackhats know of the flaw.
And if there's evidence to counter their claims, the full disclosure advcates will come up with the most ludicrous scenarios.
Recently there was evidence that they did not, after a virus was released that exploited a recently reveled vulnerability. I pointed this out. The explanation was that the blackhats already knew of it but were being cagey. Since it was now public, they had to exploit it as much as possible before it's patched. Of course - occams razor would suggest simply that none of them already knew about it.
This makes an interesting read
http://wiretrip.net/rfp/policy.html
Well thought document, written with input from big names in the computer security scene.
But when my holes are open I close them quick before someone shoves something in there... like a Trojan.
Responsible disclosure has no real benefit to the end user. It may stop some percentage of big outbreaks of worms but it doesnt in any way make life for admins guarding sensetive information a bit easier. From what i have understood many exploits are used by crackers long before they are in the wild. That is, many networks and servers are broken into and gathered for intel long before there is a patch, sometimes even for years.
Responsible disclosure only lenghten the period for the crackers in wich they can use their exploits for real cracking. It gives at best a breather for software manufacturers to drag their ass. It also doesnt promote real testing and auditing of software before its shipped. I would as an end user much prefer more tested software, that includes OSS thank you very much. Current release cycles is way to short to give any time for testing.
HTTP/1.1 400
(Posting anonymously for career protection.)
... they apparently didn't get it, and they actually wanted to distribute the full working exploit very widely inside the company.... I was told ... "Give this to all the sales engineers and to all the pen testers."
The problem has been posited as researchers v. software companies. The problem is, there are some researchers who work for software companies, some very dirty software companies, and their management would very much like to take market share from their competitors.
Someone else gets hurt? That's Cisco's problem.
-----------
WN: So ISS knew the seriousness of the bug.
Lynn: Yes, they did. In fact, at one point
WN: Why would they want you to do that?
Lynn: Well, because it bruises Cisco, remember? Mind you, this was something that Cisco hadn't gone public with yet and that's not useful to pen testers because what do they advise their customers to do (to protect themselves if no information about the vulnerability has been released yet)?
I told them, "You do realize if you do that, it's going to leak?" And (one of the ISS guys) says, "That's Cisco's problem." And then (another ISS guy) turns to me and says that they need to understand this could be their Witty worm. I was like, Whoa, what meeting did I walk into?
(The Witty worm was a particularly aggressive and destructive code released by someone last year that targeted computer systems running a security program made by Internet Security Systems and even more specifically targeted military bases using the software. It infected more than 12,000 servers and computer systems in about an hour. Because of the worm's speed in spreading and its creators' apparent knowledge of who ISS' customers were, some security experts speculated that someone working for or connected to ISS might have been responsible for writing and releasing it.)
At that point, I told them all no, and they fought it and I resigned right there on the spot. And this was about a month ago.
I thought they were handling this in a non-ethical manner. Because it was just way too fast and loose with who can see this.... I mean, I don't even want people to see it now. (ISS talked him out of the resignation by agreeing to give him control over who could see or have the exploit.)
---------
If "Responsible disclosure" is only a propaganda term, why would Mozilla and other popular open source projects use them. Why do they block access to security issues.
If a hole exists, it exists, however not everyone (including hackers) knows about it until it is published. Holes exist nowadays for years, some flaws for instance in NT 4.0 are discovered now 10 years later. Software is waay to complex nowadays it is good bet to take that unless published most holes will go completely unnoticed, until some other security firm after 100s of hours of research will find it.
Oddly enough, I used to work on a project for a huge company where this happened. We had a large search-engine like project that was running much slower on a 16 proc Sun box than I thought it should. I noticed that 40% of our traffic came from the same 5 subdomains, representing over 10 - 20,000 hits/hour. "Who uses a search engine that much?" I asked.
Me: Something fishy is going on here.
Boss: Report your findings to the project team.
Project Team: Hmmm... that is fishy
[weeks go by]
Me: Something fishy is STILL going on here.
Boss: Report your findings to the project team.
Project Team: We don't have a disclaimer on our site that restricts the number of hits/hour. Contact legal.
Legal: We'll get back to you.
[weeks go by]
Me: Something fishy is STILL going on here, and it's getting worse!
Boss: Report your findings to the project team.
Project Team: Did legal get back to you?
Legal: We'll get back to you.
[weeks go by]
Me: Something fishy is STILL going on here, can I at least block them via hosts.allow or a firewall?
Boss: Report your findings to the project team.
Project Team: Hmmm... I don't know. Did legal get back to you?
Legal: We'll get back to you.
[weeks go by]
Slashdot: "Your search engine is a known hack to alter page rankings at Google!"
Slashdot Commenters: OH yeah, that's been a problem for a while. That damn company!
Me: YIKES!! SLASHDOT has posted our company name in connection with fraud. AGAIN!
Boss: FUCK! DO SOMETHING! This is a PR nightmare!
Project Team: FUCK! DO SOMETHING! This is a PR nightmare!
Me: Luckily, I have already written a script to do so. Give me a sec--
Legal: We have shut down all admin access to this box, because there was this article on Slashdot, and we need to see if it's been hacked. We've opened a ticket.
Me: GAAAAAHHH!!!
The two groups who are responsible for security problems are software vendors and companies that buy buggy software and use them for critical data. Those are the primary parties at fault when security problems cause loss of money or life. Unfortunately, both of those groups are increasingly successful at trying to blame other people and creating legal obligations for other people.
What we really need is a market driven solution. If MegaBank discloses 200000 customer records to criminals due to a security bug in their Loses XP operating system, then they should be responsible for all the identity theft-related expenses that that causes their customers, plus statutory damages (say, $1000/customer) for distress and inconvenience for their customers. If they do that sort of thing too often, they'll go out of business. That kind of financial risk will force them to demand guarantees from the creator of the Loses XP operating system, which will force that company to finally get a handle on security or go out of business themselves and be replaced by companies that understand security. And if it turns out that it simply isn't possible to do something securely with software, well then only the non-computerized companies will survive in the market.
So, what's the "responsible" way of disclosing security bugs? Any way you feel like it, as far as I'm concerned. The security problem in someone else's software is not your responsibility in any way, shape, or form.
Let us suppose the researcher (R) reports a security hole to the software producer (let's call them M). ... who also have more items in their priority lists. In a case like this the timescale is probably approaching a month for a "fairly high priority" problem.
First the report on the problem has to get to someone who has the knowledge to investigate and fix the problem. In a large organisation this is likely to take several days. It then has to be prioritised in his workload (Hey! you think there is only one problem?).
Next he has to verify that the problem exists (hopefully R has provided a repeatable example).
Then comes the first difficult part - identifying the root cause of the problem. If it is a buffer overflow this might be easy; a tricky combination of factors in a single module may be more difficult; an underlying design feature or a clash with an important usability function is going to cause major difficulties.
In the simple cases an initial fix may be possible (and right first fix) within hours - but will then have to be tested against the whole test suite and documented. We are, by now, probably already a week after first report for anything beyond a "damaging exploit in the wild" event.
For the complex, but limited in scope, hole much more is going to need to be done. Several people need to understand the problem and possibly redesign the module. The replacement code will take longer to get right and to test. It probably also needs to be done by the more experienced members of the team
Now think about the clash of design principles type of problem - in practice this is probably going to need a fairly ugly hack by very skilled programmers (A major redesign is rarely viable for widely distributed commercial software). How long do you think this is going to take?
Step 1) Find bug.
Step 2) Write exploit
Step 3) Write fix
Step 4) Let vendor know about security flaw and show them the exploit. Tell vendor you want X amount of dollars for the fix within Y days or you will release said exploit publicly.
Step 5) If vendor doesn't put up the dough or produce a publicly available patch within Y days, patent said fix and disclose exploit to the public.
" The best security is to inform all users once a flaw is discovered."
No, it isn't.
The best security is for software vendors, security firms, and AV software providers to share information and work cooperatively to get AV updates to end users (average Joe Sixpack) while the OEM vendor works on a patch--and keep it out of the "public" eye.
Your internet-connected mom/gandmother/uncle/aunt would never know they were vulnerable anyway, even if the story was on the front page of every newspaper. Unless their machine is set up to automatically check for and install AV and security upgrades, the machine is proably already compromised. If it is so set up, they are covered.
Meanwhile, the script kiddies (as opposed to true criminal hackers) will never be the wiser until the AV updates and patches have already been out for quite a while, and therefore most if not all responsible users are protected.
Ignorance is curable, stupid is forever.
..., but if a vendor like Microsoft takes six months to a year to fix a flaw ...
Now, I'm not the Microsoft apologist of Slashdot, but I mean can we at least throw the names around of some other extremely bad abusers of this "sit on exploits/bugs and fix when we feel like it" policy?
Oracle and Cisco should also be admonished for their response time to fix exploits/bugs disclosed to them as well. Cisco and their Black Hat convention fiasco proves that MSFT isn't alone and really shouldn't be singled out (I don't want to debate the Lynn bug as being new or not).
Also, let's not forget that Zotob was patched before it was released in the wild, but users and admins failed to apply these patches in time even after SANS had raised the alert level to yellow the day before (and I don't want to argue about "we can't just blindly patch our machines", etc.)
Definitely, Linux, mySQL, Apache, the PHP CMS and forums community seem to be highly responsive to security threats and definitely, MSFT makes some very buggy, insecure software, but some impartiality would be nice every now and then.
Hagrin.com
At the very least, I believe in full disclosure to the company that writes the software- but public disclosure opens up too many risks- yes, someone else may find it, but I really don't think that Microsoft purposely leaves out fixes- they have lots of fixes to put in, and they have to prioritize them. Yes, if it is public, it gets higher priority, but they have finite resources to investigate the fix, find it, fix it, and then test to make sure that they don't break anything else.
I think that what the open source community fails to realize is the huge amount of effort that goes into testing. I used to work for one of the big computer manufacturers- (rhymes with Hell), and the software that is released on a system (my experience is with servers) is usually frozen months in advance so that the different phases of test can pound on it, not just so that they can find errors, but so that they can characterize those errors. The fix for a critical error may be done in a day, but the testing may take weeks- to test with different hardware, system software, amount of RAM, HD, different processors... the list is long- but ultimately what they are trying to make sure is that a fix for one thing doesn't cause something else to break in a worse way. This is particularly important when you are maintaining code someone else wrote- you may not fully realize why it was done that way... until it is too late.
Unfortunately, the IP issues often force companies not to reveal what they are doing. Every single person I worked with was extremely conscientious about their work, they take flaws very seriously, but remember, their priorities are not the same as yours, and if you could see the scope of what they are working on, you might be able to better understand why their priorities are where they are. On the other hand, they don't know you from Adam, and you might just be one of those black hats- so they can't reveal the HUGE GAPING HOLE they just found, to show you that they really do care about the tiny (but significant) hole you found.
The answer is massive class-action lawsuit. Consider the following scenario. A manager at Microsoft badgers his employees in order to hustle an Internet software program out the door. The product is now flawed and open to attack by worms and viruses.
Now picture the one at fault to be Joe Blow working from his basement during his "free time" outside of the 65 hour work week at his real job. Class action lawsuits like this would kill open source completely.
Now, here's where the improved security occurs. The customers who bought the flawed product initiate a class-action lawsuit against Microsoft and win $10 billion from the company. Microsoft then fires the manager who forced his employees to hustle a product to completion. The manager of that manager is also fired.
Or Joe Blow is now in prison, is fined an amount he can never pay, his credit, business, and everything is ruined. End users who could have received a patch if it wasn't for that "damned lawsuit happy group being so pushy on time limits" are left with an end-of-life broken product. Don't be so hastey to criminalize the innocent. Too many laws and lawsuits these days do just that.
Just another perspective....
Two roads diverged in a wood, and I - I took the one the bus load of girls just went down.
The Openswan project is directly affected by this this month. We were contacted by an agency and asked to sign a non-disclosure agreement, following which they would tell us of a possible vulnerability in our code. This non-disclosure would prevent us to release details of the vulnerability until such time as the rest of the "group" would be ready for it to be announced.
In the case of an Open Source product, we cannot even do a "stealth" fix; we have to describe what each patch does when we commit it to CVS. That would make the vulnerability public and would be a no-no to this agency.
In essence, the agency could decide which bug we could fix and which ones we could not.
I see this as the equivalent to blackmail: Sign our non-disclosure and we will give you a possible vulnerability; don't sign it and you will look bad when the vulnerability is made public.
I am a CISSP, and quite willing to hold on the patch until others can fix their code if the allowed time is reasonable, but the non-disclosure is broad and has no time limitations... So what the heck should we do ?
I use OpenBSD too, so don't start with me.
How can you be happy when someone else is suffering? It's not your grandmothers fault she uses windows. OpenBSD is NOT appropriate for "home users", and it's not designed to be, and it cannot ever be as secure as it is yet as functional as required for non-power-users.
Every operating system in use on PC's has security issues, even openBSD. OpenBSD is where it is because it's entire focus is security/correctness.
Security and correctness are NOT the most important aspect of general software development - if they were the only requirements, then a lead box buried in the ground would easily be more secure than openBSD. The issue is functionality vs security and correctness.
When there is something that works as well as windows for what people that use windows need to do, but has fewer problems, people will change to it in droves. For some people, that is Mac OS - although it has its own severe security problems - do you laugh when people with macs have to reboot their machines because of SoftwareUpdates ?
In any case - 0 day full disclosure hurts the majority of computer users. No amount of pain will convince them to stop using windows. If you want people to stop using windows, develop a credible alternative. Don't sit and laugh at people that don't have better choices available to them, and then say things like "i support people making life harder for windows users".
My opinions are my own, and do not necessarily represent those of my employer.
I have actually been in the middle of this before, having found a way to passively grab billing information from a larger online subscription-based game. A colleague and I built a complete technical description of the issues, theoretical "worst case" possibilities, as well as a working proof-of-concept exploit, making it clear that we would wait for a suitable fix to be in place before we would release details. We got an email back within several hours from one of the lead programmers who wanted to do a conference call but when we agreed, we never heard from him again.
We were then contacted by a manager-type that this 2-year-old hole was already being fixed. We offered our expertise to review their solution but they weren't interested. Instead, 2 special agents from the FBI showed up at my work to interrogate my involvement in felony extortion.
After a 4 hour long interview session (during which I was escorted to the restroom and watercooler by an armed agent) and I provided all correspondance and source code, they left and never came back. The best part the WTF? look I got when I described how this company was transmitting credit card information XORed with a cleartext seed transmitted in the previous packet. Second place had to be the "Why are we wasting our time here?" look I got when I explained the only credit card information I have actually seen was my own.
The hole was silently fixed in a patch distributed weeks later, and replaced with another algorithm which was also easily exploited. Again, we went through the entire process of creating documentation and a working exploit and sending it to the company. This hole was patched months later.
The company's response was always hostile at best, which I found odd considering we were trying to help them protect their customers. They never disclosed (publicly or to the credit corporations providing merchant accounts) that there was any issue.
American Express has an extremely specific policy on security, and have a minumum requirements policy which all online merchants are supposed to adhere to. They also require you to notify them if security has been compromised. California law also states that card holders must be notified if their account information may have been compromised. Apparently it's not a big deal if noone abides by these rules.
When the company is unresponsive in resolving security flaws, I feel that disclosure is imperative to allow users to take their own precautions to protect themselves. I'm not malicious, but I imagine that there are a lot of people smarter than I am that are.
Say a new DMCA law is enacted that makes it illegal to disclose security flaws. Consider that companies can now fire all but a few of the people involved in security patches and boost profit. How many security flaws do you think will get fixed? How long after a worm is released since staff has been reduced?
Say that a new law (along the lines of collusion) is enacted that makes it illegal to only disclose to a company and not to the public since you are putting the public at risk by withholding information... thus helping said company. How many security flaws do you think will get fixed?
If I buy a bike lock that can be picked with an ordinary pen do I want to know about it? Will the company that makes it do anything until everyone knows?
The best security is to inform all users once a flaw is discovered. The users can then take their flawed web clients, flawed routers, etc. off line. That action immediately prevents the problem.
Though I suspect you intended to imply here that the "information" supplied to the users should contain a detailed description of the vulnerability, let me just point out that a vendor could just as easily send out a notice stating that a critical vulnerability was just discovered, and provide mitigation instructions.
This certainly gives the black hats enough information to start probing the impacted service but doesn't go so far as to turn the event into a race (thereby rushing a riskier short-term patch instead of allowing the vendor to produce a well-tested one).
Its software programs will be bullet proof.
Another thing to think about:
100.000% reliable software costs exponentially more than 100.00% reliable software, which costs exponentially more than 100.0% reliable software. Companies cannot make a profit if they have to eat those costs, so they will have to be passed on to the purchaser.
Given the choice between two vendors' products, that effectively do the same thing:
1. Costs $1,000, took an extra 5 years to finish (and is thus 5 years behind the times), but is guaranteed to be "bug-free" (if there can ever be such a thing); versus
2. Costs $50, integrates the latest technologies, but is riddled with bugs that will impact all of its users at some point, including some security vulnerabilities that will impact some percentage of its users and requires its users to install patches once a month.
Which do you think is going to be more successful?
If a particular model of microwave oven had a design fault which could cause the magnetron to turn on while the door was open, the manufacturer would have to deal with it straight away {and not in six months' time with users dropping like flies}. If a particular model of gas boiler had a design fault and could explode or leak water under exceptional circumstances, the manufacturer would have to do something about it {and not try to silence the person who tried to warn the world about it}. If a particular model of car had a design fault where the throttle would open wide or the brakes suddenly try to engage, the manufacturer would have to respond {and not try to pretend that the problem did not exist}.
It should be no different with computers. If there is a security flaw, the vendor should act immediately to do something about it -- first warn users that the problem exists, and then get to work on eliminating the problem. And this should be done as soon as possible.
The Open Source community generally responds immediately to security reports. Closed-source vendors should not be allowed to use secrecy to get away with selling an imperfect product. I believe that software suppliers should be held accountable for their products -- either by making the source code available for inspection {hence moving it more into the realm of goods supplied in kit form, where the purchaser has some input into the construction and therefore some responsibility for the eventual performance -- like using longer screws and adding extra bracing to a piece of flatpack furniture}, or by offering a guarantee of performance if they insist to keep it secret.
It's also important to remember that (1) good guys outnumber bad guys and (2) if you discover something, the chances are that someone else has already, or is about to discover it.
Je fume. Tu fumes. Nous fûmes!