A large part of my role here at Set Solutions is to work with our vendor partners to get to know their technology. I have been working a lot in the last several months with companies focusing their efforts in the “Sec” portion of the DevSecOps space. I’ve noticed something interesting – and somewhat concerning – during these get-to-know-you sessions: there are often significant gaps in the feature sets from one company to the next who are trying to solve the same issue.
I understand that the DevSecOps space is very broad and solving for the security portion of that space is going to entail a ton of different features. I am not talking about the entirety of DevSecOps, however. I am talking about companies who are working on a very particular part of DevSecOps – API security as an example – and have gaps in their features and focus.
The First Step in Avoiding a Gap is to Know of Its Existence
So why do I think this feature gap is a problem? Let me get into it by telling a story of a recent customer interaction. I was talking with the customer about the current trends in the API security market. The primary person on the call was responsible for overall API security for his organization, and he was very interested in an API security solution that had a strong discovery and asset management feature set, as well as anomaly detection capabilities. Because he had overarching responsibility, he needed to get a handle on the company-wide problem of rogue APIs created by shadow IT and any attacks against those APIs, and I advised him on a few vendors that I thought were strong in both areas.
He also brought in one of his own AppSec/DevSecOps SMEs with a development background and a much smaller scope of API security to handle. He had responsibility for just a few workloads with a lot of integrations between them with well documented data paths and workflows, and those workloads were well contained from outside attacks. This limited scope meant that he didn’t need discovery or asset management, and his interest in anomaly/attack detection was reduced compared to the gentleman mentioned above.
What he was interested in was a developer-friendly API security tool that integrated in the IDE to provide quick feedback on secure development practices, as well as something to help with API documentation (think Swagger/Open API). As I talked to him, he told me of an API security vendor that he had spoken with that he felt met his requirements. I had heard of this vendor, but it was not one I had looked at closely.
As I dug into the vendor’s feature set and spoke with some technical folks there, I realized that the customer was correct. This vendor was very developer-friendly and obviously approached the problem of API security from a development-first angle. It was a strong feature set, but they had very little in the way of discovery, asset management, and attack detection. Essentially, it was missing heavily on the security and operations side of the problem.
Of course, that made me look at the vendors I had been focusing on up to that point, and the answer is yes: they were missing heavily on the dev side. There was very little – and sometimes no – thought to helping the developers code more securely. And while those tools did a good job of documentation of the APIs, they really didn’t compare that documentation to the actual code to make sure the instructions and functionality matched up (another dev-friendly feature).
All of that may not seem like a big deal. Two vendors with different features. What’s the issue? That’s an easy answer: the customer can very likely only buy one of the vendors because they are technically solving for the same problem, even if they have a pretty big difference in their feature sets. Vendors are categorized for good reason, and both vendors are going right into the API security bucket. And while they can try to position them as complimentary and get both, they do have some overlap in features that are going to cause complications.
Also, if you have ever heard me talk about the cybersecurity budget pie, you’ll know that the further you split up the pie, the smaller each piece gets. In this case, the customer has a cybersecurity budget which is split into several pieces, one of which is the AppSec budget. So, if you’ve already split up the cyber budget piece of the pie for AppSec, and then you have to API budget comes from AppSec budget… you see what I mean. With cybersecurity budgets already being undersized for many companies, the pie is already small before it starts getting cut.
This same issue is popping up with other application security vendors, and it can cause budgeting problems. Some companies to go with more of a platform vendor so they can cover more gaps, but those established companies sometimes have fewer features than the startups. This happens because they either bought a startup and have not integrated them completely into their platform, or they built the tech themselves and haven’t made as much progress due to their attention not being focused on one product.
If you are looking at a DevSecOps type of product (or any product that is solving for a fairly new problem), you need to make sure you do extra diligence in vetting them out and determining how they are solving the problem. Ask them about current features, watch demos closely, and do proofs of concept. Create a good list of features that are important to you and grade against those (our solution architects can help you with that, BTW).
I also suggest you do one thing that a lot of companies don’t: Ask to talk to a product manager. They know future direction of development, and they will often share roadmaps (with all kinds of caveats attached, of course) if you will sign an NDA. That information can help you decide if you can wait for a feature or if you need to move to someone else.
If you can wait overall, sometimes that is the best choice. Eventually some of these vendors will merge or develop the features you need. But if not, try to plan for potentially getting multiple products that solve for the same problem but are different enough to be complimentary. Document your reasons for making the choice, make the best case you can, and hope for the best!
My “Research” Project
BTW, I also did a mini research project to test out my hypothesis that the professional backgrounds of the technical founders of vendors have a big influence on where the focus their features. I think it is obvious that if you give two people from different walks of life a problem to solve, chances are good that they will approach the problem differently. So, while I listened to their pitch, studied their different use cases, and watched demos, I also listened for certain terms or concepts that might give a clue to how they approached the problem. Then I tried to match that up with the backgrounds of the technical founder(s). What I came up with is this graph:
To briefly explain the graph above: (1) the blue “Perspective” line is my impression of the founder(s) based on what I gathered from my time with them; (2) the orange “Actual” line is the background of the founder(s) based on their LinkedIn profiles; and (3) the legend at the top left shows what number represents what are (“dev”, “sec”, or “ops”).
Here’s what I learned from that exercise:
- I am not a data scientist
- That was a pretty unscientific “research” project
- I like graphs
But seriously, I found the project interesting, and I think some decent clues came from it. While I only got 60% correct, the time I spent trying to determine whether I was right about backgrounds lining up with feature sets gave me some clues as to why the products were built with certain features and focus. And I think it’s a good point to think about for anyone trying to do analyses of vendors in order to make a decision on which one best fits their organization’s security stack.
***
This blog was written by Michael Farnum, Chief Technology Officer with Set Solutions