One can argue that taking a risk is part of doing business. Indeed risk taking is a business choice, one that cannot and should not be stopped. But there is a major difference with intentionally taking risks, assuming risks must always be taken, or not knowing when risks are being taken.
When a business must make a constrained choice, it may take a risk to try to achieve a desirable objective. When any risk is intentionally taken, the stakeholder must be willing to live with any negative outcome if the risk should manifest as a problem. If the stakeholder is not willing to live with the problem should it manifest, the risk should not be taken, it should be controlled. These types of risks would be categorizes as chosen, understood, and appreciated when taken. The possibility of a downside is included in the taken risk. These risks are not avoided, but are managed to minimize the business impact.
Not all risks should be taken! Too often a risk is taken not knowing that there is a simple, practical way to avoid the risk. The worst possible risks are those not understood, seen, or appreciated by the stakeholder. These risks are not managed. The stakeholder does not even know that they are taking a risk. The downside is not anticipated as a possibility, and when it manifests, the risk taker says, “Well, that’s the way it is.” Well, it is not!
Today in software, the state of poor and unacceptable quality is still too often a problem. We have improved. We have processes that when implemented lead to desirable solution delivery for both the customer and the provider. We know how to deliver good quality solutions, on time, on budget, and which address the expected customer requirements.
But it is not always so. Why? Mostly because the software provider does not know or does not appreciate that application security testing by design is critical. Software can be produced at lower cost, leading to a more competitive position for the provider, and to higher customer satisfaction which in turn leads to repeat business.
We as users of software may be part of the problem. We are too forgiving when we encounter defects. It is simple to reboot when a problem on a personal computer occurs. It is a nuisance or sometimes worse, but we reboot and press on. We all know when a new release of PC software hits the streets we will encounter defects. The suppliers even admit there are defects. Yet we users buy because we want the new function. We can’t wait, and in turn we motivate poor practice by the suppliers. We need to become more demanding and with some suppliers this is an absolute must. The suppliers need to learn how to produce better software solutions, because it is possible. They can start by implementing best practices such as CMM & take inputs from the open community available on the net such as OWASP and using books.
