The Microsoft Power Apps Portal Data Leak Revisited: Are You Safe Now?

What happened

In late August 2021, a major data leak exposed where 38 million private records through Microsoft’s Power Apps portals, a powerful low-code tool that enables both professional and citizen developers to create external-facing applications. The misconfiguration was discovered by the research team at UpGuard and is now well-known as one of the most severe low-code security incidents to date. In this article, we set out to analyze the root cause behind this data leak, verify Microsoft’s mitigation effectiveness, and provide our own recommendations for users of the platform.   

How it happened

Power Apps portals are a powerful low-code tool that enables professional and citizen developers to create external-facing applications where users outside of their organizations can view content, authenticate using various providers, and interact with data usually stored in Microsoft Dataverse (previously known as Common Data Services). By creating an external-facing application, it is implied, of course, that anyone on the Internet can view the website. Power Apps portals offer granular control over the types of data exposed to each user. Data can be shared with everyone (or “Anonymous access”, using the Power Apps portals terminology), with authenticated usersor with authenticated users with specific security roles such as “admin” or “content creator”.

The August leak was due to a misconfiguration; anyone on the Internet could access data which should have been available only to authenticated Portal App portals users with specific permissions. Moreover, this was the default configuration, which made the blast radius even larger with impact on huge companies such as American Airlines, Microsoft, J.B. Hunt and governments of Indiana, Maryland and New York City.

Microsoft was quick to respond, and has claimed that the issue has now been mitigated. Changing the insecure default configuration. In this post, we will detail the steps we took to verify that the issue was indeed fully resolved, to understand the impact on existing applications and our final conclusions.

Root cause analysis

To perform a root cause analysis of this low-code security breach, we need to become familiar with a few Power Apps portals features.

  1. Lists – Power Apps portals define access to data via lists. These are views into the Microsoft Dataverse database where the portal stores its data.
  2. Table permissions – Makers can assign permissions for users to have access to those lists, including read, write and delete access. They can also decide whether to turn on Table permissions, which makes the content private, i.e. available only to authenticated users, instead of the default public, i.e. available to any Internet user.
  3. OData – Microsoft Dataverse supports the Open Data Protocol (OData), an industry standard that allows developers to build automated integrations with APIs using a rich query language. This capability is designed to be used by applications, not directly by users. For ease of integration, portal makers can enable OData support for Power Apps portals lists.

The root cause for this data leak was a combination of the insecure default for Table permissions, with the user enabling OData for the list.

By default, when a user created a new list, it was automatically created with Table permissions disabled:

Table permissions disabled

This meant that the list was tagged as available for public view. However, the content was not actually exposed without an API or UI view that presented this data to users or applications.

The second step is for users to enable OData, which is a very common configuration setting, since it is needed in order to integrate the portal with other applications and data in the organizational ecosystem.

OData feed enabled

The combined effect of these two seemingly unrelated configurations, is that the list’s data is now exposed publicly through an API to the entire Internet.

Say. for example, that we had a portal named myportal and a list is called mylist. Then every person on the internet could use their browers to go to and see all the lists available in myportal. After locating the list they would like to leak, they would go to and retrieve all contents contained in that list.

The most critical issue here is that ‘Table permissions’ was disabled by default. This raises the question: why was this even possible? Naturally, portals need to have a way to expose data publicly since that is one of its core features, but this could be accomplished by assigning roles and permissions to the anonymous user rather than disabling permissions altogether.

Verifying Microsoft’s Mitigation

Following the disclosure, Microsoft has announced changes to the default behaviour, enforcing Table permissions for all lists. There are, however, two questions left unanswered:

  1. Can users override the now-secure default and disable Table permissions manually? If not, is this enforced on the API as well?
  2. What about existing applications with Table permissions disabled? How would customers identify these? How would they mitigate the issue?

Following the public disclosure, Zenity has invested time and resources in making sure that the vulnerability was properly mitigated. In the following section, we share our findings and the answers to the questions raised above.

Let’s start with Question 1: Can users override the now-secure default?

When creating a new portal, we see that the default configuration has changed and Table permissions are now enabled. Trying to disable table permissions manually while having OData enabled results in an error, preventing us from saving the new portal:

A breaking change introduced by Microsoft

The user is prevented from setting an insecure setting by the UI. Is this enforced at the API level as well? The answer is – no, users can override the default and set an insecure configuration.

Using the Microsoft Dataverse Web API, we send a PATCH request to https://{env-domain-name}.api.crm{area}{list-id})’ with the following JSON body content: 

API request body

This request successfully disables Table permissions. These changes are reflected in the UI as well:

Table permissions disabled

OData feed enabled

However, trying to retrieve the list content as shown under Root Cause Analysis fails with the following message:

API access to Power Apps portals

We have now answered question 2 as well: What about existing applications? The answer is that Microsoft has introduced a breaking change that blocks access to OData feeds when Table permissions are disabled, thus completely mitigating the issue.

This change is indeed mentioned on the lists page in Microsoft Docs:

Lists that have OData feeds enabled require appropriate table permissions setup for the feed on these lists to work. Hence, you must enable table permissions on a list that has OData feeds enabled.


Zenity’s research concludes that Microsoft fully mitigated the issue and that customers are now protected. Having said that, in the process of doing so, Microsoft introduced a breaking change to the behavior of portal APIs. Customer applications that rely on the OData API can potentially be broken. Customers need to assess the usage of OData APIs in their organization, and detect cases where OData was actively used when table permissions were disabled.

How to detect and mitigate potential issues:

Citizen Developers Security Awareness

Raising Security Awareness Among Citizen Developers

Citizen developers are now producing the types of applications once reserved for professional programmers. By using the low-code/no-code capabilities found in low-code application development platforms (LCAP), business workflow automation or RPA, they can bypass drawn-out development processes and reap the benefits of speed and efficiency. Perhaps even more significant is the resulting efficacy—because who knows better than the citizen developer what the company needs to solve its pain points?

Citizen developer platforms have opened up a new world for enterprises. At the same time, the rise of low code platforms has introduced new concerns connected to citizen developer governance and low code platform security. 

With fewer security and compliance experts involved in the low-code development process, there are less security checkpoints from beginning to end. As a result, citizen developers must become more security aware and actively participate alongside the IT security and governance teams to mitigate risks. Let’s take a look at the background, the issues and how we can address them effectively.

The rise of citizen development


As the demand for software increases, business users have joined the ranks of developers to build applications for their companies and clients. 

And why not? They’re on the ground, struggling to make sense of Google Sheets, waiting for IT, and feeling limited by the capabilities of their SaaS applications. 

They’re also interfacing with clients and customers, fielding complaints, and trying to run department meetings with outdated data and unreliable metrics. They’re in the trenches, and they know exactly what they need to get their jobs done more efficiently.

Today, they are often much more than just business professionals.  

They’re also—citizen developers.

Low-code security challanges

With the low-code/no-code (LCNC) revolution, these individuals are producing the types of applications that were once relegated to professional software developers. With so many citizen development platforms on the market, and sometimes hundreds of new applications being introduced every year within one company alone, businesses are transforming their legacy processes and joining the digital world at lightning speed.

This new digital business world appears idyllic.

And it is… mostly.

But there’s one glaring issue. Low-code security.

While citizen developers can whip up the most stunning apps without a single computer science course under their belts, most do not have any information security training. Many are unaware of the risks in web based application development. Monitoring low-code security policies on their own, or thinking out the potential security ramifications of connectors and integrations, just isn’t something with which they’ve had experience. 

Additionally, CIOs and CISOs must now track the dozens, hundreds or even thousands of new apps their organization is producing. Because the low-code/no-code development pipeline moves faster and skips many of the steps in the traditional SDLC (software development lifecycle), there’s a greater need for security monitoring and governance. 

Exacerbating the problem is the lack of governance and security tools for low-code/no-code. Without visibility, even the most experienced information security team finds their hands tied. 

These low-code security challenges leave organizations and their clients vulnerable to inadvertent data leaks, data breaches, and malicious operations like ransomware attacks, phishing attacks and distributed denial of service (DDoS attacks).

How can an enterprise comfortably empower its citizen developers to innovate and build new and improved digital applications—with security in mind?

Step 1: Raise awareness

Ideally, citizen developers should be able to respond to the following questions:

Sure; it’s not comfortable to think about all the bad things that could happen. But sometimes the best way to appreciate information security is to practice thinking like a malicious hacker. 


Veracode understood the significance of this approach and recently introduced a hackers game competition in universities to teach the importance of writing secure code. Once you have had hands-on practice in finding holes in code, you won’t ever look at code the same way.  

While citizen developers are, by definition, not in computer science programs at universities, the same approach can be used for education within the framework of your organization.

Step 2: Think like a hacker

An ethical hacker is a professional, trained to find security holes in hardware, software, and system configuration. In fact, ethical hackers are often hired by companies to uncover and fix threats with penetration testing, vulnerability assessments, security audits and social engineering techniques.

As hackers, they are often the best ones to share that perspective and mindset with your citizen developers. Ethical hackers can educate citizen developers about potential risks in web based application development and how best to avoid them before, during and after the low-code/no-code development process. They can potentially design training for your business developers, giving them hands-on experience on what it would be like to try to break into a low-code app and where vulnerabilities can lie.

But advanced education is only part of the solution.

Step 3: Learn from mistakes

By “learn from mistakes,” we do NOT mean that your citizen developers should need to experience a data breach or cybersecurity attack in order to learn what not to do. (“It’s not worth it” is an understatement here.)

We mean that citizen developers should learn from security policy violations. If a citizen developer inadvertently creates an application that violates security best practices and opens the organization up to risk, they should be informed about the issue and how to resolve it. 

For example, if a citizen developer using Workato creates a Slack bot which allows employees to book their vacation days, the employee’s personally identifiable information (PII) is stored in that account’s storage. This violates security best practices as it sets up a weak point from which malicious actors would have an easier time gaining access to the app and its permissions. 

When the organization’s InfoSec or AppSec professionals catch the issue, not only should they remediate it, but they should include the citizen developer in the remediation process, and invest the time to explain why this was a problem. You can bet that citizen developers will take that knowledge with them and apply it in the future.


Giving IT and security the tools to help citizen developers

The big issue with that last step is that up until now, InfoSec and AppSec have lacked appropriate governance and security tools for low-code/no-code platforms for citizen developers. Without visibility, they are unable to pinpoint vulnerabilities, much less educate citizen developers on how to remediate and avoid those vulnerabilities in the future. 

As security technology advances and focuses on the vulnerabilities associated with citizen development platforms, information security professionals will be able to better help their business developers become part of an organization-wide governance and security effort.

With citizen development on the rise, it behooves any company to not only provide its citizen developers with information security awareness and education, but to make them partners in securing their organization’s business growth.

Low-Code for Dummies - An Overview of Low-Code Through Examples


While the mission statement of the Zenity Low-Code Security Blog is to help organizations adopt low-code platforms securely and with confidence, we often find ourselves explaining basic low-code concepts and principles - mostly to those who are not familiar with the day-to-day low-code development process. Since our blog will cover many critical topics related to low-code security, we thought it would be beneficial for our readers to first get closely acquainted with low-code, and there’s no better way to do so than through real-world examples.

What's so special about Low-Code?

Low-code/no-code platforms continue to gain popularity, becoming the go-to technology enabling digital transformation. Low-code solves a whole range of business needs with the key commonality of providing quick, efficient and scalable solutions that can be built by the different business teams themselves. By bringing development closer to the business professional that feels the need most acutely, and even letting that business professionals develop themselves, low-code cuts communication costs and allows for fast and agile development.

If you are in a business role in your company, you’re probably very familiar with the frustration of having to wait for a professional developer or an IT expert to build some survey form to collect data, integrate several systems together in order to facilitate a business process, or even automate mundane tasks. These are exactly some of the most common use cases which drive organizations to adopt low-code.

Trying to create a comprehensive list of what people build with low-code would be as futile as trying to compile the same list for things built by professional developers or any other builder’s profession for that matter. We can however look at a few representative use cases to help us grasp what this technology can unlock for us. The purpose of this post is to do just that.

To provide some context and narrow down on a particular domain, we focus on corporate COVID-19 response, and how low-code came to the rescue.

Top low-code use cases

Use Case 1: Business process automation

Power Apps portals site used to check special cash payment application status, City of Kobe

With the COVID-19 crisis response, Japan announced a special cash payment program which allowed every citizen to apply for subsidies. Faced with a huge surge in citizens calling the city offices with inquiries about their application, City of Kobe officers realized they needed an efficient way to manage and track the status of these applications. They leveraged Power Platform, Microsoft’s low-code platform, to facilitate the entire process and create a self-service portal where citizens could quickly receive necessary information about the status of their application without calling city offices. The portal was soon in high demand, as stated by Microsoft:

“The development efforts started in April 2020 with each solution below taking less than two weeks to build. As of May 2020, they’ve been deployed to all citizens and accessed by thousands of users per day. The Power Apps portal solution hit peak usage of over 200K+ in a single day, and as of July 2020 has been averaging 35K+ page views per day.”

Of course, with a self-service portal that allows citizens to view their personal data, security of that data must be taken seriously. The City of Kobe had to make sure they configured their portals correctly to ensure that users can only access their own data.

* Power Platform image source.

Use Case 2: Integration and automation

When COVID-19 hit, vaccine maker Moderna quickly rose to the challenge, creating a vaccine to prevent infection and reduce severe illness. In order to operate as well as they did, Moderna opted for a cloud-first strategy for increased operational speed and agility. While using multiple SaaS services had great value for the business, it also introduced two key challenges: siloed data and user provisioning and deprovisioning. As Moderna put it:

Data integration and automation, Boomi

“The cloud helps Moderna accelerate learning, automate processes, and improve quality at scale. But to harness its full power, the firm needed to integrate its best-in-class, on-demand applications and data from multiple SaaS vendors.”

To solve their siloed data problem, Moderna leveraged boomi, a low-code platform focused on integration, to integrate and synchronize data between multiple parts of the business including budgeting, vendor payments and human resources management. 

Moderna also automated the flow of onboarding and offboarding new employees. 

Of course, automation and integration go hand-in-hand with paying close attention to the way user identity and authorization are used in the process. In order to get an automation working, for example, it is tempting to use personal credentials or admin rights, but the implications could be detrimental to an organization. An organization that is aware of the risk will be particular about users using service credentials only.

Thanks to low-code, Moderna was able to accelerate employee onboarding, increase business efficiency, scale operations and make data accessible internally.

* Boomi image source.

Use Case 3: Rapid application development

During the pandemic, the need to reduce costs and deliver secure services with low-code technologies increased as agencies were, and still are, required to deliver new services rapidly for public safety. The U.S. Department of State (DoS) has leveraged the Now Platform by ServiceNow to distribute critical data to diplomats around the world. As principal deputy CIO of the U.S. State Department, Michael Mestrovich, stated in an interview with MeriTalk:

Rapid application development, ServiceNow

“These were big apps that tracked every country on the planet and what their Covid-19 requirements were. If you came from North America to Great Britain, would you need to quarantine? If you went from Great Britain to Germany, did you have to quarantine? If you did, what were the quarantine requirements? So, there’s a huge tracking mechanism that shows what phase these countries are in, what phase our posts are in, and the COVID requirements for each. All that was done through ServiceNow’s low-code platform.”

A crucial component to this critical information-providing application is ensuring that information can be edited only by authorized personnel. The Department of State had to make sure application permissions were in place to separate the users of the application from its content creators. 

The careful use of low-code has since allowed the DoS to evolve and adapt their application to the ever-changing landscape of COVID-19 response.

* ServiceNow image source.


Low-code platforms are used in organizations to deliver faster, cheaper and more adaptive software. Business applications can be developed to target specific time-sensitive demands, and can scale up to tens of thousands of users in just a couple of weeks. This tremendous change to the software development lifecycle (SDLC) is at the heart of the low-code transformation, however, it is also its greatest risk. To leverage the full power of low-code without compromising on security, business teams must work together with security teams to understand, manage and address low-code’s intrinsic security risks.

Hackers Abuse Low-Code Platforms And Turn Them Against Their Owners

Low-code development platforms open the way for greater independence and efficiency for business users. Unfortunately, they sometimes also open the way for attackers, as a result of poor low-code security practices, especially as low-code application security tries to catch up with traditional application security.

Last year, Microsoft’s Detection and Response Team (DART) published the timeline of an attack which leveraged Power Platform, Microsoft's low-code platform. Using live-off-the-land techniques, the attackers were able to exflitrate sensitive corporate data and maintain complete Office 365 access for 240 days!

This post presents an in-depth analysis of the attack. We will use the small bits and pieces of information (see end of post for a list of sources) that were published to try and understand what happened, and how users of low-code platforms can apply better security controls to prevent similar attacks from happening.

What happened?

As mentioned above, the attackers were able to maintain a persistent and complete Office 365 access for 240 days. During this time, the attackers were able to discover sensitive data, achieve strong persistence and exfiltrate data - all without the need to install any malware or access the corporate network. As traditional security solutions are based on either host or network agents, this type of attack was very hard to discover, to the extent that it took a security response team more than seven months to complete the investigation and oust the attacker.

Let’s start with a summary of the raw details:

TargetA “Large Multinational”
AdversaryNation-state backed adversaries
Adversary reputationThis APT group targets organizations across multiple industries, including government agencies, financial institutions, and technology companies.
Entry pointPassword spray
Exfiltration pointMicrosoft Power Automate
Access level achievedOffice 365 Admin
ResultSystematic access and exfiltration of data as well as sensitive emails.
Time undetectedUnknown
Time persisted240 days
Time investigatedMore than 7 months

As you can see, this attack went deep. Attackers were able to remain persistent within the environment for more than seven months while the security investigation was already ongoing. It is unclear how much time the attacker remained undetected before the investigation even started.

DART has published a slide which summarizes the chain of events:

Microsoft DART low-code security incident details report

Note that the attackers were able to execute an entire successful campaign without ever installing malware and hardly generating any network traffic directly. From the Cyber Kill-Chain perspective, the attackers started with #Delivery and #Exploitation via a Password Spray attack, skipped #Installation, and continued to leverage Office eDiscovery and Compliance Search for #Actions-On-Objective and Microsoft Power Automate for #Command-And-Control.

Many details are still missing, for example:

Let’s try to reproduce the attack and come up with possible answers as we go.

How did it happen? Reproducing the attack

Step 1: Obtain confidential information

Microsoft 365 compliance center offers eDiscovery tools to comply with legal requirements for identifying and delivering specific data across the Office suite. As Microsoft puts it:

“Electronic discovery, or eDiscovery, is the process of identifying and delivering electronic information that can be used as evidence in legal cases. You can use eDiscovery tools in Microsoft 365 to search for content in Exchange Online mailboxes, Microsoft 365 Groups, Microsoft Teams, SharePoint Online and OneDrive for Business sites, and Skype for Business conversations, and Yammer teams. You can search mailboxes and sites in the same eDiscovery search by using the Content Search tool. And you can use Core eDiscovery cases to identify, hold, and export content found in mailboxes and sites.”

There are two tools that allow you to search over the entire tenant’s data: Content Search and Core eDiscovery. While these are separate services solving different business use-cases, both have a very similar user experience and search across the entire Office suite, including Exchange mailboxes, Teams Messages, SharePoint sites and Skype for Business messages.

According to DART, the attackers used these built-in eDiscovery tools to perform precision searches for both passwords and intellectual property. Here are a few examples of harmful search queries:

Password reset emails(subjecttitle:"password reset")( emails
Passwords shared between userspassword (c:s) username (c:s) client id (c:s) client secret (c:s) certificate (c:s) .ppkTeams, Skype and Office 365 messages, and Exchange emails
Legal documents(size>1048576)(filetype=docx)(filetype=pptx)(filetype=xlsx)(filetype=pdf)legalOneDrive and SharePoint documents, and Exchange emails
All communications to company CEO(, Skype and Office 365 messages, and Exchange emails

These are only a few examples, however they demonstrate the tremendous power that these tools provide. If such capabilities fall into the wrong hands, they can be abused to move laterally by acquiring new credentials, obtain sensitive documents and perform a precision search to acquire all information of a single high privileged account.

Once you create an eDiscovery search, you can export its results periodically. Microsoft documentation clearly states that automated export is not supported, which might be related to the incident we are exploring. Today, Microsoft offers the eDiscovery Export Tool to access search results. The results are stored in an Azure storage account prior to being downloaded with the aforementioned tool, providing an opportunity for the attacker to access the files automatically. For this post’s purposes, we assume an attacker can fetch search results via an authenticated HTTP(s) request.

We now have a way to obtain valuable confidential information. It’s time to exfiltrate it and automate the process.

Step 2: Automate exfiltration by "living-of-the-land"

Power Automate is Microsoft’s low-code automation tool. It is available by default for every Office 365 user and is conveniently plugged into Office, SharePoint, Teams and Microsoft Dynamics. As Microsoft puts it:

“Empower everyone to build automated processes with flows in Power Automate. Use low-code, drag-and-drop tools and hundreds of prebuilt connectors that automate repetitive, mundane tasks with ease.”

Indeed, Power Automate is a powerful tool that gives business users and developers alike the ability to automate tasks, connect services and streamline an entire business process without writing any code. Most things a developer can do with scripts are now possible for both developers and business users with low-code.

When unprotected, however, Microsoft Power Automate gives power into the hands of attackers. An attacker can create a scheduled flow, export query results from Microsoft Compliance Centers and store the results in their own Azure blob storage (or any other exfiltration endpoint).

A malicious low-code application

From the attacker’s perspective, Power Automate serves a dual purpose:

  1. Execute attack logic - instead of having to install malware on a compromised machine and risk detection by host-based security mechanisms, the attacker can leverage Office to orchestrate and run the malicious flow.
  2. Exfiltrate data - instead of having to find a route out of the corporate network while bypassing network security mechanisms, the attackers leverage an existing path to Office 365 and then use Office to send data elsewhere. Additionally, this method leaves no traces of the attack in the network logs, since Office is making all of the connections.

Preventing low-code platform abuse

Several things went terribly wrong in this attack. First and foremost, an administrator account should always have strong passwords and have multi-factor authentication (MFA) enabled. This would have prevented access to Microsoft compliance center capabilities and thus drastically limit the blast radius of the attack. Moreover, a few key log streams were disabled, hampering the investigation.

However, even if the attackers were not able to compromise an administrator account, they could still compromise other users within the organization with the same password spray attack. The malicious use of low-code platforms demonstrated above could be part of any attack, providing the attackers with a way to orchestrate and execute their malicious operations and exfiltrate data, all without leaving any trace on a host machine or the corporate network. Anything a user has access to is up for grabs for the attacker to automate.

This malicious strategy could easily be used with other low-code platforms, including Salesforce, ServiceNow, Zapier, IFTTT, Workato and MuleSoft. 

While low-code platforms are not the only application development platforms that can be manipulated by attackers, they are particularly vulnerable to attack because low-code application security is still in its infancy, and organizations have yet to learn how to master low-code security best practices. 

Traditional application security and IT security solutions cannot be used for these modern low-code business applications, and the equivalents for low-code are only just emerging. Application and information security professionals often have lower awareness of the unique risks of low-code platforms - or they have a keen awareness, but their hands are tied for lack of appropriate governance tools. 

To prevent an attack like this or spot it as it unfolds, security teams must be familiar with the low-code platforms that are used within their organization and continuously monitor them for potential vulnerabilities and malicious activity. To succeed, they must realize that low-code is as much a revolution in SDLC as it is a new technology. They must also work alongside platform administrators to leverage platform governance capabilities that can restrict dangerous functionalities not required by users, like automated access to Office admin centers. 

As always, there is a delicate balance to strike between improving security posture and enabling business workflows.

Let's get practical

The following low-code platform security measures are simple fixes that you can (and should!) implement today:

  1. Ensure that your administration users have MFA enabled.
  2. Ensure that Office Audit Logs are enabled, including logs for Power Automate and Power App.
  3. Work with your Power Platform admins and consider restricting unused administrative connectors such as Power Platform for Admins, Power Automate for Admins, Power Apps for Admins, Microsoft 365 Compliance, Microsoft Defender ATP, Microsoft Security Graph, Azure AD, Azure AD Identity Protection and Security Center. 

Low-code platforms are an amazing tool with tremendous ROI potential for the organizations that use them, which is one of the reasons why adoption is increasing so rapidly. To make sure you get the benefits of low-code without opening your organization to increased risk of attack, be aware of the issues. Set your priorities on putting appropriate security, visibility and governance strategies into place, so that you can open the door to business efficiency and growth, while closing the door to attackers.  


Low-Code SDLC - Build Fast, Stay Secure

Low-code application development provides a solution for a wide range of business needs, from business applications through process automation and integrations. Low-code platforms are becoming a key technology behind the ongoing digital transformation trend, and as such, adoption of low-code platforms is soaring. However, low-code is as much a revolution as it is an exciting new technology. Low-code development democratizes application development and makes the process faster, cheaper and more aligned with the business.

Low-code Security - Awareness is Key

Low-code application development drastically reduces the number of stakeholders involved throughout the software development lifecycle (SDLC) process, increasing velocity and productivity. At the same time, low-code development creates new challenges to governance and security. In order to avoid introducing security vulnerabilities into low-code applications, security teams, business users and citizen developers must first be aware of the relevant low-code application security risks and how to overcome them. As you will soon see, this is especially important given the substantial difference between traditional SDLC process and that of low-code application development.   

Building Software - The Traditional SDLC Style

The software development lifecycle (SDLC) process provides a high-level description of the steps required to design, implement and maintain software. It has been molded, reshaped and fine-tuned over the years to create agile, high-quality and secure software.

 The Software Development Lifecycle (SDLC)

As an example, let’s say an organization wants to develop a simple integration between two systems - e.g. notifying a Slack channel whenever a new file has been added to a specific Google Drive folder. 

With traditional software development, the development process is done by a team of professional developers, and would be along the lines of the following:

  1. Envision - The business stakeholder defines the needs and the scope of the solution.
  2. Plan - The product manager creates specifications in collaboration with the business stakeholder and the development team. Once approved, the developer creates a design that satisfies the specification. The design is then reviewed with the development team, product manager, business stakeholder and IT / privacy / security teams.
  3. Create - Developers are assigned to build the solution according to the design.
  4. Verify - QA teams are assigned to test the automation with manual and automated testing.
  5. Deploy - DevOps teams instrument the automation with monitoring capabilities and release the automation.
  6. Monitor - DevOps teams continuously monitor the automation to validate it is working properly.
  7. Manage - In case of an issue or a change in requirements, DevOps and development teams drive the mitigation with well-defined SLAs.

Note that every time ownership of a project changes hands, new stakeholders are onboarded and their efforts are prioritized.

As mentioned above and demonstrated in this example, the SDLC process assures that all business aspects are taken into consideration when building software. Well-architectured design, enterprise governance, security, maintainability and quality are built into the process.

The main drawback of the traditional SDLC process is that it is prone to stray from the original intentions of the business stakeholder, as information might get lost in translation. It can also be wasteful in terms of time. Software development methodologies like Agile aim to ease those pains by reducing the size of each project that goes through this process, but the inherent problems still remain.

Building Software - The Low-Code Way

Now let’s look at the same requirements, through the low-code lens. low-code development provides an alternative to pro-code (traditional) development, which satisfies business requirements without competing for IT / development resources. Here is the same development process, but this time, adjusted for low-code development:

  1. Envision - The business stakeholder defines the needs and the scope of the solution.
  2. Create, Verify, Deploy - The business stakeholders use low-code platforms, designed to be user-friendly for non-developers. They create the automation, manually test it to verify it works and seamlessly deploy it to a cloud runtime environment, oftentimes without even knowing or caring what a cloud runtime environment is.

This process varies between organizations. For example, in some organizations, the business stakeholder might reach out to an automation expert within their department or within the Digital Transformation department to create their automation.

As you can immediately see, the low-code development process is much shorter. It involves less people and can even be accomplished by a single professional. This dramatically reduces time-to-feature and the use of development resources. It also ensures business stakeholders get solutions to their needs, with a lot less hassle.

It should be noted that a few key steps of the SDLC are missing, namely Plan, Monitor and Manage. low-code platforms provide tools that can help with these steps, but it is still up to the low-code developer to use them correctly. Moreover, these steps require either a high level of expertise (e.g. security and compliance review) or a different mode of operation, for example - monitoring and maintaining software.

Traditional SDLC vs. Low-code Development

These two development processes are optimized for different goals. Low-code development is optimized for development velocity and alignment with business goals by putting more power in the hands of business stakeholders and digital transformation offices. On the other hand, traditional software development is optimized for quality, security and maintainability. It leverages multiple viewpoints from different stakeholders which verify that all aspects of software development are considered.

Low-code development adds tremendous value to organizations, especially the ones going through digital transformation. However, organizations cannot afford to lose their governance capabilities, security assurances or software maintainability. These challenges must be met with dedicated solutions that do not rely on or interfere with the work of low-code developers. Instead, they must enable working alongside developers to help them follow the paved road. For low-code to reach its full potential, organizations must be able to unleash their citizen developers without compromising secure software development.

Keeping an Eye on Low-Code Security Concerns

To summarize, while low-code development removes a lot of the obstacles associated with traditional software development lifecycle processes, it also introduces new concerns related to the governance and security aspects of low-code application development, partly because of the fact that not enough stakeholders with security and compliance expertise are involved in the process. There are less checkpoints along the way from inception to deployment, and in turn, less opportunities to verify and validate that what’s being built adheres to corporate security standards. Given that low-code development processes are not likely to change anytime soon, the best approach organizations should take is to provide citizen developers with the necessary low-code security education, make them aware of low-code risks and concerns, and provide them with the necessary tools to develop secure low code applications.