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 rigor that goes into developing the platform and its associated code is a concern that shouldn’t be overlooked.
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.
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.
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.
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.
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.
Common security best practices can mitigate the risks described above regardless of the technology involved, including:
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.