Low-code has many benefits, and they’ve been widely discussed in a number of articles here on SD Times, but one area in which they don’t really have an edge is security.
It’s not that low code is more risky than traditional code, but the same risks are there, Jeff Williams, co-founder and CTO of Contrast Security explained. These include things like authentication, authorization, injection, encryption, logging, etc.
Even developers who spend their whole days writing code have very little security training, for the most part, and often they don’t even have much communication with the security team. One main difference between the two groups is that citizen developers might be more likely to accidentally introduce a security risk, explained Williams.
RELATED PODCAST: Low-code and the relationship between citizen developers and security
“I would expect citizen developers will make a lot of the basic mistakes such as hard-coded and exposed credentials, missing authentication and authorization checks, disclosure of PII, and exposure of implementation details,” said Williams.
According to Mark Nunnikhoven, distinguished cloud strategist at Lacework, access to data is also a big issue to consider, especially when you’re giving citizen developers access to data in systems they hadn’t previously encountered. It’s important to both restrict access to only what is needed and teach citizen developers the appropriate use of the data connections they have access to. “We don’t teach you like, ‘hey, you’ve got access to all of our Salesforce information and here’s what appropriate use looks like.’ We just say, ‘oh, you’re in sales or in marketing, and you should have access to that, so here you go.’”
Nunnikhoven explained that this is a huge problem in low-code development because suddenly low-code developers have the ability to access and manipulate data and connect to other systems, and if they don’t understand the appropriate use of that, they won’t understand the inappropriate use of it either.
“I think that’s the real challenge with these platforms,” said Nunnikhoven. “It’s exposing a gap in our information management or our information security programs that we don’t often talk about, because we’re so focused on the cybersecurity and the nuts and bolts of how we secure digital systems, not the information in those systems.”
Jayesh Shah, SVP of customer success at Workato, also advises customers to develop a certification program specific to the low-code platform that will be in use so that the people who will be working with it understand the capabilities and can more easily stay within the policies and guardrails laid out by the company.
Process of security doesn’t change much
Even though the way of building the application is different when you’re talking about low code versus traditionally coded apps, the process of security should be the same.
“Fundamentally the challenge for companies of all sizes is to define their specific level of security, test against that definition, and fix problems,” said Williams.
He recommends that companies set guidelines for exactly how they will use the platform. For example, how should users be authenticated? How is input validated? How are credentials stored?
After setting these guidelines, it’s important to test to ensure that developers are implementing them. These tests can be automated using instrumental application security testing (IAST), which analyzes the entire application as it is assembled. Methods like static application security testing (SAST) and dynamic application security testing (DAST) might miss real issues and report false positives, Williams explained.
In addition to having good policies within your company, the low-code platform itself can also minimize security risks. For example, according to Shah, the platform can incorporate its own security controls, such as requiring citizen developers to work in sandbox environments or limiting their options.
According to Shah, one area in which low code may have the edge over traditional code is that when a new vulnerability is discovered by the security community, custom software isn’t likely to be updated in a timely manner, while a low-code platform could be updated by the vendor to minimize or remove that vulnerability, Shah explained.
“The low-code platform can ensure that the platform components it provides do not have security vulnerabilities and are patched and updated as necessary to benefit all users globally,” he said.
Shah added that while traditional development might offer greater flexibility in terms of what can be created, that freedom also brings a broader level of responsibility. Custom software often incorporates third-party or open-source components, which are notorious for being weak points for vulnerabilities, he noted.
OWASP Top 10 expands to low-code
The OWASP Top 10 is a list of the ten most common security vulnerabilities in code. Recently, work began on an OWASP Top 10 list specifically for low code, with the same idea as the original guide but focused specifically on low-code risks.
“You as an organization that is adopting low code/no code should be able to look at the OWASP Top 10 and say, ‘Here are the main security concerns, as agreed by the experts in the community, how am I going to address these within my environment?’” said Nunnikhoven.
Here are the top 10 risks specified by the guide at the time of this writing:
- Account impersonation
- Authorization misuse
- Data leakage and unexpected consequences
- Authentication and secure communication failures
- Security misconfiguration
- Injection handling failures
- Vulnerable and untrusted components
- Data and secret handling failures
- Asset management failures
- Security logging and monitoring failures
In theory the OWASP list would give companies a set of items to focus on in their security strategies, but Williams, who created the original guide back in 2003, said that’s not really the case, unfortunately. He said that’s what he thought would happen when he wrote the guide, but that he’s “still waiting” for that.
He added: “I think OWASP helps to raise awareness and understanding around risks, but it doesn’t seem to translate into a significant decrease in vulnerabilities. I think it only really works if platform vendors take the advice and build better guardrails into their own specific environments.”
