Using no-code and low-code tools to validate cybersecurity product ideas and shorten time to market
Looking at no-code and low-code from a different vantage point
Welcome to Venture in Security! Before we begin, do me a favor and make sure you hit the “Subscribe” button. Subscriptions let me know that you care and keep me motivated to write more. Thanks folks!
Introduction
When we hear the words “open source” and “cybersecurity” in one sentence, it is commonly about the need to secure open source software. While that is fair, focusing on OSS as a source of vulnerabilities alone misses the broader context of the role it plays in cybersecurity. The destiny of the low-code and no-code mirrors that of open source: it is only discussed as an attack vector. However, unlike OSS which has been around for a few decades, low-code and no-code are new, so their mechanics and possibilities are not well understood.
In the context of cybersecurity, low-code and no-code can be discussed as follows:
As a way to build products, including cybersecurity offerings. This will be the primary focus of this article.
As an attack vector. I recognize that securing applications built using low-code and no-code is an important topic. There is a decent amount of knowledge about how to do it right, and there is even a security vendor fully focused on governance and security for low-code/no-code applications - Zenity. Discussing low-code and no-code vulnerabilities is not the goal of this article (although I will briefly touch on it later).
As an approach to cybersecurity designed to make security tools accessible and easy to configure, without having to write code. Examples of companies that embrace this approach are Tines and Torq, which provide no-code automation for security teams, and DoControl, the no-code SaaS security platform. No-code and low-code for security teams are not the main focus of this piece but I will briefly mention it as well.
This piece is in many ways unique. Usually, I talk about topics I have been researching, practicing, or learning about for some time, as well as macro trends I’ve observed on the industry level. This article is primarily based on my discussions with Walter Haydock, CEO & founder of StackAware, who built his product using no-code and low-code tools. I am not affiliated with Walter or StackAware, this post is not sponsored and is not designed to promote what I am sure is a great software supply chain platform. Instead, I will talk about the approach itself - about using no-code and low-code tools to validate cybersecurity product ideas and shorten their time to market. I found this approach interesting and rather unexpected for cybersecurity, which is what compelled me to learn more and share my learnings. All opinions and conclusions are my own and not that of Walter.
Source: StackAware
About “Hipsters, Hackers and Hustlers”, and how most “Hackers” are not “Hackers”
Originally introduced by AKQA’s Chief Technology Officer Rei Inamoto, the idea that every startup needs a Hipster, a Hacker, and a Hustler to succeed has been repeated by investors and startup enthusiasts all over the world. The Hipster is traditionally represented by a designer, the Hacker - by a developer, and the Hustler - by a business founder in charge of product, sales, and the overall go-to-market strategy. While great for consumer products, this approach hasn’t been working as well in B2B where historically, the role of design was less critical. Today, tech investors are commonly expecting to see at least two co-founders: one focused on technology and another - on business.
Cybersecurity is a technical field that demands deep domain expertise. To solve problems in security, one needs to be an experienced practitioner capable of recognizing an opportunity, making sense of technical complexity, and scoping the right solutions. Knowing how the product should work is not the same as being able to build a tool that does work. This is where the problem lies: most software developers do not possess deep knowledge of security, and most security professionals are not software engineers capable of building products. In other words, most Hackers are not Hackers, and even those that are, tend to be much better at doing one thing rather than both at once.
Every startup will be different as people have their strengths and weaknesses, which makes it not reasonable to prescribe how founding teams should be constructed. In many cases in cybersecurity, technical co-founders can handle the business side as well as technology, and later hire someone to take care of sales, product, and operations. However, one thing is true: a security professional looking to start a cybersecurity company, typically has three choices: learn how to code, find a co-founder with background and experience in software development, or outsource development. There is always a possibility that they can raise capital first, without an MVP or having anything built, but in most cases that wouldn’t work unless the founder has a brilliant track record and we can fly back in time and pitch in 2021.
Learning how to code
While it may not take long to learn basic web development and create a simple company site, building products is hard. To be able to architect a scalable solution from the ground up, and assess the trade-offs of using specific technologies, languages, and infrastructure providers, one must have accumulated hands-on experience doing it before. Learning how to debug issues takes time, and so does every other step of software development. This is not to say that a security professional cannot learn how to build products; it is most definitely possible. However, trying to learn how to code so that they can build an MVP while moving fast to get feedback and validate the idea is not productive.
Outsourcing development
Similarly, outsourcing development to a third-party provider is generally a bad idea for an early-stage startup:
The quality of outsourced development is often below average, which establishes a shaky foundation for the new venture, both in terms of technology and security,
Managing outsourced developers is not easy, especially when requirements change, there is not enough time to document everything, and people are working in different time zones,
Incentives of third parties and that of a startup are often misaligned: while the startup is trying to build a product and get to product-market fit, development agencies are interested in maximizing the amount of billable work,
Having developers isolated from customers and the epicenter of insights at the early stage slows down learning and reduces the company’s ability to iterate quickly.
I am not saying that all development agencies are bad, but it would be fair to say that a pre-product, pre-revenue startup that has not received any funding and has not validated its idea, is better off trying to build an MVP in-house.
Using no-code and low-code tools to validate cybersecurity product ideas and shorten time to market
No-code and low-code as a new approach to building software
Up until a decade ago, the most sensible way for a security professional with no background in software development to quickly build a new product was to find a co-founder. While that is still the main option today, there is now another way - using no-code and low-code tools.
No-code and low-code development started at the beginning of the 2000s with WordPress' launch of the ability to build websites without having to develop all components. The movement picked up, and around a decade ago we saw the emergence of new-generation tools such as Squarespace (2004), Shopify (2006), Bubble (2012), and Webflow (2013).
Many see the no-code as a logical next step in abstracting away the hard layers of software development and technology stack. Twenty years ago, the concept of running your software on somebody else’s hardware did not make sense. Then, AWS emerged followed by other cloud providers, abstracting away complex layers of IT infrastructure which enabled the rise of SaaS and accelerated innovation. Today, the majority of new products are built on AWS, GCP, Azure, or one of their rivals. As we see the increasing layers of the technology stack and the task of software development becoming more and more commoditized, the no-code might be the next big shift in the way products and companies are built.
Building unicorn businesses using no-code might seem a bit far-fetched today, but the adoption of tools like Stripe, which arguably can be seen as a low-code billing component, shows that we are moving in the right direction. It remains to be seen to what degree no-code will be able to deliver on its promise, but we don’t need to wait until tomorrow before taking advantage of this new approach.
No-code and low-code can be used by just anyone; a background in application development is not required. The following are some cases when it may make the most sense to explore this approach:
First-time founders trying to learn about their target market, quickly, or explore multiple startup ideas on the side while keeping their employment,
Founders who are looking to validate their idea, value proposition, market segment, and/or customer profile before attempting to raise venture capital,
Founders interested in assessing if their business idea can be venture-scale,
Founders who are planning to take a slow and steady, step-by-step approach to their business from day one instead of looking to move fast and scale.
Advantages of no-code and low-code for cybersecurity startup founders
No-code and low-code tools enable non-engineers to quickly launch new products without having to learn software development. The following are some of the advantages of taking this approach:
For someone new to building software applications, no-code tools can greatly speed up the time to market. While it may take months and years to learn programming, a first version of the working product can be built in no-code in two to three months of full-time work (roughly the time it took Walter to get the no-code/low-code version of StackAware to the early beta users). No code can accelerate development by as much as 4-5x, radically cutting the amount of time it takes to ship working solutions and collect feedback from early customers.
Ability to try different approaches before committing to a specific one. This is important as most startups pivot away from their original idea, or end up developing it in a direction at least slightly different than what they started with. To validate different ideas and approaches, one must be willing to not get attached to the code they built, throw everything away and start from scratch (often - multiple times). Using no-code and low-code tools makes it easier to do as there is less attachment to what’s built.
Ability to build a secure working version of the product. I will briefly discuss the security of no-code and low-code applications later; all software applications have vulnerabilities, and the no-code approach presents some unique challenges in securing them. However, for a self-taught product builder with no co-founder and no previous experience in software development, no-code can be the most secure way to implement their business logic. A modular, lego-like approach of no-code enables people new to application development to abstract away the parts of development they are not comfortable with.
Choosing the right no-code/low-code platform
In the past decade as the no-code movement grew, we have seen tens and even hundreds of platforms emerge trying to capitalize on the new trend. To choose the right no-code or low-code platform for a cybersecurity product from the sea of available options, it’s important to answer a few questions first:
Are you trying to build a throwaway prototype or a potentially production-ready solution?
Are you building a product for people (B2C) or enterprise customers (B2B)?
There is always more but these two questions will filter out the majority of options. To make no-code development easier, it is advisable to select a platform that covers both back-end and front-end. This will make the process easier and will eliminate the need to learn and connect multiple tools. However, if you are building a solution for the enterprise, you will need to have a full-featured API, something that a full-stack platform may be lacking. For consumers, a point-and-click product built using a full-stack no-code tool will generally work well.
To find the right platform,
Consider looking at those that offer a freemium model which will make it easy to try their capabilities for free. Transparent and predictable pricing is important as well so that the cost of no-code does not accidentally become unmanageable.
Test if the product allows you to build auto-documenting APIs, which will save a lot of time down the road.
Look for tools that have a community around them, as well as a solid knowledge base. Currently, StackOverflow does not have much information about building in no-code, so it is especially important to ensure you will get the right level of education and support. Forums, discussion groups, Slack channels, YouTube channels, free courses, and similar is where all the no-code magic happens.
Understand the security stance of the no-code platform you are evaluating. Security practices for no-code and low-code tooling are at their beginning stages. Xano is ISO 27001 certified and in process of obtaining a SOC 2 designation. Bubble is built on Amazon Web Services, which is itself compliant with certifications such as SOC 2, CSA, ISO 27001, and more; the company itself does not appear to hold any security certifications. It is well understood that the presence of security certifications is good evidence of compliance, but not necessarily a strong security posture; it is, however, a starting point for further assessment.
StackAware is built using Xano as the back-end and Bubble as the front-end. Xano offers the ability to build self-documenting APIs in no-code (via Swagger) - a key need for any product targeting enterprise customers. The tool enabled Walter, StackAware’s founder, to keep all the business logic, and sensitive information, and perform data manipulation on the back-end. Xano has a good YouTube channel and is relatively easy to get started with, especially for those with a basic understanding of object-oriented programming (Xano uses the same concepts). Bubble is a no-code platform for full-stack development, but it can also be used as a stateless front-end. Integrating Bubble with Xano enabled StackAware to retain most of the information on the back-end and make the front-end almost stateless, thus reducing security risks.
Source: Bubble
Low-code and no-code tools for cybersecurity
It would be a miss if I did not mention several cybersecurity tools that enable security professionals to build products and automate their operations.
LimaCharlie, a company where I lead product, offers cybersecurity tools and supporting infrastructure billed based solely on usage in a scalable way. This approach enables security professionals to use endpoint agents, detections & response rules engine, and other components of the cybersecurity infrastructure to build their own products on top thus accelerating their time to market.
Low-code tools such as Tines and Torq allow security professionals to automate their SOC operations without having to write code. A different focus, but also the one which could be used to test integrations-heavy product and service ideas.
I anticipate that we will be seeing more and more no-code and low-code cybersecurity products in the coming years.
Risks and limitations of no-code and low-code development
All tech companies have a digital supply chain - API integrations, cloud providers, open source libraries, and other building blocks of modern software. All applications are affected by some risks, and those built using no-code tools are not unique. However, some of the risks do not affect other kinds of software to the same degree.
Security risks
Security of the no-code and low-code solutions is the number one risk raised when this approach to building products comes up. Chris Hughes and Walter Haydock offer a great analysis of the problem and the ways to tackle it. No application is perfectly secure, whether it’s built by in-house engineers, using no-code tools, or by a team of contractors. Arguably, no-code tools, if handled well, can be a much more secure option than outsourcing development to an agency abroad with no ability to review their code, or trying to build the product from the ground up without any experience in development.
When it comes to using no-code and low-code, transparency is key. StackAware, for example, takes a proactive approach with its Security Portal where the use of the no-code and low-code tools is transparently disclosed.
I think the question of security for startups is much broader than the question of no-code, and I have previously discussed how the founder’s desire to get the MVP out as quickly as possible leads to inherent insecurity.
Business risks
Cybersecurity buyers are critical and thorough when evaluating anything they are to potentially deploy in their company’s environment. This is understandable as sharing companies’ data, especially sensitive security telemetry, presents a high risk, and so does integrating any new tool into their existing security stack. A startup trying to break through the noise on the market can potentially face a serious challenge if cybersecurity buyers do not feel comfortable with their no-code approach.
Since the product assembled in no-code “resides” on somebody else’s platform, there is an inherent risk that the platform provider can go out of business, which would then affect anything built on top. Theoretically, the same could happen to any cloud provider, but we see Google, Microsoft, and Amazon, to name a few, as proven and stable companies able to guarantee their existence in the foreseeable future. The same is not true for every low-code and no-code provider: while some, like Bubble (2012), have been around for a decade, others such as Xano (2020), are new and not proven with time.
Another risk is related to the startup’s ability to exit. While I have not been able to find any information about real-life cases, I would speculate that few potential acquirers would be comfortable buying a product built in low-code, unless it was looking to migrate startup’s customers to their own platform. Even in that case, I would imagine the company valuation would reflect a discount because of the risks associated with the no-code approach.
Technology risks
The biggest technology risk is that the tool selected for the job will not be able to handle technical and business requirements. Many of the no-code platforms are not scalable, and those that are, still present a problem where it’s very easy to build a lot of logic, chain functions together, duplicate requests, and make the application slow, and sometimes even unusable.
Closing Thoughts
In a world where technology can be treated as a solved problem and everything except the business logic can be abstracted away, the business idea and the execution of the idea will matter more than the tech stack. With the democratization of technology, today anyone can build their product without having a background in software engineering or computer science which allows for cybersecurity innovation beyond technology.
People starting a cybersecurity company have to be technical but the word “technical” can mean anything; it can be someone who is a security professional, an engineer, or both. A security practitioner may have written some code (maybe, in SQL or Python), but they are often not equipped to build a product on their own, or at least not to do it fast. In startups, and rapidly-changing cybersecurity, timing is everything, so moving slowly means losing momentum. No-code and low-code platforms enable founders with no prior software development experience to get something to the market quickly, gather feedback, validate ideas, and prove or disprove key assumptions. It creates tight feedback loops and allows for rapid experimentation, both of which are critical for early-stage ventures.
There are and probably will be limitations. I do think that given the state of the no-code and low-code market today, it’s best to use this approach to rapidly test new ideas, not to build production-ready cybersecurity offerings (this is where I want to once again emphasize that all opinions are my own and Walter would probably disagree with my conclusion). If there is a burning market need for what the founder is doing, people will accept some degree of risk of using an untested product built in no-code, which can also be a great sign to validate the idea. A no-code/low-code prototype is the best possible wireframe one can give to a developer working on building the application: a user story saying “I want to provide a vulnerability disclosure statement so that I can educate my customer” is not as effective as a working tool.
As with all other ways to build software, there are risks. While I haven’t been able to find any mention of cyber breaches caused by the use of no-code and low-code tools, I am sure the time when we will hear about it is near. However, the presence of risk does not mean that we should seek to eliminate it entirely: going out is risky but we do not normally hide in a bunker. It’s all about understanding what’s at stake and continuously looking for reasonable and appropriate ways to manage risk and reduce one’s exposure.
In the past decade, we have seen that the move to the cloud created a model of shared responsibility for security: a part is handled by the cloud provider, and a part - by the end customer. I anticipate the same will be the case for no-code and low-code, and similar to the cloud, the majority of the breaches will happen due to customers’ mistakes and misconfigurations, and not because no-code is “inherently” less secure. People using no-code and low-code tools will have to learn how to do it securely.
Thank you
A big thanks to Walter Haydock, CEO & founder of StackAware for being generous with his time and sharing his learnings and experience building the company with no-code and low-code tools. Walter has an active blog about building a no-code back-end using Xano and has previously written about no-code security.