“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.
