4 security concerns for low-code and no-code development

Low code does not mean low risk. By allowing more people in an enterprise to develop applications, low-code development creates new vulnerabilities and can hide problems from security.

There’s an increased push for what is being dubbed the citizen developer, coupled with the desire to empower application development and creation by non-developers. 

This is typically facilitated using low-code or no-code frameworks. These frameworks and tools allow non-developers to use a GUI to grab and move components to make business logic friendly applications.

Empowering the broader IT and business community to create applications to drive business value has an obvious appeal. That said the use of low code and no code platforms aren’t without their own security concerns. Much like any other software product, the rigour that goes into developing the platform and its associated code is a concern that shouldn’t be overlooked.

What is low-code/ no-code development?

No-code tools and platforms use a drag-and-drop interface to allow non-programmers such as business analysts to create or modify applications. In some cases, actual coding (low code) might be needed for integration with other applications, report generation, or modifying the user interface. This is typically done using a high-level programming language like SQL or Python.

Examples of low-code/no-code platforms include Salesforce Lightning, FileMaker, Microsoft PowerApps and Google App Maker. These are the four most important security concerns for using such platforms.

1. Low visibility into low-code/no-code applications

Using a platform that was developed by an external party always comes with visibility concerns. You’re consuming the software and therefore don’t know about the source code, associated vulnerabilities or potentially the level of testing and rigor the platform has undergone.

This could be mitigated by leveraging practices such as requesting a software bill of materials (SBOM) from the vendor. This would provide insight into the software components it contains and their associated vulnerabilities.

The use of SBOMs are on the rise, with the latest Linux Foundation study indicating that 78 per cent of organisations plan to use SBOMs in 2022. That said, the use of SBOMs is still maturing and there is a lot of room to go for the industry to normalise on practices, processes and tooling.

2. Insecure code

Dovetailing from the visibility concerns is the possibility of insecure code. Low-code and no-code platforms still have code; they’ve just abstracted the coding and allowed the end user instead to use pre-provided code functionality. 

This is great since it saves the non-developer from needing to author the code themselves. Where it gets problematic is when the code that is used is insecure and is extrapolated across organisations and applications through the low-code and no-code platforms.

One way to address this is to work with the platform vendor to ask for security scanning results for the code that is used within the platform. Scan results such as those from static and dynamic application security testing (SAST/DAST) can give consumers a level of assurance that they aren’t just replicating insecure code. 

The idea of code created outside an organisation's control isn’t a new concept and is prevalent in the rampant use of open-source software, which is used by upwards of 98 per cent of organisations and with software supply chain threats associated with other repositories as well, such as those for infrastructure-as-code (IaC) templates.

Another aspect to consider is that many low-code and no-code platforms are delivered as software as a service (SaaS). This puts you in a position to request industry certifications such as ISO, SOC2, FedRAMP and others from the vendor. This provides further assurance regarding the organisation's operational and the security controls applicable to the SaaS application/platform itself.

SaaS applications present many security risks themselves and warrant proper governance and security rigor

Without properly vetting the SaaS applications and platforms your organisation is using, you could be exposing the organisation to undue risk. This is further exacerbated if the low-code and no-code platforms are used to develop applications that will expose sensitive organisational or customer data.

3. Out-of-control shadow IT

Since low-code and no-code platforms allow applications to be quickly created, even by those without development backgrounds, it also can lead to rampant shadow IT. Shadow IT occurs when business units and staff create applications and expose them both internally within the organisation or externally to the world. 

These applications could house sensitive organisational, customer or regulated data, which could have a slew of implications for the organisation if those applications were compromised in a data breach.

4. Business disruption

From a business continuity perspective, reliance on low-code and no-code platforms delivered as a service could disrupt business if that platform experiences an outage. It is important for organisations to establish service level agreements (SLAs) for business-critical applications, including low-code and no-code platforms.

Tips to mitigate risk from low-code/no-code development

Common security best practices can mitigate the risks described above regardless of the technology involved, including:

  • Buy software and platforms from trusted vendors with respected industry reputations.
  • Ensure those vendors have third-party attested certifications to represent their internal security practices and processes.
  • Account for low-code and no-code platforms in your application and software inventories, as well as the applications created through their use.
  • Maintain good access control; know who is accessing the platforms and what activities they are allowed to perform.
  • Implement secure data practices to understand where your critical data resides and if applications created using low-code and no-code platforms house sensitive data.
  • Know where low-code/no-code platforms are hosted. Are the platforms hosted in a hyperscale global Cloud Service Provider (CSP) such as AWS, Google or Microsoft Azure? Or are they hosted in a legacy on-premises data centre with limited to no physical and logical access control?

It’s also important consider your organisation’s security culture. While the platform users may not be developers or security professionals by trade, they should understand the security implications of the low-code and no-code platforms and applications they’re using and creating. With great power comes great responsibility as they said, and this is applicable here with low-code and no-code platforms.