On December 1, 2011 a Class-action lawsuit was filed in United States District Court Northern District of California against Hewlett-Packard, alleging violations of The California Consumer Legal Remedies Act for Injunctive Relief and the California Unfair Competition Law based on non-disclosure of a known security vulnerability (read the filing here)
Nature of the Action
l. Plaintiff brings this action individually and as a class action against Hewlett-Packard Company (“Hewlett-Packard” or “HP” or “Defendant”) on behalf of all others who purchased a Hewlett-Packard printer (the “HP Printers”).
2. The HP Printer’s suffer from a design defect in the software (which is also sometimes referred to as “firmware” ) that is resident on the HP Printers, which allow computer hackers to gain access to the network on which the HP Printers are connected, steal sensitive information, and even flood the HP Printers, themselves, with commands that are able to control the HP Printers and even cause physical damage to the BP Printers themselves.
3. Despite Defendant’s knowledge of the design defect in the software of the HP Printers. Defendant has failed to disclose the existence of the defect to consumers
4. As a result of the facts alleged herein, Defendant has violated California laws governing consumer protection.
Regulatory compliance mandates strong-arm organizations to implement control after control at a cost of billions of dollars annually to compensate for inherent flaws, vulnerabilities and exposures in 3rd party software, yet the developers themselves remain largely unaffected by these punitive laws and regulations.
The argument against punitive or regulatory oversight of commercial software development organizations has primarily been that the costs the industry would incur would ultimately result in a significant reduction of innovation. I believe one could just as easily argue that the organizations that spend significant resources on implementing security and operational controls to compensate for inherent flaws in the 3rd party software they purchase are already experiencing a significant impact to their ability to innovate.
Do I think the burden of implementing security controls needs to also be carried by software developers – absolutely!
Do I think we should look for government oversight, laws and regulations to force software developers to adopt security as part of the software development lifecycle – no, but what would be so wrong with something like PCI being completely rewritten so that software developers would have to adhere to a base set of security processes and tools if they want to sell their software to companies that process credit card transactions.
Either way this lawsuit could be the catalyst that launches this discussion into the main stream
Something, something this way blogs 
Definitely watching this case as it unfolds. A few reactions to your thoughts, though…
1. I hear you about essentially holding software developers more accountable, but I would hope that the good ones stay employed and are valued while the bad ones are shown the door. I’m not sure what else is needed, especially when responsibility in an organization moves upward with the decision-making. I’d hate to be a developer who was not given the resources/mandate to do it right, and gets punted because of an eventual issue they couldn’t control.
2. I’m not sure implementing security controls and processes will lead to better innovation. I don’t know *that* many controls that are transparent and easy, or thatt don’t get in the way. In fact, I would argue the very idea of innovation moves ahead of the security curve, which will just cost even more resources to accomodate. Perhaps that should be a blog post in itself, or maybe what you’re saying if you can leave your 3rd party apps (e.g.) vulnerable as long as you have a layer on top (some nebulous layer that magically protects everything like a condom?). I guess, ultimately, I’m not buying that argument yet. 🙂
The rest, of course, you’re spot on!
Pingback: HP Facing Class Action Suit For Not Disclosing Printer Vulnerability | Threatpost