In the hands of professional coders, low-code development platforms can speed up development cycles. Meantime, business users can leverage no-code tools to empower themselves as citizen developers who can quickly create applications to automate tasks, connect existing applications together, or customize software to perform exactly as they need.
All of this flexibility can come with a security cost, however. Without the right security policies and control mechanisms, low-code/no-code can stand to exacerbate existing application security problems and potentially erode security posture around access control, code quality, and application visibility. While the first instinct may be to ban low-code/no-code development outright, the reality is that this is a battle that no CISO will win, says Michael Bargury, co-founder and CTO of Zenity, a low-code/no-code security firm.
“You can’t fight this trend,” says Bargury, who’s also co-author of the OWASP Low-Code/No-Code Top 10 list. “I see some organizations try to go down the route of either saying, ‘Low-code and no-code is not going to happen here,’ or saying, ‘We’re going to allow it, but only in this platform’.And these are things that you can tell yourself as a security leader, but this approach is about as ineffective as banning people from bringing their own devices onto the network was all those years ago.”
Instead, he and other forward-looking application security advocates recommend that organizations start building an enforceable set of policies around low-code/no-code development and creating the right set of processes and technology to manage the biggest risks in these development environments. The following are 10 types of policies security leaders should consider for low-code/no-code.
Acceptable use case purpose and scope policies
Like with many security exercises, before policies are defined and enforced an organization would do well to audit and document the current state of affairs. Assess how pro coders and business users are already leveraging low-code and no-code technologies in the enterprise and be sure to dig deep.
Bargury warns that many CISOs and technology leaders do not realize how prevalent low-code and no-code already are in today’s environments. An assessment should look out for not-only the known enterprise class no-code/low-code platforms, but also at the smaller prosumer choices that tech savvy business users may be paying for outside of IT purview. Additionally, this assessment should look for existing SaaS and software platform vendors that embed no-code/low-code capabilities directly into their offerings to enable users to customize and add connectors without input from the dev team.
The lesson here is to be thorough in assessment and then document and define existing use cases. Understanding why certain user groups are currently leveraging a particular low-code/no-code platform will help security and business leaders make risk calculations that will determine the course of future policies.
The most immediate policy that will come out of this work will be one that defines acceptable use cases for low-code/no-code across the business.
“Specify the application of low-code and no-code development across departments, as well as clearly state the purpose of low-code and no-code development,” says Vikas Kaushik, CEO of TechAhead, a development consultancy. This policy of purpose and scope is crucial for setting the course and the tone of the risk management policies around use cases.
Some companies may choose to be very granular about this, breaking it down by lines of business, business function, user groups, or teams. Others may simply just delineate between professional developers and so-called citizen developers — tech-savvy business stakeholders.
Platform due diligence policies
Not all low-code/no-code platforms or SaaS extensions are created equally — not only from a functionality but also a security maturity perspective.
“The maturity of current low-code platforms out of the box is, at best, nascent,” explains Thomas Segura, security expert for GitGuardian. “Many platforms do not inherently include the robust security features required to ensure compliance with stringent regulations and standards. They often lack sophisticated data governance tools, comprehensive audit trails, and the necessary encryption standards to protect sensitive information adequately. This lack of maturity necessitates that organizations take additional steps to bolster security and compliance when adopting these platforms.”
One of the first set of policies an organization will want to lay out is how much and what kind of vetting will be performed on platforms before they’re approved for use. This will help them find just how much security gap each platform will pose to their risk threshold and decide whether the juice is worth the squeeze.
Evaluation policies should stipulate an organization examines not only the security features and compliance controls of the platform, but also the security posture of the platform itself. This may include asking for documentation and potentially requesting permission to perform penetration tests, explains Walter Haydock, an experienced security consultant and founder of StackAware. He has been utilizing several low-code platforms in his development work recently and looks for this kind of assurance in the platforms he uses.
“So, Bubble for example, they have a stated policy on how you can conduct penetration tests against their platform,” Haydock tells CSO. “Xano, which is my back end, does have an ISO 27001 certification. So, they have had a formal audit of their security program, and they are pretty transparent in terms of their subprocesses and their tech stack and things like that. So that gave me confidence.”
Additionally, security teams will want to formalize an evaluation of how the platforms and the applications they produce handle sensitive data, as well as how nicely the platforms will play with existing security controls, GitGuardian’s Segura tells CSO.
“Organizations should perform rigorous security due diligence on any platforms they consider adopting to prevent data and PII sprawl, ensuring these platforms can integrate seamlessly with existing security infrastructures,” Segura says. “When necessary, self-hosting solutions should be prioritized to retain full control over data.”
Acceptable platform policies
Once use cases have been defined and the platforms currently in use have been vetted, then the business can get to work determining which no-code/low-code platforms are best suited to enable specific use cases. The more platforms that are in play, the harder it will be to manage the risks within the platforms and the applications that flow out from them. So, from a security perspective, keeping the list of acceptable platforms concise is ideal.
“Organizations should implement policies that centralize the development and deployment of low-code applications to manage these risks effectively,” says Segura, who prefers policies that select a single platform that best meets internal and external compliance requirements. “This policy would mitigate the risks of shadow IT, ensure uniform security practices, and simplify compliance processes.”
However, Bargury warns that at many organizations it will be unrealistic to expect a single platform (or even two or three at some larger enterprises) to adequately serve the needs of all the use cases across various groups and business stakeholders. He recommends taking a portfolio approach that focuses on meeting user needs in a risk-appropriate manner. He suggests picking a handful of platforms based on current usage and business needs and funneling development and security support to those. From that point, have security engineer ‘paved roads’ — guiderails for citizen developers and pro developers alike that make it hard to make insecure choices in how they use those platforms. This will take policy work, configuration work, customization and controls around the platform. The idea is to pick the platforms that take the least amount of work while still meeting the needs of each crucial use case.
As part of this set of policies, organizations should also define when it is ok to enable embedded or add-on low-code/no-code capabilities within generic software platforms or SaaS offerings and in which cases the security team will have those extensions disabled. For example, will it be ok to allow the business to run tools like Salesforce’s Business Rules Engine, a no-code rules automation tool? The policy should provide clarity and answer these kinds of questions.
Environment specification policies
One type of policy that Bargury recommends to limit risks is one that stipulates separate environments for pro developers and business coders. Ideally, when pro coders are using low-code tooling to help speed up their development work, the work product will still be running through a secure development lifecycle. Security policies and procedures should be established to implement security and quality gating at important points in the development lifecycle, and Bargury says organization should use runtime monitoring and other controls placed around what developers are pumping out of the low-code platform.
Meantime, citizen developer no-code workflows may be a little more lenient and as a result, enterprises should consider bulkheading that works. “Just try to compartmentalize. You can’t have everyone building in the same place because that’s just a recipe for disaster,” Bargury says, recommending compartmentalization of environments based on use cases.
Risk boundary policies
Breaking out different environments based on use cases can also help create risk boundary policies based on what and how the resultant low-code/no-code apps are actually doing once they’re live. Many successful organizations today are taking a lenient approach to building applications and then tightening the controls once the nature of the app is revealed, according to Bargury.
“They create environments where everybody can build applications without many barriers, but then once the application touches sensitive data or it’s shared with more than say 10 people, there are specific boundaries you can put onto the apps,” Bargury says. “When you hit those boundaries, you get an email saying, “You’ve hit the boundary. There’s another environment for you. We can move your infrastructure there, but here’s a security awareness training.”
Beyond the security awareness training boundary, others may require the business coder is paired with a pro developer to harden that app and maybe even refactor it altogether — using the no-code process as kind of skunkworks proof of concept generator. The app ‘graduates’ once it triggers certain variables. To make this work, an organization will first have to lay out all the triggers and path for risk escalation in a policy framework.
Data governance policies
Organizations should have very clear policies about data governance and compliance with regard to low-code/no-code platform, lest they run afoul of regulators. First and foremost the organization should stipulate what kind of data each platform will have access to.
If low-code/no-code apps are permitted to touch sensitive data and create apps that let that data flow through them, then an organization will need data governance policies and controls in place to keep track of everything in a compliance-friendly manner, warns Segura.
“One major risk is the dispersal of personally identifiable information and confidential data across a multitude of platforms, as the decentralized nature of low-code/no-code solutions makes it harder to track and secure sensitive information,” Segura says. “Consequently, organizations face challenges in maintaining data integrity and confidentiality, posing a substantial risk to their cybersecurity posture.”
Even with a robust set of embedded security controls, more mature low-code/no-code platforms may still need additional security or compliance tooling controls on top to fully meet data privacy and data security requirements laid out by GDPR, HIPAA, and CCPA, let alone internal requirements for SOC 2 or ISO 27000 compliance, says Youssef El Achab, cloud security and DevOps consultant for EFS.
“Some platforms are more advanced, offering encryption, role-based access control, and audit trails, which can help mitigate risks. However, these features might not cover all compliance requirements, and organizations must configure and customize them according to their specific needs,” El Achab tells CSO. “Organizations might not properly handle user data, provide adequate consent mechanisms, or maintain records of processing activities. This can result in regulatory fines and damage to reputation.”
Data governance policies should dictate when additional measures need to be taken.
Code testing policies
As organizations delineate use cases and platforms, they should create documented code testing policies based on the kinds of apps produced along each of those ‘paved roads’ mentioned by Bargury. The riskier use cases will require more testing procedures and also potentially regular penetration testing of the low-code apps that make it to production.
“Organizations should definitely do the same kind of security testing on their low-code/no-code applications and APIs that they do for traditional custom code software,” says Jeff Williams, co-founder and CTO of Contrast Security. “There’s no reason to believe that all the traditional vulnerabilities — like those in the OWASP Top Ten — are not possible in low-code/no-code apps.”
The problem with low-code/no-code is that there’s no easy button for plugging in unified security testing across every platform and use case. He believes security policies and testing procedures should be developed with the guardrail mindset that has already permeated a lot of modern DevSecOps work.
Some low-code/no-code platforms may include rudimentary testing or controls, and policy should stipulate that they’re enabled for users by default. Those likely won’t get an organization all the way across the finish line, though. Bargury argues that security and engineering teams should also be building mechanisms that test and enforce secure code and functionality standards automatically.
“We need to make sure that making the right choice is easy,” Bargury says. “Somebody from the sales team should not know how to store credit cards. This needs to be an automated guardrail, somebody needs to help them, it needs to be easy. It needs to be difficult to make mistakes.”
Access control policies
Ideally, organizations will approve and smooth the way for low-code/no-code platforms that take a mature stance on how their applications provision role-based access controls. Security policies should define requirements for access control, permissions and secrets management in low-code/no-code application environments.
“These need to include the ability to set security controls, building the app, signing the app as well as management and auditing roles for the system,” Appdome CPO Chris Roeckl tells CSO, of.
Organizations should lean toward platforms that make strong access controls easy to configure, because configuration is going to be half the battle here.
Haydock suggests that organizations have clear guidelines for permission hierarchies within applications that citizen developers churn out. “Thinking about your permissions structure and documenting that in a written policy is a best practice, but also documenting it in code (and default configuration), so to speak, to force compliance of that policy as much as possible,” Haydock says, recommending that organizations also create and enforce policies about how their low-code/no-code platforms and applications manage secrets like tokens and keys.
Enterprises need to be especially mindful of how low-code/no-code platforms share credentials across apps. Research Bargury’s conducted in the past shows that even the most reputable platforms will by default share a citizen developer’s credentials in the apps they produce such that the produced application completely circumvents role-based access control. This is a huge security blind spot that should be accounted for through policy, configuration, and enforcement controls.
Code ownership policies
One of the big issues of managing both the quality and security of low-code/no-code applications over time is around code ownership and responsibility. “You will get applications that will go viral, or applications that become business critical, but which were built by a business user who eventually moves to another role or leaves the company,” Bargury explains, saying then an organization gets stuck with snowballing technical debt because nobody is tending to that application.
To better enforce all the other policies delineated here, Bargury emphasizes that a company needs policies and procedures in place to establish ownership at the technical and business level of the various applications produced in low-code/no-code environments.
“People are right now struggling a lot with just this thing: ‘Who’s the owner for this application?’” Bargury says. “And I’m talking about both an owner in terms of who’s the developer or the technical expert for that application, but also who’s the owner in terms of the business leader.”
Enforcing these policies and tracking ownership poses a new technical problem because in traditional development an engineering team typically has a CMDB to act as a system of record. This kind of system doesn’t exist for a distributed portfolio of low-code/no-code apps produced by various platforms. But it’s a governance issue that does need to be solved not only for security’s sake but also to deal with other issues like quality, resilience and open-source licensing compliance.
Keep business users confined to no-code
One final policy to consider is being very clear about the use cases where low-code development is appropriate and where it is not. Many organizations create policies that dictate that business users should strictly be confined to no-code development and should not ever be handling code.
“When they’re going for custom components or something that involves code, this needs to be off limit for business users,” Bargury recommends.