<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1195114&amp;fmt=gif">

Security and low code; did you lock the door?

Derryn Zwart
Derryn Zwart

SMART Digital Factory Mendix Quality

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.

Derryn Zwart

Derryn Zwart

Derryn is the product manager of the SMART Digital Factory Tooling. As a product manager, he is involved in identifying the customer needs and the business objectives of the tooling. He previously worked at Mansytems as a QA consultant for three years. After graduating with a master's degree in tax law, he worked at PricewaterhouseCoopers on the International tax law department for 1,5 years. Eventually, he missed the IT (and the awesome vibe at Mansystems) too much and returned as a product manager.

Related posts

Cloud architecture patterns

How to offload work from Mendix to Azure? As someone who has been working with Mendix for several years I am acutely aware of the limitations of the ...

Read More

Best practices for writing custom actions in Mendix

Since actions are the main way of using many app store modules, it is worth investing some time and thought in designing good actions. Here are ...

Read More

Best practice for adding a java dependency to Mendix

My journey with Mendix started more than four years ago. Due to the nature of my Mendix projects many times I had to use third-party java libraries ...

Read More