The low code/no code movement provides simplified app generation – but it needs to be understood to be safe.
We are struggling to satisfy the demand for new software – the laborious effort of writing code has become a bottleneck to innovation in general, and being first to market in particular.
In other areas of business, such problems are being solved through automation. Automation applied to code generation leads to the concept of ‘low code/no code’; that is, the automatic generation of software requiring little or even no direct human coding. The question is whether this concept will be a genuine boon to secure app development, or just a promise full of hidden landmines and booby traps – like open source software has proved to be.
We’re going to examine the concept, use, advantages and disadvantages, and the security implications of this evolution.
Concept
“The concept of low-code/no-code isn’t new,” explains Steve Wilson, CPO at Contrast Security; “but the definition isn’t very specific either. For decades, most computer programs have been written with text-based programming languages – aka code. The resulting ‘source code’ is then ‘compiled’ into the code a computer can execute. This is true for most apps that run on back-end servers, desktops, and even mobile phones today.”
Low code/no code environments are introducing a higher level of abstraction, often using concepts like drag-and-drop icons and data flow diagrams. “In other words, visual programming rather than textual. Alternatively, low-code environments may mix visual programming with small bits of textual code, often referred to as ‘scripts’ or ‘functions’ to allow the developer or user to mix the benefits of visual and textual concepts.”
Ryan Cunningham, VP of Power Apps at Microsoft described the Microsoft product. “Low code/no code platforms like the Microsoft Power Platform,” he said, “use AI, automation, and ‘what you see is what you get’ tooling to make it easier to create applications, data visualizations, workflows, chatbots, and websites more efficiently than traditional ‘code-first’ software development.”
Use
The application of low code/no code is expanding, and there is no single sentence nor use case that can categorize its potential. Broadly speaking, it falls into apps or workflows, or apps with workflows.
Eoin Hinchy, CEO and co-founder at Tines, has a low code/no code platform designed for security personnel. “Security teams face a major problem: there’s too much work and not enough staff,” he says. “More specifically, overworked staff are doing repetitive and mundane tasks, which not only leads to burnout [more likely, ‘rust out’, see Burnout in Cybersecurity – Can It Be Prevented?] but to human error that could cost a company millions.”
This can be solved by allowing the teams to develop their own scripts to automate workflows. But “Security analysts don’t necessarily have coding skills,” continued Hinchy, “so, they’re forced to call in developers, which can take weeks or months to create integrations and deploy automations. Then, if an update or addition is needed, the analyst needs to get developers involved all over again.”
His argument is that no-code automation allows frontline security analysts to independently automate time-consuming, mission-critical workflows: “like phishing attack responses, suspicious logins, and even employee onboarding and offboarding. Using a drag-and-drop interface, users place actions into a workflow, connect them together, enter parameters, test it, and set it loose.”
Automating workflows is just one of the uses for low code/no code concepts. Richard Rabins, CEO and co-founder of Alpha Software, sees the core technology of his platform frequently being used to develop mobile and web apps that combine with data collection workflows.
“The most common use case,” he said, “is replacing paper forms with a mobile app for collecting data. For example, you may have an inspector who examines bridges. That inspector used to enter details of the inspection on paper, but now the inspector uses an app on a tablet.” Rabins’ product can build that app from common building blocks since the requirements of data collection are often similar.
“In some cases,” he continued, “the bridge will be fine and all that is necessary is to set the date of the next inspection and file the report. Often, however, further action will be required. Repair work may be necessary, so the process needs to kick off a further workflow.” This workflow can also be generated by his app, demonstrating a low code/no code use case combining a stand-alone app and workflow.
Ryan Cunningham sees a much wider capability. “More than 7.4 million monthly active developers are using Power Platform to build standalone low-code apps, automations, websites, and dashboards. These developers range from audiologists and former bricklayers to dedicated software professionals who have found a new way to work faster and more efficiently.”
The point to note from his comment is that you don’t need to be a developer to produce new apps – you could be a sole trader or small business with no IT staff, and yet still generate you own proprietary apps. But if you are a professional developer in a larger organization, you can work faster and more efficiently. In short, low code/no code brings skills to the unskilled, and efficiency to the professionals.
Advantages and disadvantages
“The top two benefits of low code/no code are speed of delivery and opening it up for ‘business users’ to self-service and develop workflows that meet their needs without needing to engage with IT. However, this is also the biggest potential pitfall,” comments Mark Lambert, VP of products at ArmorCode.
Reed Loden, VP of security at Teleport agrees. “I’m personally a big fan of low code/no code,” he says. “These types of products have made code integrations really easy, making certain actions possible that would have taken a typical developer a lot of time to complete.”
But there are both pros and cons, he continued. “The pros are that developers can quickly make integrations that are super useful for cybersecurity. For example, it can create an interaction that detects an alert and automatically remediates a problem, without any human intervention required. The con is that these types of tools require a lot of access, so if they are compromised, it can be really bad for the customer.”
Cunningham, describes the movement as a democratic force: “This technology changes the traditional development landscape by making existing professionals more productive and at the same time democratizing software development for a wider range of users.”
Allowing professionals in a professional environment to be more productive is good. “It decreases the risks associated with either one-off software projects or the ‘shadow IT’ alternatives that many business users will turn to without any other viable solution,” he adds.
But the same democratizing process could increase shadow IT. In one area it could help a small business develop personal apps to improve internal operations and workflow. This could be good or bad depending on the security of the app’s usage.
But it could also persuade an employee in a large organization to by-pass the IT department and produce his or her own personal automation tools. “Giving the power of development to non-developers,” comments Nick Rago, Field CTO at Salt Security, “also presents another security risk in regard to shadow IT, even if the endpoints are intended to be ‘internal only’. We have seen far too many breaches where attackers gain inside or privileged access to internal applications and APIs.”
Lambert adds, “Simply put, we need a defined process for deploying low-code, no-code into production environments; and have guardrails to ensure that, if any issues are present, the potential damage is limited.”
In fairness to Cunningham, extensive guardrails are present in the Microsoft product. “The Power Platform is built upon all the security and governance capabilities Microsoft is known for,” he comments, “and makes it possible for IT departments to require standard guardrails around app development and data access. Administrators can build guardrails around data, applications, and environments.”
The problem is that once a new technology is in process, it cannot be contained. We are seeing this with AI and generative pre-trained transformers (GPTs) such as ChatGPT – democratizing the use of AI leads to its personal use outside the built-in guardrails of the developer. With low code/no code, individuals not wishing to be constrained by the IT department will likely turn to third-party platforms to produce their own shadow ITapps, outside the purview of the IT department’s official guardrails.
Just as the web created the citizen journalist, so is low code/no code creating the citizen developer — with similar concerns. The output and the connection between subject and output both increase, but the accuracy and quality of the output needs scrutiny. It may be that the democratization of app development — at least for corporations — should be considered more as a potentially worrying side-effect than an advantage of low code/no code.
“One of the advantages of low code is that it allows non-developers to build their own applications,” says Jeff Williams, CTO and co-founder at Contrast Security. But he adds, “There is also a con in this as citizen developers are more likely to make inadvertent mistakes that could lead to security issues. I would expect citizen developers will make a lot of the basic mistakes such as hardcoded and exposed credentials, missing authentication and authorization checks, disclosure of PII, and exposure of implementation details.”
That said, if the process can be constrained to the professional IT department, more and potentially more secure code can be produced faster – and that alone will drive increasing adoption.
Ernest Lefner, CPO at Gluware – a firm that offers no-code process automation for networks – sees six primary advantages in the low code/no code movement. These are faster innovation, lower costs and improved efficiency, customer-focused delivery, less risk, greater control over intellectual property, and standardization.
“The biggest pitfalls of a low code/no code strategy,” he says, “revolve around adoption and culture. Large scale organizations have a myriad of processes that were created specifically to avoid well known problems. Many of those problems no longer exist when you are employing automation for 90+% of your delivery. In many cases organizations try to retrofit low/no code solutions with all checks and balances of an over bloated delivery process and significantly increase the complexity of how you automate.”
Nevertheless, insists Mark Lambert, VP of products at ArmorCode, “Just because anyone ‘can’ create something, shouldn’t mean they should. Programming is inherently difficult. This is why it’s a profession. It’s why people have degrees in computer science. And why we’ve developed processes to ensure software is delivered that is both reliable and secure.”
“If the platform is well designed and is generating code that’s secure, that’s a Good Thing,” says Mike Parkin, senior technical engineer at Vulcan Cyber, “but it may also potentially introduce idiosyncrasies or vulnerabilities that a threat actor could leverage. Overall, though, the low/no code platforms offer more advantages than not.”
Security implications
“Low code solutions are often considered more of a black box where developers may not have full control over how the underlying system is used, making it difficult to ensure the security of the application,” warns Jason Davis, VP of product and applications at Sauce Labs. “This can have implications as engineers don’t have control over network security, server configurations, security policies, and use of third-party services.”
Cunningham is a firm believer in the potential security of low code/no code. “A well-managed low code practice significantly decreases security concerns by standardizing application delivery on a robust platform with secure best practices built in… Companies can set granular data loss prevention policies to apply across low code environments.”
But Davis adds, “Vulnerabilities such as those achieved through inadequate input validation, insecure user input handling, or backdoors allowing unauthenticated access are always a concern.”
Rabins believes the security concerns are more in the use of the finished app, than the building blocks of its generator. Firstly, the generator is developed by experts with a security first approach. Secondly, it is under constant overview of security experts. And thirdly, since it is a cloud-based platform, any concerns can be immediately addressed and corrected for all future customers.
But he adds, “Any software that gets written has massive security implications. An app could be sending nurses to take care of patients in their own homes, and it collects sensitive medical information.” Here, it is not so much the security of the app’s code, but the security of the app’s usage that needs to be considered.
This is the primary security issue: the democratization of app production puts the ability into the hands of individuals who may have little understanding of cybersecurity and compliance regulations.
To complicate matters, those individuals or sole traders could be a component of your supply chain. Williams, however, doesn’t feel we should over-stress security concerns. “The risks are essentially the same [for all software]. Authentication, authorization, injection, encryption, logging, libraries, etc. There are slight differences with every application framework. And low/no code is no different.”
Wilson points out, “As with many things in IT, security is a shared responsibility model. What is the user/developer responsible for and what is the development environment responsible for. In a low-code environment, classic ‘vulnerabilities’ such as SQL Injection may not be a worry, and many user-authentication issues may be automatically handled. However, the user/developer may still make logic errors where they pass inappropriate data back to users or store data in insecure manners. In essence, the problems are all still there, but they move around in terms of who is responsible for what. At a minimum, you should thoroughly investigate the security characteristics, tools and practices that are recommended by the provider of your low-code tooling.”
Evolution
“There are still trust issues in putting the fate of the network specifically into the hands of automation. Many network shops still want to keep one hand on the wheel. As we gain trust in the capabilities of low code/no code platforms we should see a lift in adoption,” says Lefner. “Ultimately no one wants to be working on Saturday at 2:00 am anymore. With the automation capabilities we have today, no one should have to.”
He believes this is just the beginning. “I expect to see the proliferation of low code/no code solutions grow in the next to 12-18 months. With the skills in short supply, and the absolute complexity and large failure rates in large scale automation programs, companies are going to need a flexible, less risky way to build efficiencies.”
Like all new technologies, there are concerns in the early days. Cloud-based platforms reduce some of the concerns of low code/no code. Greater understanding of the governance and guardrails necessary to manage the results will come. The advantages without the disadvantages will increase over time.
This is clearly an evolutionary step in the generation of application code. Trying to stop evolution is like standing in front of a bulldozer rolling down the Hill of Inevitability.