The security a buyer
can recognise.

A supplier can spend more on security and still lose a sale to a product with more visible features. Research on software markets asks how buyers’ choices, vendors’ incentives and the allocation of responsibility fit together. A practical question follows: what evidence makes a security improvement recognisable before the purchase?

The choice behind the product

My conference paper Software, Vendors and Reputation: An Analysis of the Dilemma in Creating Secure Software was published in the 2011 proceedings of INTRUST 2010. Its public abstract examines the economic allocation of software-security costs and liability. It argues that customers weigh features, price and risk, so additional security expenditure does not automatically produce a more attractive product. It also challenges the inference that weaknesses in particular vulnerability-market models discredit market arrangements themselves.

That is the paper’s stated economic argument, rather than evidence that every customer has complete information or that every market produces adequate protection. The discussion below develops a separate procurement example. Its numbers and proposed evaluation are illustrative; they are not empirical results from the paper.

A feature can be demonstrated. A risk reduction needs an account.

Imagine a small manufacturer comparing two inventory applications. Both track stock and produce the required reports. One offers a convenient forecasting screen. The other devotes more engineering effort to isolating customer records and testing the boundaries between user roles.

The screen can be demonstrated during a sales meeting. The isolation work is harder to observe. A buyer may see the same clean interface whether the boundary underneath it has been carefully tested or merely asserted. If the sales process supplies no way to distinguish those cases, the supplier that did the additional work has a commercial problem as well as a communication problem.

It would be premature to conclude that the buyer does not value security. The buyer may value it but lack credible evidence of the difference. Alternatively, the protection may genuinely be less valuable in that buyer’s use case than the competing feature. A third possibility is that the purchasing employee receives credit for a quick deployment while another department bears the consequences of an incident. These explanations suggest different remedies and should not be collapsed into one story about careless customers.

What has to change the decision?

Consider a deliberately simplified, one-year comparison in arbitrary monetary units. The additional protection costs 600 and forgoes a feature worth 400 to this buyer. Suppose a specified adverse event would impose a loss of 100,000 on the buyer. Ignore other differences, risk aversion and discounting for this illustration.

The added cost is 1,000. Under an expected-cost rule, the protection breaks even if it reduces the event probability by one percentage point: 100,000 multiplied by 0.01 equals 1,000. A credible two-percentage-point reduction would justify the choice on these assumptions; a half-percentage-point reduction would not.

This arithmetic has not estimated either probability. Its useful output is the evidence question. Does the offered protection address that event? Is the loss figure appropriate to this deployment? What supports a reduction large enough to cross the buyer’s threshold? Replacing an unsupported claim of “better security” with an unsupported decimal would leave the original problem intact.

The threshold also changes when the deployment changes. An application containing only test inventory is different from one holding customer identities and production credentials. A product comparison should therefore describe the protected operation, relevant configuration and loss boundary before attaching a value to the security work.

Make the evidence specific enough to compare

A useful supplier demonstration could ask whether an ordinary warehouse user can retrieve another customer’s records, change a role without authority or continue accessing a record after that access is withdrawn. The buyer and supplier would agree the test conditions and expected refusals in advance. The record would identify the application version, configuration, test method and unresolved limitations.

A successful test would establish what happened in that exercise. It would not establish the absence of every vulnerability or supply the annual incident probability in the numerical example. The benefit is narrower and still substantial: the buyer can inspect evidence about an actual capability instead of comparing adjectives.

NIST’s Secure Software Development Framework, version 1.1, offers a complementary reference. Its 2022 publication describes high-level practices for reducing software vulnerabilities and their consequences, and a shared vocabulary that purchasers can use when communicating with suppliers. That vocabulary can organise questions; a declaration that a supplier follows it is not, by itself, a measurement of this product’s risk.

Let reputation carry a record

In the hypothetical procurement, I would ask for a history that distinguishes discovery from repair. When was an issue reported? When was the affected behaviour reproduced? What changed, and what check established the result? Was the customer told which versions remained exposed? Those dates describe a response more precisely than a general claim of responsiveness.

A raw count of reported vulnerabilities would be an inadequate ranking. One supplier might invite scrutiny while another makes reporting difficult. One product might be used in more demanding environments. A comparison would need to state its observation period, reporting arrangements, exposure and severity criteria. Otherwise, rewarding a low count could reward weak observation.

The point is to give a reputation claim a connection to conduct that another party can examine. The buyer should also know what happens after purchase: which support period is included, how corrections reach the installation and who is responsible for applying them. A promise that depends on an unperformed customer action needs to identify that dependency.

Test whether the evidence earns its price

A follow-on study could present otherwise comparable purchasing teams with the same product options, varying whether security claims arrive as general assurances or as scoped, inspectable evidence. It could record choices, willingness to pay, questions raised and how accurately participants understand the limits of the evidence. Random allocation and a fixed product description would help separate the information treatment from differences in the products themselves.

Such a study would test purchasing responses in its stated setting. It would not establish that the chosen product prevents incidents in operation. A later operational evaluation would need its own exposure measures, follow-up period and account of changes after deployment.

The original software-market question remains useful because it connects engineering work to the choices that fund it. My extension here is to make the information boundary explicit. Before deciding that security cannot compete with features, ask whether the customer has been given a credible way to recognise what the extra expenditure buys.