I’d like to start this BrainBlog post with a horror story.
Let’s say you’ve assigned a junior php developer (let’s call them Chris) to hand-code a simple HTML form submission script. One of the HTML form fields is called ‘name,’ so Chris writes the following snippet of php to process that particular field:
$_GET[“name”];
The form passes unit tests, so Chris moves onto the next task. A few days later, the php code makes it into production. The end.
Scary, right? Just in case you missed the frightening part of this story, let’s point out that Chris did just about everything wrong from a security perspective.
The choice of GET instead of POST exposes the value of the field to anybody casually snooping. Even worse, Chris didn’t write any code to sanitize the contents of the field, allowing anyone to enter malicious JavaScript, SQL, or worse.
In other words, Chris just opened a door so large that hackers could drive a tank through it.
You might wonder why the creators of php made it so easy to introduce such a vulnerability. After all, php is simple enough for even quite junior developers to get the hang of the basics quickly – and those are just the sorts of people who may not be savvy enough to secure their code.
The root of the problem: in the inexorable progress creating programming languages that are increasingly easy to use, they have also become increasingly easy for newbie coders (among others) to screw up security.
And yet, the answer is certainly not to make coding more difficult. We’d end up scaring off the junior folks with no guarantees the senior team is going to get the security right, either.
No-Code: Easy and Secure – at the Same Time
One little-recognized solution to this problem of easy vulnerabilities is to use a no-code platform to build applications. After all, no-code platform vendors have historically targeted business users or ‘citizen developers’ to assemble applications for themselves in straightforward, drag-and-drop visual environments. Nobody would expect such people to know the ins and outs of application security.
Today, the ‘lightweight’ connotation of no-code is rapidly shifting. The current generation of no-code tools are becoming increasingly sophisticated and powerful – and as a result, professional developers are also taking advantage of such platforms.
And this transition to no-code couldn’t come at a better time, because one of the most important benefits for both citizen and professional developers to use no-code platforms to build applications is security.
Not only do such platforms prevent boneheaded mistakes like the one above, but they can also catch other, more subtle vulnerabilities as well.
Not Just for Newbies
Professional developers are supposed to know the ins and outs of writing secure code, but the fact of the matter is that such expertise is a specialized skillset, and furthermore, one that many developers aren’t particularly interested in.
And yet, the traditional approach to enterprise application security – shipping all code off to a security team for review and signoff – is fraught with issues. Such signoffs create an adversarial relationship between the appdev and appsec teams, and the entire process slows everything down.
Regardless of where the organization is on its road to DevOps, no one wants us-vs-them thinking or procedural roadblocks interfering with efficient, rapid software development. On the other hand, nobody wants to risk releasing vulnerabilities into production, either. No-code can solve all of these issues.
Application Security – An Inherently Dynamic Target
There is more to this story than simply preventing people from writing insecure code. True, drag-and-drop assembly of functionality will never result in the php vulnerability above, but the greater application security challenge is the fact that new, ‘zero day’ vulnerabilities crop up all the time.
When such a vulnerability appears in some part of the underlying software infrastructure, enterprises must respond promptly by applying the appropriate patch. Even a brief delay can lead to fiascos like the recent Equifax breach, to name a particularly egregious example.
The vulnerability in Equifax’s case cropped up in Struts, a piece of open source middleware, and the team responsible for that bit of code promptly patched it. Equifax, however, didn’t apply the patch in a timely manner – an appallingly common occurrence.
Declarative Metadata-Driven vs. Code Generation Platforms
Contrast the Struts story to what happens when a no-code platform vendor identifies a zero-day vulnerability in their platform. They promptly patch it – and as a result, the vulnerability is automatically and immediately patched for every one of the vendor’s customers.
There is just one caveat to the statement above: not all no-code platforms work the same. Some of them generate running code, while others like ClaySys create metadata representations of the applications that execute in real-time on the underlying platform.
Both approaches have their advantages and disadvantages. The code generation approach can produce standalone applications independent of the underlying platform, thus making them especially suitable for building native mobile apps, for example.
However, if a vulnerability creeps into a code generation-based platform, the vendor must patch the platform, and the application builder – that’s you – must recreate all of the running apps in order to incorporate the fix.
If you delay for any reason – even for a day – then any or all of your apps may be vulnerable to attack.
Metadata-driven platforms like ClaySys resolve this issue. Because the platform represents all of your application functionality in a document format – typically JSON or XML or the like – all the vendor has to do to ensure your running apps are secure is to patch the underlying platform. No rebuilding of apps required.
The Intellyx Take
The potential drawback of using a metadata-driven no-code platform to build your applications is that they must run on the platform – so such platforms aren’t suitable for standalone apps that must be able to run disconnected from the Internet.
The sorts of apps that such platforms are suitable for, however, are quite broad, and includes most enterprise applications. Furthermore, if you’re not comfortable depending on a third-party platform running in the cloud, there is usually an on-premises option, allowing you to run the entire platform in your own data center or private cloud if you prefer.
In such cases, your ops team would be responsible for applying security patches – but even in this situation, patching the platform once would automatically and immediately secure all the apps running on the platform, regardless of their location or the level of technical sophistication of their creators.
Copyright © Intellyx LLC. ClaySys is an Intellyx customer. Intellyx retains final editorial control of this article. Image credit: Paul Inkles.
