No- and low-code security
How to speed up development while still deploying securely.
Low-code and no-code tools are all the rage these days.
Whether it’s building an online marketplace or multiple one-man businesses, an array of powerful offerings have allowed non-developers to build advanced workflows.
Similarly, individual employees within organizations regularly use code to build scripts and miniature apps that automate a variety of activities within the enterprise (e.g. continuous integration/continuous delivery and issue prioritization). A new set of offerings promises to streamline their development and deployment.
These are all excellent developments in terms of productivity and value generation, but, as with most technological advancements, they are already outpacing cybersecurity guardrails.
It is good to see that OWASP has created a “top 10” set of risks for no- and low-code and at least one vendor is marketing a product to address them, but anecdotal evidence and industry research suggests few have even started to tackle the problem. As an example of the latter, 32% of respondents to one survey said there “is no governance over how these applications are accessing and using our data.”
Thus, I would say that organizations must develop a framework for how to use no-code/low-code/in-house code tools securely. Your top concerns should be:
To what data does (or could) the tool have access?
What is the security posture of the underlying platform?
How does my organization govern the use of the tool?
The first two are really just stand-ins for a business impact analysis of a traditional third party such as a vendor. I would recommend checking out this article for a deep dive on how to conduct such an analysis, but there are some unique considerations for low- and no-code tools. I’ll dive in below.
To what data does (or could) the tool have access?
The answer to this is usually “at least as much data as the individual using the tool has access to,” but there is a scale factor here that is important to consider. For example, a user accidentally (or maliciously) sending an email to an unauthorized address with a single sensitive record could cause serious but finite damage to an organization. The same user setting up a Zapier workflow to automatically send out such emails every time a record in a database is updated, however, would cause many orders of magnitude more damage.
This is a tricky problem to address, as users will necessarily need access to certain types of data and might potentially even need to send sensitive information outside the company network (e.g. to a partner under NDA). User education will be the first line of defense against this problem, as simple errors are likely to be the biggest threat to an organization’s data in this case. User and entity behavior analysis (UEBA) technology can also help to spot errant or malicious workflows or no-/low-code tool implementations.
What is the security posture of the underlying platform?
As for the security of the platforms themselves, it will be interesting to see how organizations treat applications built on no-code platforms. Some of the latter have achieved security certifications and list out their data subprocessors, which is a good start, but doesn’t quite build a full risk picture for a consumer. Having a detailed understanding of the security of the platform’s application development and operational practices will allow those using them to better understand the risks involved.
Furthermore, effective SaaSBOMs - of which CycloneDX is the only common format - will need to start reflecting the use of no- and low-code platforms in the “top-level” application. Such SaaSBOMs will become extremely complex, as the product with which the end user interacts will comprise various levels of components and services stacked on top of each other.
How does my organization govern using the tool?
This is probably the most critical piece.
As mentioned previously, the likelihood and severity of accidental or malicious impact to data confidentiality, integrity, or availability are substantially higher when using a tool like Zapier, whose catchphrase is “Integrate, Automate, Innovate” than it is when employees are emailing data around.
Similarly, a “citizen developer” building a web application for internal use may forget (or not know how) to require authentication on the front end, accidentally exposing it and any underlying data to the entire internet.
Thus, user education - including in secure development techniques, even for non-developers - will be an important first line of defense. Clear policies and automated safeguards that govern the use of these tools will also be critical. Most importantly, enterprises that don’t have clear and relatively friction-free processes for getting approval to use these tools are going to face some combination of the following:
Innovation within the organization will slow due to the inability to deploy these platforms rapidly.
The security team will lose visibility on the risks they pose because people will just them anyway, without permission, to accomplish their daily tasks.
Automation (potentially even using no-code tools) will be the only way to address this paradox. If employees can be confident they will get rapid approval (or denial with a valid reason) of their requests, they will be more likely to follow the process. If, however, they need to enter into a Kafkaesque security review (or no such process even exists), they will either not pursue use of (potentially value-generating) tool or not bother seeking permission at all.
Conclusion
No- and low-code development platforms look to be the next frontier of technological advancement. I suspect that they will eventually become another commoditized layer of enterprise technology stacks, similar to how Infrastructure-as-a-Service offerings (e.g. AWS, Azure, GCP) did for storage and compute. Such IaaS products now have well-developed shared security models and no- and low-code platforms should follow in their footsteps.
Security teams should also avoid defaulting to “no” or creating byzantine review processes when employees seek to use them. By both enabling increased productivity and managing the associated risk of these tools, security professionals can fulfill their role of allowing organizations to deliver value while at the same time protecting that value from mishaps or attacks.
This article was inspired by Jerich Beason’s LinkedIn post and Chris Hughes’ article.