Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Organizations are still increasing their use of low-code/no-code (LCNC). But this adoption isn’t always consolidated around one tool—frequently, multiple low-code/no-code platforms are used under the same roof. In fact, Gartner predicts that by 2024, 75% of large enterprises will be using at least four low-code development tools for both IT application development and citizen development initiatives.
Utilizing multiple low-code/no-code platforms simultaneously introduces some security concerns. This is partially due to a lack of standard policies to govern different platforms in the same way. Low-code platforms are often incompatible with traditional IT security processes, like vulnerability scanning, manual code reviews and runtime security monitoring. Organizations going all-in on citizen development need safe ways to use low-code/no-code platforms. So, how can they safely enable this innovation without hindering productivity?
I recently met with Michael Bargury, CTO and co-founder, Zenity, about securing LCNC systems. Bargury, who oversees the OWASP Low-Code Top Ten list, has significant insight into both the benefits and drawbacks of low-code/no-code platforms. Below, we’ll review the potential risks of using multiple low-code platforms and consider ways to mitigate these concerns.
Why Companies Have Multiple Low-Code Platforms
Interest in low-code has been rising, and low-code/no-code adoption continues to accelerate across enterprises. According to Bargury, large enterprises often don’t get a choice in the matter—low-code tools are arising organically, and it’s challenging to keep a lid on their proliferation.
One way this occurs is that low-code becomes embedded into the SaaS platforms everyone already uses. Software platforms integral to business operations, like Salesforce, Microsoft Office and ServiceNow, have arguably mutated into low-code platforms, making them more like cloud providers than SaaS vendors, said Bargury.
The other way low-code platforms emerge is through bottom-up transitions, says Bargury. This could be a specific knowledge worker working in a subset of the business to automate a domain-specific operation or integrate various tools. Then, there are the platforms, like OutSystems, Mendix or Mulesoft that specifically target professional developers.
Organizations going all-in on citizen development may build a center of excellence and focus efforts on a single platform. And low-code platforms targeting developers will sometimes encourage more consolidation. Yet, “different platforms solve different use cases better,” explained Bargury. As a result, you will usually have a few converging in the same enterprises.
Potential Security Concerns of Multiple Low-Code Platforms
The emergence of low-code is similar to the bring your own device (BYOD) movement. IT and security leaders fought to avoid it at one point, but nowadays, everyone does it. So, what are the security implications if low-code becomes similarly ubiquitous? Well, no matter how it’s generated, low-code-bred programs are still applications susceptible to the same logical problems. And unfortunately, compared to your typical traditional code development life cycle, low-code development is fraught with discrepancies, says Bargury.
Immature CI/CD Pipelines
Some platforms do not offer the kind of mature CI/CD process one would expect from a software development platform. For example, there may be no way to create tests or separate your environments. Since there’s no coherent and consistent way to push code from development into production, you lack a way to apply secure development across platforms. “You don’t have a way to ensure every piece of software is up to your standards,” said Bargury.
Opaque Underyling Codebases
In traditional software development, you apply your own security reviews to ensure applications don’t contain risks. This includes shift-left scanning, security gates, manual reviews to catch mistakes early on and runtime scanning to catch unknown vulnerabilities in production. But there aren’t always parallels in low-code development. Low-code solutions typically have their own way of doing things with fewer standards, and they avoid exposing the underlying code and Git, said Bargury.
Lack of Visibility
As such, with low-code obfuscation, you lose a degree of visibility into how an application runs. Logs may be insufficient or wholly inaccessible. It’s also tricky—or at times impossible—to set up runtime monitoring, let alone scan various platforms. This means that low-code users can’t leverage powerful observability tools to identify errors and remediate security holes.
Lack of Unified Policies
Finally, establishing common authorization and permissions across multiple low-code development platforms is another hurdle. Since low-code vendors have their proprietary building blocks, you’re unable to leverage something like OPA or Kyverno to create and unify policies. Lacking shared policies across tools makes it challenging to verify that best practices have been implemented, says Bargury.
How to Secure Multi-LCNC
Low-code can grant much creative potential. But, knowing the above risks, what should IT be doing to reduce risks around low-code—especially when using multiple platforms? Well, Bargury shared several steps to help cybersecurity leaders start safely addressing the emergence of increasingly low-code capabilities.
- Take low-code development under the application security umbrella. First, low-code must be brought under the security umbrella, if it isn’t already. “It should be part of their mandate,” said Bargury. Shift the responsibility to professionals well-trained in resolving threats.
- Understand your surface area. As a basic security tenant, you can’t secure what you don’t know. Thus, Bargury recommends increasing your visibility into each low-code platform by collecting logs when possible and centralizing your analysis.
- Create automated guardrails. Next, it’s critical to identify your risks and set guardrails for your low-code users—especially when citizen development is involved. The OWASP framework provides a good overview of common risks and mitigation advice across robotic process automation (RPA), integration and low-code. In general, it’s important to design permissions with the rule of least privilege in mind. This can help reduce the chance of vulnerabilities like LCNC-SEC-03: Data Leakage and Unexpected Consequences and LCNC-SEC-01: Account Impersonation.
- Address gaps within the development life cycle (SDLC). Lastly, low-code platforms often provide the building blocks to secure applications, but it’s still up to you to ensure they are safely used. Cybersecurity teams should continually audit the low-code SDLC to ensure holes don’t persist.
You’re Responsible for Securing Low-Code Development
Low-code development platforms aren’t 100% safe from harm. It’s not out of the question for hackers to abuse low-code platforms and turn them against their owners. For example, Microsoft’s Detection and Response Team (DART) reported how a hacker group used entry to a low-code tool to remain hidden within an organization for six months, using credential stuffing to access an administrative account. By creating automations, they were able to use internal discovery tools and exfiltrate secrets and data that could have been used for privilege escalation.
As you can see, there are legitimate concerns for low-code, especially at scale. However, security responsibility is not always that transparent. To date, there isn’t an equivalent of a shared cloud responsibility model in the realm of low-code development. As such, at the end of the day, you need to take the reins to own the applications that you build and ensure everything is secure.
