Sharing structured data

XML Magazine

Subscribe to XML Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get XML Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


XML Authors: Jayaram Krishnaswamy, Chris Pollach, Jason Bloomberg, Peter Silva, Mehdi Daoudi

Related Topics: Intel XML, XML Magazine, Agile Digital Transformation

Blog Feed Post

Unsung No-Code Benefit: Application Security

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.

Read the original blog entry...

More Stories By Jason Bloomberg

Jason Bloomberg is a leading IT industry analyst, Forbes contributor, keynote speaker, and globally recognized expert on multiple disruptive trends in enterprise technology and digital transformation. He is ranked #5 on Onalytica’s list of top Digital Transformation influencers for 2018 and #15 on Jax’s list of top DevOps influencers for 2017, the only person to appear on both lists.

As founder and president of Agile Digital Transformation analyst firm Intellyx, he advises, writes, and speaks on a diverse set of topics, including digital transformation, artificial intelligence, cloud computing, devops, big data/analytics, cybersecurity, blockchain/bitcoin/cryptocurrency, no-code/low-code platforms and tools, organizational transformation, internet of things, enterprise architecture, SD-WAN/SDX, mainframes, hybrid IT, and legacy transformation, among other topics.

Mr. Bloomberg’s articles in Forbes are often viewed by more than 100,000 readers. During his career, he has published over 1,200 articles (over 200 for Forbes alone), spoken at over 400 conferences and webinars, and he has been quoted in the press and blogosphere over 2,000 times.

Mr. Bloomberg is the author or coauthor of four books: The Agile Architecture Revolution (Wiley, 2013), Service Orient or Be Doomed! How Service Orientation Will Change Your Business (Wiley, 2006), XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996). His next book, Agile Digital Transformation, is due within the next year.

At SOA-focused industry analyst firm ZapThink from 2001 to 2013, Mr. Bloomberg created and delivered the Licensed ZapThink Architect (LZA) Service-Oriented Architecture (SOA) course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, which was acquired by Dovel Technologies in 2011.

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting), and several software and web development positions.