New Technologies

Why low code doesn’t have to mean low security

Low code can potentially improve time-to-market in software development and further dismantle the boundaries between IT and business. This often results in broader support for coding within companies. But the question is: how can this be achieved while also meeting the corresponding cybersecurity standards?

cutout of a keyboard

The aim of low code is to make software development more accessible, shorten the time between the initial concept and go-live and significantly reduce the costs for digitalising business processes. According to Gartner, we’ll soon be seeing 70% of all new applications developed using low code.

8 minutes to read
With insights from...

Depending on the target application, these use platforms from different categories , such as Mendix, Simplifier, Microsoft Power Platform, Appian, Service Now, Microsoft Dynamics and Salesforce. As low-code applications continue to proliferate, the focus on security is becoming increasingly relevant. In this article, using our own analyses of application security, we’ll show you what exactly needs to be considered when comparing low code to individual development in the two most commonly used low-code platforms:

  • Specific training in relation to application security appears to be more important in low code than in traditional software development because software development now involves a broader share of the workforce (citizen developers).
  • While the abstraction of low code can help map business processes faster, it doesn’t do much in the way of security. For this reason, tried and tested security principles must also be applied to low-code applications.
  • Third-party code should also be subjected to extensive security checks in the case of low-code applications.
  • In order to safeguard application security, a well-defined secure development life cycle is also crucial in low code.
  • Low-code applications also face the challenges associated with security architecture. It is therefore just as important to tackle this issue during the early stages of low-code projects.

Comparing low code to conventional individual development, it quickly becomes apparent that what’s good for one is often good for the other. With respect to training and raising awareness among citizen developers, however, special care must be taken. Below, we’ll explore the above points in a little more detail.

Training citizen developers is crucial

Developers of low-code applications do not necessarily need to have an impressive technical background or years of experience in software development. In the case of low code, there is instead a greater focus on the efficient mapping of business processes. Since even experienced software developers are often found wanting in terms of their security knowledge, we can expect low-code developers to have a greater deficit in this regard, especially if there is a lack of time and resources allocated, as is often the case in low-code projects.

If you create a business application, for example, performing input validations only in the front end will not suffice. Validations in the back end are particularly relevant for security. A leading low-code platform allows you to perform, for example, type-based validations in the front end and back end. However, you need to explicitly activate, configure and test these validations. If contents are not validated correctly, there is a risk that harmful input may be processed, potentially resulting in undesirable business application behaviour and in some cases, data protection breaches and blackmail by cybercriminals.

It is therefore vital that low-code developers also have sound basic knowledge of application security. Zühlke offers a dedicated web security workshop, specifically aimed at developers with experience in web development.

The best way to learn security is to hack yourself!

High level of abstraction

Low code offers a high level of abstraction, enabling business processes to be mapped faster in software. Large parts of the logic are modelled using the modules provided. This often leads to the delusion that the modules can simply be inserted and linked together while ensuring application security as standard in the process. In the above case, however, these modules can still be configured individually. Here, depending on the platform, the number of options is considerable.

As mentioned above, you have the option of validating data types for some low-code platforms in the area of front-end and back-end validation. Let’s say we’re using two modules that are to receive, validate and process data, and then subsequently provide a certain output. For the input and output of a service to be validated, this must be explicitly activated in a platform that we have analysed in detail.

Consequently, the configuration of the modules and how they are linked together must be checked for security in the respective application context, in order to reduce the attack surface. On a positive note, as shown in the example above, platforms support this – but the configuration needs to be set correctly.

Checking third-party code

New tools and modules can often be added at the touch of a button via the respective marketplaces of low-code platforms. However, the content of a module doesn’t always have to come from trustworthy sources. Many platforms allow self-developed modules to be published on the marketplace and made available to other developers. The security checks of platform operators are not always transparent. This lays the foundation for “supply chain attacks”, which are launched with increasing frequency nowadays. During these attacks, attackers inject malicious code into relevant components or offer the components themselves.

Portals with countless, predefined modules that can be used for developing internal business applications exist for some low-code platforms. There are, for example, modules that allow users to perform a simplified login using a simple link without any need for authentication factors such as passwords. These kinds of functions have strict requirements in terms of information security and should be analysed in detail and carefully integrated prior to use.

In addition to checking for security gaps during integration, you should also check the source code where possible. These checks can be carried out manually or using automated static and dynamic analyses. On top of that, dependencies can also be checked for vulnerabilities, which will be discussed in more detail below.

Secure development life cycle

Development based on a well-defined “secure development life cycle” is just as important for low-code applications as it is for conventionally developed applications. Starting with threat modelling and the derived security requirements, the design of a secure architecture is also necessary. One look at the published vulnerabilities will tell you that certain modules are affected by serious vulnerabilities.

A vulnerability was discovered, for example, in the “Forgot password” module in an earlier version of a leading low-code platform. This vulnerability allowed attackers to take over the accounts of other users. It was eliminated in a new version and the affected versions were removed from the portal. Developers were advised to install an update.

Not only the modules, but the platforms themselves can contain vulnerabilities and must be updated accordingly on a regular basis. We scanned 1 million websites for characteristics of a leading low-code platform and added information from publicwww.com. Of the 95 identified and available websites of this platform, 60% used a version with known vulnerabilities because the operators had failed to update the platform to the latest version.

As is the case with apps on a smartphone or libraries and frameworks in traditional individual development, updating the implemented modules is crucial to the security of an application. On a positive note, the documentation of some low-code platforms addresses “best practices” in relation to security. Following these tried and tested methods is a good start to ensuring an ultimately more secure product.

Security architecture is crucial

Requirements regarding a secure application architecture are also relevant to low-code applications. Aspects such as authentication, authorisation, secure handling of data and logging of events must also be taken into account in low-code applications.

Several providers rely on role-based access control. Developers have to define the access authorisations to the modules themselves for a given platform. These roles can be used for authorisations within the modules. Assignment to an incorrect user role or an incorrect definition leads to undesirable access to functions and data.

Experienced software architects, developers and security experts should therefore be involved in low-code projects too, with particular intensity in the early phases of the project, for example, in order to develop authentication and authorisation concepts and to provide support during implementation.

A "center of excellence" for low code

Security is just as important in low-code software development as it is in conventional individual development. However, the risk regarding security gaps is further exacerbated because applications can be created particularly easily and quickly using a low-code platform. It is therefore vital that such risks be addressed at an early stage – especially at an organisational level. The more employees participating in software development, the greater the likelihood of security gaps. This is due to the fact that citizen developers tend to have less knowledge with regard to best practices.

Establishing a centre of excellence (CoE) for low code in companies can help address these risks. The CoE, as the central unit, is responsible for the low-code platforms. This also includes empowering developers and citizen developers in matters such as software development and security. The CoE is the central point of contact, responsible for monitoring the developed applications and operating the platform. It also informs developers of new versions with security updates and ensures that all applications meet the defined standards. In addition, a CoE can proactively check applications, for example, using targeted risk analyses, and also demand such action from the (citizen) developers before an application is developed. By conducting external penetration tests, a CoE can subject particularly exposed applications to a detailed examination and plan further steps if necessary. On top of that, through regular informational events and community building, the CoE can ensure that the (citizen) developers always remain up to date when it comes to the security of low-code platforms.

With our experience and expertise in IT security and the development of low-code applications, we’ll be happy to support you on your journey towards secure low-code applications. We would be delighted to provide you with a comprehensive consultation on how to use low code in your business context. Learn more about our expertise in low code.

Silvan Stich
Contact person for Switzerland

Silvan Stich

Head of Low-Code

Silvan Stich has taken on the role of Head of Application Platforms as of January 2022. His focus is on team leadership and he is responsible for the development and advancement of the Application Platforms topic within the Cloud Practice. Silvan gained experience with application platforms as a project manager in various projects and bid phases. The great flexibility paired with fast implementation inspires him for the technologies.

Contact
Thank you for your message.