Skip navigation
Padlock open Alamy

Is Low-Code, No-Code a Security Risk to Your Enterprise?

Low-code, no-code platforms are increasingly finding use in the enterprise, but IT leaders should be on the lookout for potential security risks.

Low-code, no-code programming most often comes up in the context of enterprise communications/collaboration — in connection with communications platform as a service (CPaaS) with the promise that anyone can (and should be able to) program new ways to communicate internally, and more likely, externally with customers. While empowering citizen developers can lead to innovative ways of communicating, as with any technology, IT leaders need to do their due diligence to ensure that low-code/no-code technologies aren’t creating unintended security threats that put communications and other systems at risk.

Unpacking IT Security Implications of CPaaS

In a survey of 136 IT and cybersecurity decision-makers, No Jitter’s sister website Dark Reading found that 52% of organizations are implementing low-/no-code technology in some part of their enterprise. However, many professionals have security concerns with their use. Among the top security concerns, 32% of IT and cybersecurity professionals said the lack of governance on how these applications access and use data was a major security concern. Additionally, 26% said they don't trust the platforms used to create applications, and the same percentage didn't know how to check for security vulnerabilities in low-/no-code applications.

A big part of the security risk comes from how low-code, no-code platforms can slip into the enterprise without IT and the security team even knowing (i.e., shadow IT), writes Michael Bargury, CTO & co-founder of Zenity, which provides security and governance for low-code, no-code applications, in an article discussing the Dark Reading findings. Such platforms often “find their way into the enterprise through business units rather than top-down through IT,” Bargury writes. Some platform vendors also allow users to create private applications folders that IT admins can’t access, and some enterprises are using multiple low-code/no-code platforms, further complicating the picture, Bargury explains, noting that, basically, "you can't protect what you can't see."

Another IT blind spot with low-/no-code technologies arises because many of these platforms lack event and logging controls, making it difficult for admins to understand what exactly is going on in the platform, Sorell Slaymaker, principal consulting analyst at TechVision Research, told No Jitter. However, Slaymaker suggested AI can help with logging and can be used to find unusual behaviors or events like “a user downloading 10G of content or sharing sensitive content to external email addresses or accounts.”

To the concerns of overall platform security, a potential risk can come from the APIs low-code/no-code platforms use, as Channel Futures, another No Jitter sister site, shared in this article. Specifically, “APIs are only as secure as the CPaaS platform makes them ... [and] it is critical that those specifications follow API security best practices, such as requiring authentication, and that the API implementation actually matches the specification,” Andrew Howard, CEO of global security firm Kudelski Security, said in the article. To ensure that CPaaS APIs are secure, IT professionals should inspect the specifications and implementations for issues and conduct regular security audits, Howard added.

Let’s Not Forget the Developers

While governance and APIs can be sources of security risks, in a recent No Jitter on Air podcast episode, Microsoft MVP Randy Chapman highlighted a different reason why enterprises might want to be careful with who they task with creating apps — they most likely already have a team in house to do the work.

“If you speak to a developer, they went to school and studied and became professionals at all this,” Chapman noted. Developers have learned proven development frameworks, factor security into their design process, and know how to support the app across its lifecycle, Chapman added.

To the latter issue, Chapman noted that citizen-developed apps might run into issues when the enterprise rolls out the app more broadly or must support it for the long haul. “What happens when the app breaks, and ... the citizen developer doesn't know how to fix it?” Chapman asked.

Not only will enterprises lose time from needing to fix these apps (that might not have broken if designed properly by trained developers), but if the citizen developer leaves the organization, they can take with them that knowledge of the application, Chapman noted. This issue can be true of any application developed in-house (not just those created with low-/no-code platforms), but apps created by citizen developers might be harder to manage and thus require special attention.

Using Low-code, No-code Safely? Focus on IT Security Fundamentals

While acknowledging these shortcomings, Chapman noted that “it is possible to design with a good framework, [and] do something responsibly with no risks and holes.”

One way of securing an environment for low-code/no-code technologies is ensuring that the underlying platform (and your enterprise) support a Zero Trust model that incorporates end-to-end encryption, multi-factor authentication, classification of content, and security controls, Slaymaker suggested. Additionally, enterprises need to invest in proper training for users, and policies should detail proper usage and what would be considered violations, Slaymaker said. “This means getting away from generic training classes and doing [training] tailored to that user and/or group,” Slaymaker added.

As with most technologies, low-/no-code isn’t inherently insecure in and of itself. However, if careful consideration isn’t given to the how — and more importantly, the who — when it comes to low-/no-code technologies, enterprises might find themselves facing security threats that they could have easily avoided.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish