As the popularity of no-code and low-code tools grows, so, too, do security concerns
The demand for new applications is growing at a rapid rate. Many individuals and business units will not tolerate delays. As a result, citizen developers are stepping in, some of whom may be sanctioned by the company while essentially operating as shadow IT.
Common to both groups is that they increasingly are aided by the wide availability of no-code/low-code development tools and platforms on the market today. Such solutions abstract away many coding tasks, offering developers a visual studio or palette to create applications by dragging and dropping software components and smaller apps.
No-code/low-code tools offload tedious chores from professional developers, allowing them to work more efficiently. For those without that expertise, these tools enable people who have intimate knowledge of the business create their own applications and automate processes.
Development is not only faster but less structured. As such, these technologies in the hands of those not trained in security can introduce risk.
There are many ways citizen developers can expose a business to cyber risks. One common issue in many companies is that citizen developers (like their professional counterparts) do not want to reinvent the wheel. If they can find an existing or open source component to an application, they might freely use it when developing an application. For example, rather than hard coding a front-end mobile user interface for different platforms, they may just take existing ones and use them for their new applications. Similarly, if they want their application to perform real-time analytics, they could use an open source events stream engine. And if they want to create an interactive chatbot, they might use open source cognitive apps. The problem is that they select these no-code/low-code apps with very little vetting of the code components they’re using.
Another common issue is that a citizen developer might ignore built-in security features in a component that makes up their composite application. For example, they may choose not to password-protect a database to simplify its use. Or they may decide to forgo best practices and send data across public networks unencrypted.
There are many choices like these where attention to security is needed. Yet, most citizen developers do not even know to be on the lookout for potential security weaknesses.
Layering in Security Before, During and After Apps Are Created
Obviously, citizen developer applications must be tracked, vetted and fixed before potential vulnerabilities are exploited by attackers.
To do that, security needs to be integrated throughout an application’s life cycle. It is no longer enough to only test for vulnerabilities after an application is developed and let it operate unchecked forever. Additionally, security must be real-time instead of reactive. It must constantly examine the elements of an application as they operate and are modified.
Cobbling together components using no-code/low-code techniques introduces additional issues. While the individual components may be trusted, the use of several components together might expose data or provide a weakness that can be exploited. Additionally, a composite application that is secure today may no longer be so if a new vulnerability emerges for one of the software elements within the application.
What many organizations are finding is that they need to marry DevOps and security. Hence, the growing focus on DevSecOps in the industry. DevSecOps is increasingly necessary to find weaknesses and vulnerabilities in modern applications composed of loosely coupled components.
The constant refreshing, updating and replacement of applications dictate that security must be an integral part of the entire life cycle of an application. Again, another reason to bring security into the application life cycle, just as DevOps does for development and deployment.
And the complexity of applications built, even when using low-code/no-code methods, means security needs to be more sophisticated to understand hidden dependencies in today’s loosely coupled applications. Any security solution cannot be passive. Simple scanning for known vulnerabilities is not enough. A solution must understand the way components of a citizen developer application change over time and interact with one another.
The bottom line is that cybercrime protection must be implanted at the code level, and secure coding practices must be instituted, especially when citizen developers are driving application development.
