Today, more than 300 vendors and various platforms offer different flavors of low-code solutions. However, the majority of these low-code tools are really no-code tools that benefit individuals or groups trying to solve a specific program. The list of benefits of low-code tools in your environment is long and compelling; however, there are security risks that businesses should be aware of when working with these powerful tools.
When evaluating or using a low-code tool, it’s important to remember that while low-code tools abstract the process of writing code, code is still being written. Applications created with low-code tools are susceptible to the same attacks as any other web application. However, companies don’t have control over the code generated by a low-code tool, so the burden of developing secure applications is largely shifted to the low-code tool vendor. Therefore, the best way to minimize risk when using a low-code vendor is to properly evaluate that vendor’s security practices and test applications created using these tools as vigorously as you would any application developed using a traditional/pro-code approach.
Risks to consider include access control and authentication (permissions, multifactor authentication), data security (encryption in transit and at rest) and application security from vulnerabilities and attacks (network security and intrusion detection). Other risks to consider are risk mitigation covering areas such as DDOS (distributed denial of service) attacks, backup and disaster recovery, and security incident handling. Responsibility for management of these risks belongs to the low-code vendor, the hosting provider and the company using the low-code tool.
The following tips should be considered when bringing new low-code tools into your environment to minimize security risk. Remember, it’s critical to perform due diligence of the vendor. Items to consider include:
Hosting Platform: Be sure the vendor is using a reputable hosting provider, ideally Amazon Web Services (AWS), Google Cloud Platform, Salesforce or Microsoft Azure. Leading players will offer secure, highly available platforms that address the aforementioned risks and will have completed third-party audits and certifications demonstrating their commitment to security.
Vendor Infrastructure Management: Low-code vendors typically have some level of responsibility for management of the upper tiers of the overall stack; this is generally referred to as the shared security model. Review the vendor to ensure they have solid controls and processes in place to properly manage and secure the infrastructure. Ideally, the vendor regularly submits to some form of recognized audit, such as a SOC 2 Type 2 or ISO-27001. This helps ensure controls and processes are in place in areas such as security, availability, confidentiality, privacy and processing integrity to address the aforementioned risks in the area of the hosting platform the vendor is responsible for.
Formal SDLC: The vendor should follow a documented software development life cycle (SDLC) and change management process used for the development of their low-code tool. A good SDLC process includes using a source code management system, dependency checking process, static code analysis, automated unit and regression tests, peer code review, secure coding practices training, application vulnerability scanning, quality assurance testing process and third-party penetration testing.
Policies and Processes: Documented policies and processes covering information security, business continuity, disaster recovery, security incident handling, infrastructure hardening and more should be in place at the vendor. This helps demonstrate that the vendor is committed to providing a secure, highly available and high-quality offering.
The company adopting the low-code tool itself should also consider internal processes and how it’s using the low-code tools. Items to consider include:
Formal SDLC: Even though the company uses a low-code tool, there’s still the need to follow a formalized SDLC. It’s important for the company to emphasize and embrace secure programming practices, even for low-code developers. Low-code tools have the ability to implement customer-developed code snippets or components and it is recommended companies follow programming standards and secure programming practices as outlined by the Open Web Application Security Project (OWASP) foundation. Another area of emphasis that can sometimes be overlooked is the need for testing, including functional and security-oriented testing.
Security Testing: Consider performing a penetration test of the completed low-code application. While ideally, the vendor has performed these tests on the tools itself, it’s a good idea to also perform one on the completed low-code application.
Access Control and Authentication: Configure access and permissions according to the least privilege model. Leverage advanced authentication mechanisms like multifactor authentication and single sign-on where possible. Ensure an access removal process is in place to remove access for terminated employees.
Data Security: Verify the application is configured to use HTTPS and that all databases are encrypted. Low-code vendors may or may not provide a database, and either way, the company likely has some level of responsibility for securing the data, regardless of who is hosting it.
Policies and Processes: Documented policies, processes and related training for team members helps mitigate risk. Some level of formality is recommended for documentation and training for the SDLC, business continuity planning, disaster recovery and security incident handling. For example, the team responsible for the low-code application needs to know how to handle a security incident if one occurs, whether it’s due to an issue in the low-code application, the low-code tool or the hosting infrastructure.
The benefits of low-code tools far outweigh the risks of introducing these tools into your environment, but with a little effort up front, you can save a lot of headaches down the road.
