Skip navigation
open padlock Getty Images

App Development: Staying Secure Using Low-Code Platforms

While low-code platforms can be more secure than traditional application development, there are still risks. Here’s how to overcome them.

More companies than ever are turning to low-code platforms to speed application development and reduce the burden on IT staffs. These platforms, fronted by a graphical user interface and intended to be easier to use than traditional development methods, are growing fast. According to Gartner, more than 65% of application development activity will be accomplished using low-code environments by 2024.

Done right, low-code platforms can actually be more secure than traditional application development because the platform itself helps the entire development process “shift left.” This works especially well when the IT department maintains control of the low-code platform, putting the right policies in place and ensuring that they are enforced.

“It’s the lowest risk to the enterprise because it’s the most transparent, most governed and most controlled way to develop apps,” said Michael Beckley, acting CTO at Appian. “Any decent low-code platform will give you centralized control over who can access the apps, the automations and the data underneath.”

The Rising Risk of the ‘Citizen Developer’

While that’s an important step toward security, there are plenty of caveats to actually achieving high levels of security and governance. That’s because while IT professionals make good use of low-code platforms, the biggest growth is taking place among “citizen developers”—employees outside the IT department who create applications for others or themselves. According to Gartner, more than 40% of companies have active citizen development initiatives underway, and many more are either evaluating or planning to start them.

While empowering citizen developers is great for productivity, it can make security and governance much more challenging. Developers outside of the IT department are much more likely to “go rogue,” building part of their applications outside of the native tooling of the low-code platform. This can have the effect of actually weakening the overall security of the application.

“When there is a lot of freedom, there should also be lots of control, and that means good governance,” said Andie Dovgan, chief growth officer at Creatio. “It’s a fine line because they might view governance as taking away their freedom, but in mature democracies, you know where to apply the governance.”

The key, he said, is to allow as much freedom as possible unless it bumps up against a boundary that can cause risk. This applies to everything along the way, from data management to connecting with other business processes. This requires having the right security guardrails built into the platform—guardrails that prompt IT staff to adjust security permissions on all objects appropriately.

Another helpful feature is a built-in health check system, which can be set up to automatically check the overall health of the platform and identify any misconfigured or orphaned objects before deployment.

Freedom with Limits

To ensure security for all types of users, make sure to put the right processes and protocols in place. That includes training and certifying citizen developers, conducting routine application testing and reviews, and using permission policies to specify what actions specific users can perform and what data they can access. “Role-based access should be as fine-grained as possible. That’s especially important today, with the proliferation of APIs and data everywhere,” said Mayur Shah, senior director of product management at WaveMaker.

Probably the most important way to use policies is to ensure that everyone working on an application—IT staff or citizen developer—goes through the low-code platform. There has to be a really good reason for going outside the lines, Beckley said.

But even with the right low-code platform and comprehensive policies and procedures, true security can be elusive. Here are some reasons why, and how to overcome them.

Lack of visibility

The problem: With so many cooks in the kitchen, it can be difficult to keep tabs on what’s being built, what resources are being used and whether acceptable processes are being followed.

The solution: One solution is requiring citizen developers to build what they want in a sandbox, accessing only resources available in that sandbox. It’s also important to implement fine-grained controls for viewing, editing and sharing data. The low-code platform itself can make a difference. The virtual data layer in a low-code platform can provide the security control necessary to ensure that only the appropriate people can access the system, Beckley said. “Using the virtual data layer in a low-code platform provides security control to ensure that only the right people can access the system,” he noted. Quality low-code platforms also come with many other security compliance checks built in, such as PCI (for payment), HIPAA (healthcare) and FedRAMP (government).

Another way to improve visibility is having central IT govern onboarding and setup of the platform, along with which artifacts are available to be consumed by each group. That makes everything more manageable, and allows everyone to share and collaborate securely, Shah added.

Business logic problems that could expose data

The problem: While low-code development platforms do include access controls and permissions, they have to be set up properly for developers to create secure apps. But developers—especially citizen developers—can still make choices that can compromise security. For example, a developer may inadvertently allow sensitive data to be posted to a public location.

The solution: Having a managed runtime environment with the ability to automatically reveal where data is exposed and where security controls are not properly applied is vital. With these capabilities, development teams get more frequent recommendations earlier in the process, which allows them to better manage their code reviews and avoid business logic problems that could expose data.

Vulnerabilities via third-party integrations

The problem: Verizon’s 2020 Data Breach Investigations Report found that 43% of all breaches are connected to a vulnerability at the application layer. That’s because security risks increase as developers integrate with external databases, applications, cloud services and other resources. Low-code platforms don’t always natively support these integrations, which means they can’t handle security threats that arise due to these integrations, said Sandy Carielli, principal analyst at Forrester, in a report.

The solution: For these reasons, it’s best to deploy in the same environment as the low-code development platform, Carielli said. She recommends building the required functions using the low-code platform rather than using a third-party integration whenever possible, often by building your own APIs within the platform.

Other vulnerabilities

There are plenty of other vulnerabilities that can surface, even in low-code development environments. For example, applications developed in low-code environments often use

proprietary languages, libraries, frameworks and software.

While the low-code platform’s security protections can help, it’s also helpful to ensure that the low-code platform you choose has a robust set of user interface components so developers don’t have to create their own, examining proprietary libraries for potential risks, testing the APIs that applications are interacting with using an API scanner, and isolating applications and running them in containers. Finally, look for a virtual data layer that enforces data governance policies, along with security policies that protect direct access to underlying data sources.

All of these vulnerabilities also should be addressed by third-party security auditing. This can take the form of automated testing tools like OWASP’s ZAP (Zed Attack Proxy), which can find security vulnerabilities in web apps during development and testing phases. Other useful tools include SonarQube and w3af.

Despite Precautions, Low Code Is Still the Way to Go

There are a lot of reasons to go with low-code platforms, but getting the most value without compromising security requires a change in mindset and approach. The same was true when moving from waterfall to agile project management approaches—it required changes in the language, along with the way teams are deployed, contracts are set up and technology is deployed.

Low code also works best with full collaboration between citizen developers and professional developers. This requires not only choosing the right people to be citizen developers and training them, but setting up the right guidelines.

“It’s about making sure [citizen developers] understand the potential risks related to breaches of security, and training and certifying them correctly,” Dovgan said. “This results in better alignment between IT and business organizations, and can really improve security and governance.”

Finally, there is nothing “set it and forget it” about low-code environments. They require ongoing security reviews because things can and do change.

“Often, once a system is deployed, the security teams don’t check on them more than once a year,” Dovgan said. “But with low code moving so fast, you need more frequent controls—at least once per quarter. You can find yourself in a very different situation a few months in because your citizen developers have already created multiple applications, some of which may have security issues.”

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