I was intrigued by an article I read the other day in CSO Online titled “4 security concerns for low-code and no-code development”. The premise of the article was, essentially, that enterprises must beware of low-code solutions, because they can cause security concerns.In the article, author Chris Hughes says, “By allowing more people in an enterprise to develop applications, low-code development creates new vulnerabilities and can hide problems from security.”I fundamentally disagree with this premise. Specifically, there is nothing inherently secure or insecure about low-code or no-code solutions. The key to all application development frameworks, systems, processes, and policies—manual or automated—is that they are as secure as the enterprise invests in making them secure.Yes, reducing the number of people in your organization who are capable of building applications reduces the likelihood that an application will have a security vulnerability. However, using that logic, the best way to make your applications secure is to reduce the size of your engineering team so it produces fewer applications. The fewer the applications, the fewer the security problems from those applications. While this is a true statement, it’s hardly a useful one.This argument provides a limited view of application development. A good CSO encourages the growth of the organization rather than stifling it. Yes, a larger, faster-growing organization has tougher security concerns to deal with. Improving application security by focusing on limiting what an organization can build is not the way for an effective CSO to contribute to the success of a company. The best CSOs find a way to solve security problems inherent in growth opportunities.The same is true with low-code. By enabling so-called citizen developers to build and expand applications useful to the enterprise, your company enables growth. The CSO—and the rest of the IT leadership team—should be focused on making this easier by providing high-quality, reliable, and secure low-code development platforms for your citizen developers to leverage. This is the best way to avoid security vulnerabilities. How do you do that? Rather than pushing back against the use of low-code development tools, work on bringing enterprise-grade low-code development tools into your company, enabling users to learn how they work, and encouraging their use. Then, at the same time, work toward making sure the environment these tools provide is safe and secure.Rather than relegating low-code development to the murky world of shadow IT, this strategy puts low-code front and center and encourages its use—under the purview of the CSO, security department, and the rest of the enterprise IT organization—which will allow your company to grow. This growth leverages the value of a citizen developer workforce that strengthens, enhances, and multiplies the value of the rest of the development organization. Low-code is just another toolThink back to the early days of computing, when developers wrote their programs in assembly language or machine language. Developing in these low-level languages was difficult, and required highly experienced developers to accomplish the simplest tasks. Today, most software is developed using high-level programming languages, such as Java, Ruby, JavaScript, Python, and C++. Why? Because these high-level languages allow developers to write more powerful code more easily, and to focus on bigger problems without having to worry about the low-level intricacies of machine language programming.The arrival of high-level programming languages, as illustrated in Figure 1, enhanced machine and assembly language programming and generally allowed less code to accomplish more. This was seen as a huge improvement in the ability to bring bigger and better applications to fruition faster. Software development was still a highly specialized task, requiring highly specialized skills and techniques. But more people could learn these languages and the ranks of software developers grew. The age of the productive software developer was born. IDG
Figure 1. Early development tooling.
Eventually developers started writing larger and more complex applications. They started creating programming platforms, frameworks, and toolsets to improve their development abilities. Frameworks such as ASP.NET, Ruby on Rails, jQuery, Spring, and React.js allowed developers to build higher-level applications more easily. Then, SaaS and cloud services added more capabilities to the developer’s arsenal.All of these higher-level tools and services, as illustrated in Figure 2, enhanced the development experience and continued the trend of allowing less code to accomplish more. This was a huge improvement in the ability to bring even more complex applications to fruition faster. It was not only easier to build high-value applications, but also required less training to become a skilled developer. Less training meant that there were more software developers available. The age of SaaS and cloud-based applications was born. IDG
Figure 2. Expanded development tooling.
Time marches on, and developers have started writing larger and more complex applications. Artificial intelligence and machine learning capabilities are starting to see traction, and low-code and no-code tools increase the developer’s ability to build more complex applications. These tools, as illustrated in Figure 3, enhance the capabilities of other development tools, continuing the trend of allowing less code to accomplish more. They also open up development to less experienced developers. Now, someone without direct, focused training as a developer can build applications that perform advanced tasks. The age of the citizen developer is born. IDG
Figure 3. Modern development tooling.
There is nothing fundamentally new or novel about the citizen developer. It’s just the latest iteration in the evolution of the software developer’s role. There’s nothing in this progression of software development that makes low-code or no-code any more or less dangerous, more or less secure, more or less useful, than any of the other development improvements that came before it.Saying that low-code and no-code tools are fundamentally less secure or less useful or less safe than earlier tools is hypocritical. They are an evolving set of tools that all enterprises need and will depend on as we move forward.Low-code shall overcomeIf low-code doesn’t differ from other development environment improvements, then why is there so much hype against low-code? It’s not unusual or unexpected. In their day, each of these new layers confronted the same pushbacks. It wasn’t so long ago that we “didn’t dare” consider the cloud for enterprise IT usage, or consider using React for a serious enterprise application. I also remember the days when Java was the only language considered safe enough for enterprise IT development.And what about the worry that low-code enables shadow IT? Well, it wasn’t so long ago when cloud computing was considered shadow IT, or when a “new and novel platform” such as Ruby on Rails or React could only be used in non-official applications.Low-code, no-code, and AI-assisted development tools are here to stay, and they will continue to grow in importance. Enterprise IT departments and enterprise security departments will be behind the times unless they reach forward and help drive the growth of these platforms, rather than drag their heels and hope they go away.Handled appropriately, low-code poses no additional security risk over any other platform, system, or development environment. It gives you no more operational risk or unmanaged cost. The key is to handle it appropriately. If low-code is allowed to become a vessel for shadow IT, then it can be just as insecure as any other shadow IT project. If low-code is allowed to become unmonitored and uncontrolled, then it can be just as insecure as any other unmonitored and uncontrolled process.Low-code development tools and platforms have matured to the point where they can be trusted. This is especially true when running with high-quality, enterprise-grade low-code systems from established vendors.
Copyright © 2022 IDG Communications, Inc.
Source link