Edition 9: A build v/s buy framework for AppSec
Edition 9: A build v/s buy framework for AppSec
Incorrect buy v/s build decisions can have serious downstream impact on security posture and team morale. This edition builds a framework that can help that decision making easier.
Buy v/s build is not an AppSec specific problem. If you work in an ops-first organization, “buy” decisions are the default for most software projects (security included). In tech-first companies, the instinct is to “build”, but for non-core projects (i.e. software that does not bring the company revenue), there is always a temptation to buy as well.
There are a few factors which are unique to Security teams thouugh (not just AppSec):
Core goal of security teams to stop external adversaries from compromising your systems. You need intelligence about these external threats. Think threat intel feeds, SAST rules for weaknesses in programming languages, software patches and so on. It is difficult for a single company to “build” this feed and you have no option but to buy these (note: I consider relying on open source feeds only as a “buy” decision that costs $0. It has all the same features of a “buy”, except the cost)
Traditionally, security teams were filled with network engineers or IT auditors. Neither of these groups have the necessary skills to build software solutions. This is changing quite dramatically with the advent of the Security Engineer. But if you are one of those old-school teams, you don’t really have a “build” option
Bad build v/s buy decisions can have adverse impacts. However, this impact isn’t always acknowledged due to what economists called the Endowment Effect (i.e. we have an emotional bias that causes individuals to value an owned object higher, often irrationally). Here are two examples of bad build v/s buy decisions
Buying to de-risk: "Blaming the vendor" is a shameful practice in our industry. Far too many security teams "buy' solutions (can be services or products) simply to de-risk themselves from negative outcomes. Failed the audit? fire the contractor! Had a breach? find a vendor to sacrifice! This is a terrible reason to "buy" instead of "build".
Building for vanity: Have you wondered why there are so many open source projects which do pretty much the exact same thing? A popular one I have seen in AppSec is tools which collate results from a bunch of other tools and publish results on an HTML page. In many cases, this wasn’t built because no other option was available. This was built and published so the team could participate in Security Theater. Being part of the theater is important, so nothing wrong with that, but I wonder what the opportunity cost of doing this is. What else could have been done with these resources if the team used an available open source alternative instead?
There is no magic formula on when to buy and when to build. It is however easier to calculate the opportunity cost of "buy" (given the solution provider has done the heavy lifting defining some of the cost) compared to "build". So, here’s a hypothesis on how to make a build v/s buy decision:
Assume all solutions should be built. Then ask 3 key questions which will challenge those assumptions. If any of the assumptions fail, change the decision to “buy”. The questions are:
Is there a turnkey solution available to this problem?
Is there value in having an “outside-in” perspective to solve this problem?
Is there significant security risk in involving a 3rd party to solve this problem?
The framework
Let’s get in to the 3 key questions:
Is there a turnkey solution available to this problem?
Many security problems are common across companies. Things like a SAST tool, a vulnerability management platform, 3rd party penetration tests for compliance and so on. The industry has done a decent job at building turnkey solutions for some of these problems. So, to start with, investigate if there are plug and play solutions available.
If they are available, we should then calculate the total cost of the solution. This includes cost of onwership and cost of maintenance. A thing to watch out for is that teams often underestimate the cost of maintenance. Breaking them down into sub-items which considers all kinds of costs is important (example below)
If turnkey solutions are not available, then estimate if your team has the skillset to build this solution in the timelines budget & demanded by the project. If the estimate is hard to determine (happens often for complex projects) or if you are clear the skillsets don’t exist, then it maybe best to work with a 3rd party who can build this custom solution for you.
Is there value having an “outside in” perspective?
This one is intuitive. Often, security projects involve verifying if your program is working. In such projects, an outside-in perspective is invaluable. Think maturity assessments, red-teaming exercises and so on. In some large enterprises there maybe multiple security teams which can act as “external” to each other. But in all other cases, it is imperitive to “buy” a solution.
Is there a security risk in involving a 3rd party in this solution?
Working with a 3rd party will involve sharing some amount of data with them. The trade off between convinience and parting with your data (e.g.: source code) needs to be measured. When I started in AppSec a decade ago, security teams were stricklers when it came to sharing data. All deployments had to be in-house, all contractors/consultants had to use company laptops and so on. It’s fair to say that Security teams are skeptical about most new things (rightly so. Being skeptical is part of the job description :) ) and hence, the change to SaaS solutions has taken longer than expected for security solutions.
That’s a round about way of saying the answer has now swung in the direction of “buy”, as solution providers provide seemless ways to use their solutions, without sharing sensitive data. A great example is the evolution of SAST offerings. Traditionally, AppSec teams spent a lot of time in deploying and maintaining big-box SAST tools (not our core competence). With modern tools like CodeQL and Semgrep, deployment is essentially one-click, you don’t really share your code with any additional third party and you are able to spend your time in the right areas such as customizing the SAST tool to meet your org needs.
What next?
Like most frameworks, this one is meant to be a compass, not a GPS. A general “this is north” guide and not “turn by turn directions”. Here are some things to keep in mind as you use the framework:
The decision making is oversimplified in the framework. The answers to the big 3 questions (and the sub-questions) are rarely yes/no. They are often “maybe” or “not sure”. If you can change those answers instead to “leaning yes” or “leaning no”, you may get better value from the framework
The framework only work if you have a crisp, output driven problem statement. If your problem statement lacks details and clarity, the framework will fail. Defining the problem properly is key. How to do that? Well, that’s for another edition :)
That’s it for today! Are there more questions + sub-questions to consider while making build v/s buy decisions? Is there another framework that works better? Hit me up! You can drop me a line on twitter, LinkedIn or email. If you find this newsletter useful, do share it with a friend, colleague or on your social media feed.