A large organisation spends millions of ringgit on a cybersecurity platform. The purchase is not made casually. There are months of evaluation, technical assessments, architecture discussions, commercial negotiations and approval processes. The product is eventually selected because it promises stronger protection, better visibility and lower cyber risk.
Months later, a critical vulnerability is announced.
The same organisation that paid for the technology must now mobilise its own people to understand what went wrong. Engineers check affected systems. Security teams review exposure. Operations teams prepare emergency changes. Management asks for updates. Auditors may want explanations. If there is any indication that the vulnerability has been exploited, incident-response activities begin.
The vendor publishes an advisory and, eventually, a patch.
The customer does almost everything else.
This situation is so common in technology that very few people stop to question it anymore. Vulnerabilities are treated as part of normal operations. Products receive CVE numbers, advisories are issued, patches are tested and systems are updated. The cycle is familiar, organised and well understood.
Yet there is a more basic question underneath all of this: when a weakness originates in the product itself, why does the customer carry so much of the cost of dealing with it?
That question becomes particularly uncomfortable when the affected product is itself a cybersecurity product.
A firewall is purchased to reduce exposure. An identity system is introduced to strengthen access control. An endpoint security platform is deployed to detect attacks. A VPN protects remote connectivity. A privileged-access platform is supposed to reduce the risk of administrative compromise.
But each of these products is also software, and software can contain weaknesses.
There is an irony in that. An organisation may buy a product to reduce its attack surface, only to discover later that the product has become part of that attack surface.
This does not mean vendors deliberately release vulnerable software. Modern technology is extremely complex. Products depend on millions of lines of code, third-party libraries, operating systems, cloud services and external components. New attack techniques also appear over time. It would be unrealistic to expect software to be completely free from defects.
But complexity should not end the discussion.
There is a difference between accepting that software can fail and accepting every failure as simply unavoidable.
Some vulnerabilities are subtle and difficult to predict. Others come from familiar problems such as poor input validation, insecure defaults, weak authentication logic or unsafe components. When the same types of weaknesses repeatedly appear in mature products, customers are entitled to ask whether the problem is truly unavoidable or whether speed, cost and market pressure have been given greater priority than security assurance.
This is where the economic side of the story becomes interesting.
Software companies are rewarded when they release new capabilities. Features can be demonstrated. New functionality can be marketed. Product roadmaps can attract customers. Sales teams can use them to differentiate one platform from another.
Security quality is much harder to see.
A secure design does not always create something obvious that can be shown in a product demonstration. A vulnerability that never appears does not become a marketing headline. The business value of preventing a defect may remain invisible.
By contrast, the commercial benefit of releasing a new feature is immediate.
That creates an unusual imbalance. The benefit of shipping quickly can be realised by the vendor today, while the cost of a weakness may only appear years later, after the customer has already invested heavily in the product.
By that stage, changing the technology may no longer be simple.
Enterprise products rarely operate in isolation. They become connected to identity services, networks, cloud platforms, monitoring systems, automation workflows and business processes. Employees are trained to use them. Procedures are built around them. Contracts may run for several years.
A customer may therefore discover that replacing a troublesome product could cost as much as implementing it in the first place.
The result is dependency.
The customer patches the product, accepts the disruption and continues using it.
Then another vulnerability appears.
The process repeats.
What is rarely captured is the true financial cost of this cycle.
The original price of a product is easy to see. Licence cost appears in a contract. Implementation cost appears in a project budget. Support fees are predictable.
The cost of failure is much less visible.
It includes the people who investigate advisories, the engineers who test emergency patches, the downtime required to deploy them, the additional monitoring introduced as a precaution, the meetings held to discuss exposure, and the hours spent explaining risk to management, auditors and regulators.
If exploitation occurs, the cost increases dramatically. Investigation, containment, recovery, legal support, regulatory reporting and reputational damage can quickly exceed the price of the technology itself.
Perhaps organisations should therefore stop looking only at Total Cost of Ownership.
There may be another number worth measuring: Total Cost of Failure.
A product that appears cheaper during procurement may be far more expensive over its lifetime if it repeatedly demands emergency remediation and operational attention.
This also raises a broader question about the cybersecurity market.
When organisations face new risks, the usual response is to purchase more technology. New threats produce new products. New regulatory expectations produce new platforms. New attack techniques create new categories of security tools.
Every additional product may solve a genuine problem.
But every additional product also creates another dependency, another management interface, another privileged account, another software component and another possible vulnerability.
The security industry therefore exists in a curious position. It sells technology to reduce the risks created by technology.
And when that technology fails, another part of the same industry often appears to manage the consequences.
Security vendors sell protection. Vulnerability-management companies help discover weaknesses. Threat-intelligence providers track exploitation. Consultants assess exposure. Incident-response firms investigate breaches. Insurers price the financial impact.
There is nothing inherently wrong with any of these services. Organisations need them.
But together they create an ecosystem in which insecurity generates economic activity.
That is perhaps the most uncomfortable part of the story.
Cybersecurity has become a very large global industry because cyber risk continues to grow. Companies invest because they are genuinely trying to protect themselves. Vendors build products because there is real demand. Security professionals work every day to prevent serious harm.
At the same time, it is difficult to ignore the underlying economics.
More vulnerabilities create more work.
More breaches create more demand.
More complexity creates more products.
More products create more dependencies.
And more dependencies create more things that must eventually be secured.
None of this proves that anyone wants the problem to continue.
But it does create a question about incentives.
If one organisation earns revenue from selling a product, while another organisation carries most of the operational consequences when that product fails, should responsibility be distributed differently?
Should vendors provide stronger guarantees around secure development?
Should repeated preventable vulnerabilities influence contract renewals?
Should customers expect more transparency about root causes?
Should procurement teams examine vulnerability history as seriously as they examine features and price?
And should the cost of emergency remediation be treated as part of the commercial relationship rather than simply as the customer's operational problem?
There may be no simple answer.
Software will continue to have vulnerabilities. Customers will still need strong vulnerability-management programmes. Vendors will still need responsible disclosure and rapid patching processes.
But perhaps the industry should become less comfortable with the idea that this cycle is simply normal.
Because normalisation has a strange effect. Once something becomes routine, people stop asking whether it should be happening so often in the first place.
The cybersecurity industry has become extraordinarily good at detecting, reporting, patching and managing product weaknesses.
The more difficult question is whether it has become equally good at reducing the number of preventable weaknesses entering products at all.
That is where the discussion becomes bigger than CVEs, patches or security advisories.
It becomes a question about responsibility, incentives and economics.
And perhaps there is one final thought worth leaving on the table.
Whenever one group suffers, another group somewhere often earns money helping to fix the problem.
That does not automatically make the business unethical.
But whenever someone can profit from somebody else's suffering, it is always worth asking whether the incentives are truly aligned with making that suffering disappear.
