How to secure Citizen (Low Code) Development — Part 1: Why is it different?

Citizen developer building a new application

In this series of posts, I’d like to document what I’ve experienced in projects and discussions around “citizen development security” and “low code application security” to hopefully provide value to all readers who are also thinking about the challenges involved in securing citizen development activities in their companies.

As this post is the first in a series of posts, I will start with the following sections before we dive deeper into the different perspectives and considerations in the coming posts:

1. What is citizen development and why is it different from “regular” software development?
2. What is low code development and how is it related to citizen development?
3. Why is it necessary to secure citizen development activities in different ways as opposed to “regular” software development?

What is citizen development and why is it different from “regular” software development?

Before we dive deeper into the needed activities to secure citizen development, we first have to define what citizen development is.
I’d like to use the Gartner definition as a foundation:

A citizen developer is an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units. A citizen developer is a persona, not a title or targeted role. They report to a business unit or function other than IT.

Furthermore, it should be added that citizen developers are often not formally trained in software development but have varying degrees of self-taught knowledge in developing smaller software projects e.g., reports or macros.
Therefore a citizen developer is someone who:

1. Creates application capabilities for consumption by themselves or others
2. Uses tools that are not actively forbidden by IT
3. Is part of a business unit or function other than IT
4. Is usually not formally trained in software development

In my experience, citizen developers try to innovate and accelerate business processes by developing their own applications. They tend to start small projects and add to them until the resulting application reaches a significant complexity.

Key differences between this approach and the “regular” software development process I have experienced are:

• Citizen developers usually don’t follow software development methodologies and processes such as Kanban, Scrum etc.
• Therefore viable activities like requirement engineering, architecture planning and review, threat modelling, quality assurance and regression testing are often omitted
• Often there is little planning for long-time operation and maintenance of the application
• Software development lifecycle and security policies or guidelines are rarely followed

It is important to highlight that these differences are (in my experience) mostly due to a lack of awareness and tailored training materials and not intentional shortcuts. Next, we will define the term “low code” development and how it’s related to citizen development.

What is low code development and how is it related to citizen development?

Let’s use IBM’s definition of Low Code as a baseline for our own definition:

Low-code is a visual approach to software development that enables faster delivery of applications through minimal hand-coding. The graphical user interface and the drag-and-drop features of a low-code platform automates aspects of the development process, eliminating dependencies on traditional computer programming approaches. Low-code platforms democratize app development, particularly for the “citizen” developers — i.e. business users with little formal coding experience, such as business analysts or project managers.

For the sake of simplicity, I will use this definition for the term “low code” development going forward. Additionally, you can see IBMs own definition of citizen development in the last sentence of this quote.
Therefore, we can summarize this definition and the relation to citizen developers like this:

• Low code is a visual approach to software development with minimal manual coding
• It uses drag-and-drop features to automate the development process
• It enables citizen developers to develop applications

This will bring us to the last section of this post: Why is it different from the regular software development lifecycle that we (hopefully) already secure through various policies, guidelines and activities?

Why is it necessary to secure citizen development activities in different ways as opposed to “regular” software development?

First of all, I’d like to use the following definition to describe the term “regular” software development:

• It follows a defined, documented and repeatable process or “Software Development Lifecycle” (SDLC)
• Formally trained or experienced software developers use established methods to organize development activities e.g. via sprints, version control systems, automated or manual testing procedures
• It follows formal software development and security guidelines or policies

Even when using this — admittedly simplified — definition of “regular” software development the need for a tailored approach to citizen development security becomes clear.

The following questions illustrate the differences and should explain why a tailored approach is necessary:

If citizen developers are not formally trained in software development methodologies and practices, how can we expect them to understand and adhere to DevOps and CI/CD best practices, which at times is also hard for trained and experienced developers?

If citizen developers have never had to maintain and run an application for more than a couple of weeks or months, how can we expect them to know what is needed to maintain and run an application for years?

Lastly, if citizen developers don’t understand security guidelines and policies written for experienced and trained developers, how can we expect them to understand, adhere to and implement security requirements in their applications?

Therefore, we have to find a new and tailored approach to securing applications developed (and potentially also maintained) by citizen developers. This approach will have to cover the whole SDLC and should consider different stakeholder perspectives e.g. Enterprise Architecture Management, Operations, Security and last but not least the perspective of the citizen developers.

If you liked this post and would like to learn more about the different perspectives or the approach I’m going to propose in my later posts of this series consider following me on Medium, as I will release posts every week.