Industry leaders are also banging the drum for no-code, such as the CEO of GitHub Chris Wanstrath, who declared “the future of coding is no coding at all".
However, amongst all the hype we shouldn't lose focus on the biggest barrier to product adoption: security. According to a recent study, 59% of respondents, cited security as the top challenge when it comes to the adoption of low-code platforms.
Letting go of control of an application is hard for anyone, especially legacy enterprises that may have done in-house development for decades. This is why no-code/low-code software providers must work to overcome these concerns; as the saying goes, with great power comes great responsibility.
Therefore, here are five key areas that all vendors should pay close attention to when both designing no-code applications and engaging with their users.
Easily enable user security audits
A thorny issue for many low-code and no-code vendors is accommodating the rigors of enterprise-grade InfoSec audits. This is particularly the case with legacy era enterprises who may have developed their InfoSec vendor audit frameworks in a bygone era.
While auditing documentation and certifications such as compliance and testing certificates are simple enough to accommodate, running physical tests against the software can be a different story.
This is amplified by the fact that a lot of no-code/low-code software are black-box applications, making it impossible to test and verify for security. However, some vendors are generating standard application code that can be tested externally.
For example, low-code platform provider Outsystems enables static application security testing, by allowing users to export its source code. The security features that are tested and verified will then automatically apply to any application built on the platform.
Segment users from data with sandboxes
Vendors rightly invest heavily in data security measures in order to protect data from external threats. However, given that no code and low code software can potentially be used by anyone within the customer's organization, a similar focus needs to be applied to designing solutions that protect data from internal threats on the client-side. These threats can either be from user errors and mistakes, or deliberate malicious acts.
A solution to this problem is to partition sensitive data from users with sandboxes, so each user only has a level of access to data that's relevant to their job role.
Building sandboxes needn't place a huge burden on development teams. One option is to build sandboxes using JavaScript. However, as Javascript needs to be interpreted by a browser, this makes it vulnerable, especially if business logic is stored on the client-side.
A more robust option is to set this up using a virtual machine program such as VirtualBox or VMware. These set up a virtual hardware system that activates the applications in a separate window, which runs these apps without disturbing your network.
Securing API endpoints
API integration with no-code/low-code applications is extremely common, such as into databases, cloud services, and applications. It's therefore crucial that developers ensure they secure endpoints. This sounds obvious, but research has unfortunately found some vendors lacking in this area.
The risk here isn't just suffering a security breach, but also a potential compliance failure for the end-user. This is particularly the case if the end-user is a financial services provider in a highly regulated market such as the EU.
Follow industry best practices to secure endpoints. These include making HTTPS the only protocol option, applying limits to the number of API calls a client can make in a given timeframe, and setting authentication tokens to expire every 24 or 48 hours.
A moot point with no-code vendors securing APIs is restricting access by IP address. This is overly burdensome for most vendors who value immediate client onboarding. What's more, the rise in remote working adds further complexities in this regard.
Managing the risks of customization
No-code/low-code applications are arguably their most vulnerable when developers at the user side add external customizations. Much of the testing and verification completed by the user during the onboarding process can be rendered redundant if developers then start playing with the code, which can lead to a false sense of security.
The level of risk depends on who the target user is. Applications designed for non-developers (or “citizen-developers") will have a limited range of customizations, whereas those designed for developers will usually enable far more customizations.
While vendors can signpost the potential risks to external developers, the responsibility rests with the end-user to ensure security when making customizations. The most effective way to manage this is to contain the new code in a separate module and connect this via API into the no-code app. This enables developers to test the new code and also reduces the risks of negatively impacting the application.
Encouraging a change in attitudes
I'll finish with a more theoretical point. While it's arguable that the security of many no-code/low-code applications far exceed the security of equivalent in house builds, the industry needs to improve how it communicates this to target customers.
For example, a common concern is that low code applications create opportunities of scale for attackers. A security vulnerability opens the opportunity to attack every single organization using the application.
However, the same is true in reverse, in that there are much greater opportunities of scale to identify issues and quickly deploy fixes to no-code/low-code applications.
Other factors also need to be emphasized to target users, such as the fact no-code/low-code applications that are hosted entirely on secure clouds can be far more secure than in-house built equivalents.
#NoCode and #LowCode are being touted as the next big thing by the tech industry. Despite all the hype we shouldn't lose focus on the biggest barrier to adoption: #security.
Ultimately, when it comes to the pros and cons of no-code many enterprise-grade applications and platforms either match or exceed the security offered by the alternative in-house build. However, it's up to the industry to encourage adoption by accommodating the security requirements of users while managing the risks that are specific to this type of software.