Tag Archives: bounty

Does “Research” Terminology Reduce Adoption Rates?

What is your reaction to this tweet?

In the drive to “do something,” many applaud this as a reasonable step. I think it actually might harm our efforts and slow our progress.

Words matter.

Does the use of the term “research” reduce adoption rates vs. if we used the term QA or QC?

What is wrong with the term security research? Why might QA or QC be a better selling point?

Consider how businesses handle “research” versus quality assurance/control. In most cases, businesses have budget for quality work. They recognize the importance of producing to the level of quality expected in the marketplace.

The role of QA/QC is one of trust. Partnering together to produce a better product. A way to protect the company while growing the bottom line.

Research is a confusing concept. It either harkens back to grade school papers, college projects, or huge corporate investments. And in the corporate world, research is tightly controlled and wrought with failure. The hope is a small amount of success to make up the difference.

Research is about the future. Quality is about the current state.

Confusing the opportunity: security research

Security research is not well understood. Not even within the “research” community – Bug Bounties refer to their testers as “researchers”, “bounty hunters”, etc.Combining two expensive, confusing terms together creates additional barriers and hurdles.

Where does it fall within the budget? Is it a security item, an application item?

Does this make security testing or research bad? No. It highlights the fact that when working with an organization, perception matters.

When you approach an organization regarding security testing and approval, are they more apt to go with something that sounds familiar, they understand the value, and fits their model, or go with an option that is often interchanged with “hacker”, and they really don’t understand the value? You hear all the time how different groups need to speak the language of their consumer. While I am not a fan of the idea of all these different languages, I do think that using terminology that is familiar to the consumer provides a better connection and opportunity.

In this case, you are selling testing services. These are QA/QC services to offset the internal testing they are doing, while adding a specific focus on a limited classification of bugs. Would changing our terminology change the adoption rate?

I would love to hear others opinions on how they think choice of terminology affects adoption rate.