• United States



Chris Hughes
Contributing Writer

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

Feb 16, 20225 mins
Application SecurityCloud Security

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.

software development / application testing / planning / flow chart / diagram
Credit: SPainter VFX / Getty Images

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 rigor 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% of organizations 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 normalize 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 organizations 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 organization’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% of organizations 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 organization’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 organization is using, you could be exposing the organization to undue risk. This is further exacerbated if the low-code and no-code platforms are used to develop applications that will expose sensitive organizational 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 organization or externally to the world. These applications could house sensitive organizational, customer or regulated data, which could have a slew of implications for the organization 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 organizations 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 center with limited to no physical and logical access control?

It’s also important consider your organization’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.

Chris Hughes
Contributing Writer

Chris Hughes currently serves as the co-founder and CISO of Aquia. Chris has nearly 20 years of IT/cybersecurity experience. This ranges from active duty time with the U.S. Air Force, a civil servant with the U.S. Navy and General Services Administration (GSA)/FedRAMP as well as time as a consultant in the private sector. In addition, he also is an adjunct professor for M.S. cybersecurity programs at Capitol Technology University and University of Maryland Global Campus. Chris also participates in industry working groups such as the Cloud Security Alliances Incident Response Working Group and serves as the membership chair for Cloud Security Alliance D.C. Chris also co-hosts the Resilient Cyber Podcast. He holds various industry certifications such as the CISSP/CCSP from ISC2 as holding both the AWS and Azure security certifications. He regularly consults with IT and cybersecurity leaders from various industries to assist their organizations with their cloud migration journeys while keeping security a core component of that transformation.

More from this author