Low-code/no-code platforms in general, and Workato in particular, have become highly popular over the last few years. The reason for this increasing popularity is enabling non-software developers to create automated flows (such as Workato Recipes), reducing repetitive manual work, and increasing productivity. Workato has an integrations directory that includes 1,000+ integrations to different SaaS applications and other enterprise services. These integrations, also known as connectors, allow easy connection to Workato to other services and to create powerful integrations without writing code. In addition, Workato includes pre-built recipes that even reduce the need for creating custom workflows with all the steps, and can help Workato users to unlock new use cases that they didn’t think of themselves, increasing the value of the platform.
While Workato is inherently secure, third-party vendors who have access to it through these methods can be a weak link. Inherently risky or over-privileged OAuth tokens, etc. can be exploited to gain the keys to the kingdom, placing Workato customers at risk of data breaches and account exposure. Supply chain access attacks against Workato are not properly covered by existing security approaches such as IdP (Identity Providers), CASB (Cloud Access Security Broker) and SSPM (SaaS Security Posture Management) solutions that focus on human-to-SaaS access controls and neglect the critical growing non-human SaaS-to-SaaS third-party integration layer.
One of the risks that comes with a low-code/no-code platform such as Workato, Zapier, Make and others, is the lack of security and compliance governance for citizen application development procedures. Developers outside of the engineering organization, also known as citizen developers, that use Workato do not use the CI/CD pipelines where secure SDLC is usually enforced and therefore most existing application security tools and procedures do not apply to them. In addition, citizen developers usually are less aware of security risks and potential consequences and in many cases their development processes are more prone to errors and misconfigurations. As an example, the well known Microsoft Power Platform misconfiguration, led to the exposure of 38 million records that included personal information for COVID-19 contact tracing and vaccination appointments, social security numbers for job applicants, employee IDs, names, and email addresses. A different type of risk that is incorporated with low-code/no-code platforms is targeting their keys to the kingdom to steal and abuse the OAuth and API tokens they hold to multiple business critical apps. That way, attackers can leverage an existing connection in order to execute lateral movement attacks and expend their permissions until a sensitive resource is obtained from a business critical SaaS application. Lastly, another risk that arises from low-code/no-code platforms is automated data exfiltration, the same as happened and identified by Microsoft’s Response team in the past. Attackers were able to stay in customers' systems for more than 7 months and steal data under the radar at scale by leveraging built-in Microsoft Power Platform capabilities that were not properly monitored.