Why low-code/no-code should not mean low/no security

For a long time, security experts have struggled to gain visibility of enterprise- app and service usage that may put organizational data at risk. With the increased adoption of SaaS we have seen in the past few years, security solutions such as CASB, SASE and SSPM are helping organizations gain greater visibility and control of what, how and if these services are used.

However, the concept of development has introduced shadow IT applications to an organization, impacting the security and compliance of data. In this scenario, how can security professionals avoid breaches within these applications that may infiltrate other critical systems?

This article focuses on five key topics that need to be addressed when governing the security and compliance of low-code application development:

Identity is the primary perimeter in a public cloud architecture and the first line of a defense-in-depth security posture. As we move away from physical infrastructure and compute resources, the more important it becomes to secure our identity and secrets. In this context, both of these are primary ways that users gain access to an application, and in turn to other applications or databases. Both are equally important and improper handling could cause an identity breach.

Unlike security professionals, low-code developers may not understand the full scope of access, such as a user’s authorized credentials or a secret’s permissions. An organization can protect itself from leaked credentials and secrets by ensuring that user accounts and secrets are not exposed within its applications. Operations requiring privileged access should be implemented just in time and with just enough access through zero trust verification methods. If standard security practices have these procedures in place, it will limit the chance of exposure in low-code application development.

Static testing is the process of having someone review the code prior to production, although it is just an “eye test” of the written code, not the code in action. Therefore, it may not identify possible vulnerabilities that only appear when the application is running. On the other hand, dynamic testing is used to test code while an application is running. It has the potential to uncover more vulnerabilities, but since the code is in production, these vulnerabilities may be exploited by an attacker, underscoring the importance of monitoring the application during testing.

Static and dynamic testing can help identify the configuration errors discussed in the previous section. Testing is a critical phase that provides peace of mind prior to an application going into production. Company procedures need to be in place within a DevSecOps deployment process. This may not be feasible within your organization for agile low-code development within departments, but it is an important step to avoid API- and code-based vulnerabilities, such as cross-site scripting and injection attacks.

Since low-code development is by definition executed by people outside the IT department, the development of these applications is often not aligned with the same DevSecOps processes. Therefore, security teams should integrate security testing into their processes prior to releasing the low-code application into production.

Finally, the key to any successful security posture is how applications are monitored and managed for potential anomalous activities and threats. Policies should be in place for all application development to ensure that proper logging takes place and security operations systems have access to review these logs through a SIEM/SOAR solution with analytics capabilities — such as the Atos AIsaac MDR platform.