The idea of low-code/no-code (LC/NC) application development seems to be extremely popular nowadays, to the point of it almost becoming a marketing buzzword similar, say, to “Zero Trust”. For decades, creating “proper” application software was a complex and tedious process that required qualified professional developers to produce even the smallest app. Organizations only had two choices: either purchase an existing off-the-shelf product from a software vendor or commission an internal or external development team to design, code, test, and deploy a custom application. Well, that or write an Excel macro…
LC/NC strives to change this dichotomy by offering a third choice: let business people build their own custom apps just by using a graphical design tool, choosing from a library of existing building blocks, or maybe even let artificial intelligence do the heavy lifting. The users, or “citizen developers” as they are now called, would only need to provide their domain knowledge, with no coding skills required.
In theory, the idea is great: every accountant, doctor, business analyst, or HR employee should be able to solve their small daily problems of finding the right information, doing a small calculation, or automating a back-office task without the need to involve software developers. There are so many potential use cases for LC/NC solutions and so many opportunities for software vendors to attract new customers with their citizen development offerings!
Do not trust the label!
Unfortunately, the market for these solutions is still in the very early stages of maturity – the diversity of products being sold under the “low-code/no-code” label is astounding. Anything ranging from sophisticated integrated development environments and robotic process automation platforms to glorified scripting tools and even chatbots – anything passes for LC/NC nowadays. This makes finding the right tool for a specific use case very difficult and, of course, only further increases the danger of Shadow IT – having an uncontrolled zoo of low-code tools in an organization is just as dangerous as letting your employees use unsanctioned cloud services.
However, the security and compliance implications of current-generation low-code platforms are much larger than that. First of all, “proper” software developers do not just write code. They are responsible for the full life cycle of their applications, from early design to implementation, operations, monitoring, fixing bugs and vulnerabilities, and, last but not least, protecting apps from attacks and preventing security breaches.
Low-code platforms must be able to implement all these capabilities, but even better than traditional software platforms because the customer simply does not have a team of citizen DevOps engineers and citizen security analysts. Even the largest enterprises that do have such teams at hand usually don’t plan to involve them in their citizen developer projects. After all, the biggest selling point of such projects is that business people can use them directly, without relying on their colleagues from IT.
Unfortunately, most solutions currently available on the market seemingly do not focus too much on these challenges, as some of the recently discovered problems indicate. Just a few days ago, multiple data leaks were reported in Microsoft Power Apps – a popular suite of apps, services, and connectors, as well as a data platform, that provides a rapid development environment for custom business apps.
The dangers of "shadow citizen development"
Although the platform provides a number of tools to enable user authentication, configure access permissions for tables that hold data, and so on, these controls were not enabled by default, leaving many apps created by customers completely exposed to anonymous access via the Open Data Protocol API. Since all customer apps are hosted on subdomains of the same domain and the API endpoint address is fixed, the security researchers were able to quickly discover hundreds of affected companies and over a thousand lists with sensitive data such as passenger contact information, healthcare records, and even Microsoft’s own internal business data.
This particular data breach was quickly contained but who knows how many others are waiting to be discovered? Similar past problems with the likes of Amazon S3 or MongoDB clearly show that if a database or service allows making sensitive data public, it will eventually happen again and again, most commonly through negligence and misconfiguration, but sometimes by the hand of a malicious insider.
And if this can happen to a seasoned IT expert, how can we expect every citizen developer to be able to secure their data properly? Potential privacy implications of letting non-technical (and non-legal) people decide which data should be put into a no-code platform and who should have access to it might be massive, too. After all, citizen developers are just as likely not to understand international privacy regulations like GDPR as they are to have no clue about security principles.
Also, let’s not forget that one of the most popular usage scenarios for a low-code platform is combining and analyzing data from multiple external sources – for visualization, reporting, or automation, for example. If a custom app can be easily breached through such a trivial vulnerability in the underlying LC/NC platform, it will essentially turn into a massive security hole, potentially letting hackers pivot to and breach multiple other IT systems.
Choosing the right low-code/no-code solution
What should customers do to avoid such problems? Even before they decide to adopt the citizen development methodology, they have to carefully incorporate the idea into their existing security and compliance policies. They have to consider all the potential challenges and carefully evaluate the risks of “shadow citizen development” as well.
When choosing the best LC/NC solution, one should understand that the market is nowhere near maturity yet, and available capabilities can vary dramatically. There will probably never be a single product that can address all potential use cases, but again – business people alone should not be allowed to decide which tools (and to what extent) to use just based on their needs. All such tools must be carefully vetted by security and privacy experts, and proper constraints and policies must be established for their usage. Needless to say, access to any sensitive systems and data sources through a low-code platform must be controlled, secured, and generally treated as untrusted.
If an LC/NC platform comes with its own data platform, it must be secured to a higher standard than other enterprise databases, not a lower one. All the security and compliance controls for a database used by citizen developers must work at least as efficiently as for other sensitive data sources, but in addition, they must be fully transparent, not user-serviceable, and always on.
And, of course, creating an app in a modern low-code/no-code environment should be at least somewhat more convenient than writing an Excel macro. Otherwise, nobody will bother to use it.