The Million Dollar Question: To Build or Buy for Security Tools?

When a large enterprise is looking to invest in improving the process and automation, the question of Build vs. Buy comes up more frequently than you would imagine. This is a decision that will have a significant impact for years to come and is a tough decision that the management needs to make.

While most of the cases I have encountered personally have been around application security tools, specifically SD Elements as a security requirements management tool, the arguments are valid for all productivity and automation tools.

In short, there are only two valid reasons to even consider a build option:

  1. You are in the business of selling the tool, i.e. you have the customer base and it fits with the core business
  2. The tool you need does not exist and nobody is building anything close to it

We have seen many cases of a build decision gone wrong and the most popular reasons are:

  • Relies on a single person: The lead engineer that was passionate and spearheaded the project left the company and project died off.
  • Significant effort cost underestimation: The estimates that are put together initially are frequently too conservative and do not consider the overhead costs and many other complications associated with building the product. The original plans and estimations are usually good (correction: marginally good) for a proof-of-concept initial product, it fails to account for:

* Performance at scale: What happens when 10,000 users are using the product or the data size is considerably larger and the pages take 2–3 minutes to load?

* Updates: A product that is not updated is for all intents and purposes, dead. Many organizations incur significant costs just to keep legacy environment (e.g. old linux distributions) alive since they have an internal product and no one to update it.

* Usability: Internal products often fail to invest on usability, which results in difficulty in traction with end users and loss of productivity.

* Maintenance aspects: Updates, backup capabilities, audit trails and logging, data migration capabilities between versions, etc.

In summary additional costs associated with the aforementioned items can easily add up to 3–5 times the original cost estimation that was valid for the initial proof-of-concept.

  • Difficulty securing resources: It is generally harder to get the development talent in the company to focus on internal productivity products that are not aligned with core business. Specifically once it is past the initial PoC stage, the interests die off and the work is no longer attractive to keep the talent.
  • New competition: It is generally harder to abandon internal tools when a new product comes to the market, even every logical comparison supports the decision for the switch. This results in emotions running high and organizations staying with less productive and more expensive tools.

Keep in mind that when a tool/product is a core business of a company, the cost of updates, new improvements, usability features and others are shared among all the customer base. If the product is a good fit, or even a close enough fit, it is best to build a custom solution on top of the tool rather than build a new tool.

Previous Article
BSIMM Mapping
BSIMM Mapping

The Building Security In Maturity Model (BSIMM) is a descriptive model of software security programs. BSIMM...

Next Article
Don’t Trust Your Plugins
Don’t Trust Your Plugins

WordPress security, or the lack of it, isn’t really a new concept. There are dozens and dozens of posts and...