Dr Richard Clayton might be a whiz "in theory" but in practice he is mistaken. Consultants/Vendors rarely do work for which their Clients do not want to pay. Consider 2 paths:

1) The Client is very insistent on all manner of testing, including security testing but the Client's own technical staff advises, "It will never be an issue".

2) The Vendors is contacted to consult with the Client and the Vendor is insistent on all manner of testing, including security testing, but the Client finds great expense and no real value in it. The Vendor is thanked and sent packing.

Scenario 1 is outright laughable for a few reasons; a) this scenario will never happen, and b) if the Client were to stress the importance testing the Vendors would pick up more business from the Client.

Scenario 1 implies the Vendor would be saying something we never hear them say; things like, "I don't like money", "get that cash away from me", "I can't stand the idea of more funding", "no, please, no more".

Scenario 2, on the other hand, happens so frequently that we all have our own polished rebuttals. However a proper Vendor would hire adequate testers and they should, at very least, advise the Client of the risks involved with not performing various aspects of testing post-implementation.

a) if this advice was not extended to the Client, the Client should now be reconsidering their relationship with the Vendor. This is a good time to lawyer-up.

b) but then there is the most common route: the risks were communicated to the Client and the Client dismissed those concerns outright. At this point the Vendor should have gotten the Clients views on security testing in writing with their signatures thereby exonerating the Vendor of any wrong-doing or lack of performance in the area of due diligence.

3) Let's consider a third option though, the Client purchases the software and never consults with the Vendor. Certainly we could not expect a Vendor to contact each and every Client that purchases their wares in order to make sure each Client is happy. Here, the Client should be ordered, by whomever, to sit in their own poopy diaper.

4) And the fourth option; Client and Vendor are sitting around a table both agreeing, in a language that only businessmen can speak, to ram a project through to completion. Testing is burdensome and represents a great deal of cost to both parties. Everyone implicitly nods at one another in agreement that testing is important and not to test "too much". This happens most of all.

In this case, as in all cases like it, if a mediation body were to read the contract, assuming there is one, and weigh those terms against the advice of an outside software expert (like Stefan Jaskiel, Rick Craig, etc) it would likely reveal negligence on both sides of the relationship, however great or slight.

Conclusion: Here it seems both the Client and the Vendor didn't perform proper testing. Any good comp-sci professor would stress the importance of testing - on both sides - as much as possible and as often as changes are made.

But, the question of a broad measure to remove any/all developers right to waive any responsibility for security flaws in their software would ultimately result in companies having to hire their own development teams (full-time with salary+benefits) and having to write their own in-house software. These companies would have to if development Vendors were looking down the barrel of a law suit every time they made a release. More importantly a company like the one described above would only find themselves in the same predicament again, only this time at the hands of their own staff.

A better approach would be for Vendors to fully learn their business, write contracts accordingly, and have fail-safes along the way, like offering consulting services when Clients want to implement their software and getting a Client's signature when they opt-out for security testing.

When it all boils down, Vendors should be the experts, not the Client; for human cooperation to work at all we all need to be adept in our given fields. To change the scenario a bit, what if the Client were buying an vehicle? Is the buyer expected to be an expert mechanic?

It is the Client's responsibility to partner with the vendor in order to avoid problems like this. After all, who would know the internal workings of a clock more than the person who constructed it?

Assuming that all software problems are not new, it is a 70 year old profession after all, it would behove Vendors to draw from some software standards in order that they get closer to being true "professionals". Here is some light reading to start:
Software Reqs. Eng. IEEE 29148
Software PM Plans IEEE 16326
Testing Definitions IEEE P29119-1
Testing Process IEEE P29119-2
Test Documentation IEEE P29119-3
Test Techniques IEEE P29119-4

These standards, and there are many more, are documented and approved via review board comprised of experts, in order to keep simple mistakes from happening over and over. Vendors will ignore these standards at their own peril.

Software Development might be a great creative release and has the potential to make piles of money but, make no mistake, it is a serious business. Given the availability of the above standards, it's a pity that simple mistakes have to be repeated at all.