A leadership guide for mitigating security risks with low code platforms
The low code market continues to grow, increasingly finding adoption for more diverse and serious applications among enterprises and independent software vendors (ISVs).
The lingering question of application code security follows, as stories of security breaches continue to pour, and remote teams across the world adopt low code for faster application delivery. Even as Gartner predicts that 65% of applications will be built using the low-code paradigm by 2024, it is important to understand the security implications that come with it and discuss how we can mitigate possible risks.
Most low code platforms enable non-technical users to build applications quickly and offer in-built security for various aspects of the application, such as APIs, data access, web front-ends, deployment, etc. Some go deeper with functionalities purpose-built for professional developers, with abilities to customize at a platform level. That said, no platform can claim to be the silver bullet when it comes to abstracting all security risks.
Business leaders should assess both internal and external risks that arise, and make sure there are certain guard rails enforced to secure low code-built applications. Let’s discuss some of these in detail.
An API-first strategy is becoming increasingly commonplace in organizations today for exposing services, data, etc. But do all of them pursue API security in the same vein? As per a Salt Security report, 27% of organizations running production APIs have no API security strategy at all. Web and mobile applications built using low code leveraging APIs could potentially become an attack vector, if the underlying APIs are not secure enough.
It is important to review APIs for security, typically through penetration tests or scanner tools before integrating with low code applications. Using an OAuth-based API token exchange with an appropriate refresh mechanism for tokens can ensure they are not compromised. Additionally, applications could conceal APIs by creating a proxy with an added layer of authentication to minimize the attack vector for APIs.
Technology leaders need to review access to business-critical data exposed through low code applications closely from a security and governance point of view. Low code platforms allow roles to be created with a specific set of permissions to view or modify this data and dev teams should use caution in setting up these properly while developing the application. Data compromises typically arise when developers widen the permissions inadvertently for a specific role exposing additional data or by providing elevated access.
To avoid these situations, IT security teams usually set up organization-wide authentication providers or single sign-on (SSO) systems which define the roles and permissions across the organization. Low code applications should seamlessly integrate with these systems and make use of the established security and governance policies already in place.
The State of API Security report quotes that 82% of organizations do not know which APIs expose PII or other sensitive data. When using such APIs in low code applications additional review process is needed from internal security teams and consent has to be taken from the application users for sharing the information.
Application access outside firewall
With the changed norms of COVID-19 to make remote working possible, many organizations are pushing their apps and APIs outside the network. This will create the need for additional security for low code applications to operate outside the boundary, protecting against malicious attacks. Low code platforms should provide a secure framework for building web and mobile applications, mitigating the Top 10 OWASP vulnerabilities.
Proprietary code with hidden vulnerabilities
In this article, Chris Wysopal, CTO of Veracode, brings up the crucial discussion point of many low code platforms generating a good deal of proprietary software that is somewhat opaque, making security a challenge. Even though a few platforms generate traditional code, it is a mix of code and proprietary libraries which makes it difficult to run static analysis.
A low code platform with open standards-based code with well-known open-source libraries, enables most static analysis tools to perform audits for known vulnerabilities and detects them upfront. In addition to this, it is advised to run dynamic analysis on applications to identify vulnerabilities that could arise at runtime.
Shifting security left
In line with the latest trend in DevSecOps, shifting security left is desirable to bring in the necessary verification and audit steps early-on during the application development. DevOps leaders should consider platforms that provide the ability to integrate with static analysis tools right from the time developers make their first check-in.
This will help weed out vulnerabilities at early stages of development and help avoid serious security flaws showing up post-production.
Building a culture of self-service and ownership
Lastly, low code development teams should have enough awareness towards potential threats and security risks. Security training on application security best practices should be mandatory, and the overall development culture should empower and encourage developers to own the responsibility of building secure apps.
Low code platforms can help development teams thrive in this self-service culture, with tools that can support them generate secure code, align with existing methodologies and dev practices, greatly abstract repetitive work, and focus on adding business value.
Low code security doesn’t have to be a risk, if it’s done right.