Security and Low-Code: did you lock the door?

Security is becoming more important. So it is not surprising that security is always a topic when I am talking to clients. I always emphasize that security is even more important in the world of low code. Citizen development is rising, and the business is more and more involved in the development of applications. This is, of course, great for the speed to market and solving business issues through digitalization. However, this also means that people who, in general, have little knowledge of the requirements of quality software (security included) are in the lead for developing business solutions. This results in a great challenge for low code development teams because they need to ensure that what is being delivered is considered quality software.

Especially security is a difficult topic, mostly because when discussing it or preparing for it, we are driven by the fear of reputation damage, either the brand or personal level. This fear can cloud our judgment. When I am having a conversation on security with a client, the question that always arises is;

do we cover security testing with our SMART Digital Factory tooling?

Well, the answer is yes. But it does require some explaining.

Security testing for low code is different than regular high code. I know, confusing. We are, most of the time, stating that quality checks like code review and functional testing are the same for high code and low code. But this time, it is different.

Imagine you built your own house. You want it to be secure, so you need solid walls and a roof to ensure that nobody gets in. However, what is the point of a house that cannot be used? So it must also be livable. You will need some windows for natural lighting. You want to get inside yourself, so you need some doors as well, but you only want certain people to enter, so you need to make a door that only works for specific people.

That is a lot of requirements to take into account:

• You need solid walls and a roof to avoid entering the house.
• You need windows that can only open from the inside, not from the outside.
• You need a door that can be opened only by specific people.

Once you finished your house, you want to make sure that you met all the different requirements and that your house is secure enough. So you check it out yourself and test everything. Of course, to be sure, you also hire some people to try and ‘penetrate’ your house. You see what I did there 😉 .

Eventually, they report back and tell you what the result and potentially what you should fix.

Next time you leave your house, it is up to lock the door and ensure that only people with a key can get in.

You see, with high code, you are mostly building the application yourself, which means that you are the one implementing the security measures throughout the entire application to ensure no malicious parties can gain access. With low code, it is different.

Imagine you bought a new house. It has walls, a roof, and the contractor agreed to put in new doors and windows. The contractor tested everything thoroughly, and after a while, you get the keys, and you can get inside your new house.

In this scenario, locking the door and distributing keys is your main concern.

Because with low code, the actual platform you are using for application development is doing thorough security testing. Low code platforms test their cloud, apps, and widgets extensively to ensure that they are safe. Just have a look at the security measures that Mendix takes into account.

When you built an application using a low code platform, you are using these thoroughly tested low code components in your application. In this case, your main security focus is configuring the security settings to ensure that every door is locked and that the right people have keys. Of course, assuming you are not alternating existing platform components so that you are impacting their security (needless to say that you should never do this). This means that from a security perspective, your main security threat when using low code is in the security configuration of your application.

I know security is not this simple and that there are always exceptions. So I am not telling you to take security lightly. If anything, I think you should take it dead serious. I am telling you that you should be aware of your priorities when security testing low code application. Make sure you lock that door.

Need help checking the lock on all those doors? We are here to help you.

• Application Code Reviewer (ACR) is a static analysis tool specifically designed for Mendix. It checks every microflow, page, and every other document in your app, as well as the global setting and security configuration of your project. ACR finds security vulnerabilities that compromise your app or data. Keep your users' data safe by understanding and fixing the violations in your app. In general, it is also possible to configure your own security policies in ACR. ACR also ensures your application is reliable and maintainable.

• Application Model Security (AMS) is a protocol-level security tool that determines what data a specific user can access/change. Unlike ACR, AMS does not have access to the source code and instead does black-box testing. By comparing two scans done on different revisions of your application, you can see changes that have occurred. These changes can either be as intended and be approved, or the change is a regression, and the model needs to be fixed.

By integrating both ACR and AMS in a CI/CD pipeline, you can automate these checks and make sure that you will never forget to lock the door when you leave the house.