Where There's No Code, There's No SDLC

We’ve come to rely heavily on the software development life cycle (SDLC) as the go-to method for getting security ingrained into development processes. In fact, the assumption of a comprehensive continuous integration/continuous delivery (CI/CD) has become so fundamental that we as an industry spent most of last year focused on addressing one of its derivatives: security of the CI/CD pipeline as the centerpiece of the software supply chain. This is good news, of course. A proper SDLC and its operational manifestation, the CI/CD, has allowed us to embed security controls where they are most useful — while developers are building and testing their software.

With the continued soar of low-code/no-code and citizen development in the enterprise, many AppSec teams have been occupied with creating secure development guidelines for these new business applications. Cross-industry collaborations have emerged to provide a security risk framework. The real challenge, however, is bringing this new wave of business users becoming developers under the security umbrella.

Business users are best at knowing what the business needs, and so they are best positioned to address those needs when empowered with low-code/no-code tools that allow them to build their own applications. On the other hand, trying to discuss security risks or development practices with business users can prove challenging.

Embedding security in the SDLC works because it is where it is more comfortable for developers to consume it, making it less costly to fix a security vulnerability. In order to do the same for business users, we must understand how their process for building applications works.

R.I.P. to the SDLC

A boilerplate version of the SDLC shows how software goes from articulating a need by the business; to planning, development, and testing by engineering and Q&A teams; to deployment, monitoring, and management by the operations teams. This, of course, varies widely across organizations. The important point for our discussion is that the responsibility is shifted among different teams and perhaps different departments throughout the development life cycle. Every transition can also be harnessed as a quality or security assurance gate, whether automated, like SAST/DAST/IAST tools, or manually, like threat modeling or security review.

In contrast, consider the low-code/no-code development process. A business user articulates their needs, moves on to creating their application or automation with an intuitive drag and drop interface, clicks save, and ... that’s it! Sometimes even the save step is skipped with a helpful autosave. Although not all low-code/no-code applications are built this way by the person who envisioned them, many are. Note how much faster the development process can be now — no exchange of responsibility or convincing someone else to align with your goals, and everyone can address their own business needs as they are spotted, on their own. This is the power of business-led development and mature citizen-development initiatives.

Unfortunately, it comes at the cost of skipping those security and quality gates we’ve baked into the development life cycle. These gates were critical, especially in an enterprise that needs to enforce values that are just as important as business productivity: security, compliance, and privacy, to name a few.

Meeting Developers Where They Are

Business users are building and will continue to build more applications than we’ve ever seen before. To bring them under the security umbrella, we must meet them where they are and speak their language. Instead of relying on the existence of a CI/CD pipeline and introducing business users to concepts like production versus test environments, we should accept reality and focus on making it easy to create secure applications and difficult to create risky ones.

To do this, we must understand the low-code/no-code platforms they use to build applications and the ways in which these applications are built and adopted by others. We must embrace our responsibility to guide these new developers, apply security best practices to the applications they create according to our organization's risk appetite, and take a retroactive approach to address critical issues swiftly.