I Don’t Get It

I don’t get it.

Call me a boomer, call me old, call me old-fashioned, call me a dinosaur. But at least respect the 40-plus years I’ve spent in the IT industry doing business application development with almost 30 years responsible for different site’s Source and Configuration Life-cycle Management (SCLM), now more fashionably called Development Operations (DevOps).

I know a thing or two about DevOps, especially its evolution from z/OS platforms and “adoption” on distributed platforms.

I do not understand the enterprises that accept the perversion of the discipline of DevOps auditing requirements on distributed platforms. I understand why it’s happening, but I point the finger squarely at the current crop of IT auditors and their ongoing hesitancy to call a halt to what is (in my opinion) going to ultimately be an unmitigated disaster.

Years ago, when I started in IT, auditors did what was known as comprehensive Software Change Management Audits. This covered various aspects of DevOps designed to mitigate risks associated with changing software. It was the early days of Trojan Horses (hidden code that benefitted a 3^rd party at the expense of the enterprise), lost source, and mismatched/untracked source-to-executable (to name a few of the dawning “issues”).

Many sites failed these audits, driving a need to address these risks effectively.

Most sites looked to software vendors to provide comprehensive tools to support features, functions, and abilities to address or at least reduce the chance of issues at their site.

More importantly, however, they looked to vendor solutions to provide security, support, stability, and “bullet-proof” software for which the vendor could be held accountable.

Yes, these vendor “safes” were expensive. But they more than did the job. In conjunction with changed processes, they more than adequately addressed the issues that were rising. Products such as Endevor answered the need of the auditors and those on-site responsible for delivering vetted code (albeit accepting that no code is vetted if reviewers don’t actually review!).

Then along came the distributed platforms….

At first, this new crop of platforms was expected to follow the same set of rules as the old platforms. Vendors responded accordingly; each vendor had a tool that would deliver most of the same features and functionality. Legent and then CA offered “Endevor Workstation”. Later, after the purchase of Platinum, CA offered “Harvest”.

Each vendor solution offered the support of a dedicated team committed to ensuring the viability of both their product as well as the enterprise’s. Each had a vested interest in the other and most audit requirements were met.

Then we hit “Agile Development”, the rise of the young recently-graduated developer, and, finally, “open source”.

First, “Agile”….

Now, as an “old guy”, I would argue there is nothing new under the sun. In the “old days”, we called “Agile” by different names; JAD (joint application design), RAD (rapid application development)… to name just a couple. But as an application developer, I got it…. I understood the pushback to waterfall methodology and the seemingly endless paperwork and red-tape needed to get anything done.

That said, the need for iterative development does not supersede the needs of proper and secure controls, processes, and configuration management. If ever there was a need to have supported back office software, it is now. Most enterprises are not in the business of “rolling their own” when it comes to process support software and the need for an identified and accountable vendor to provide that back office software has (arguably) never been greater.

Second, the rise of the young recently-graduated developer….

Most enterprises are actively (or passively) “getting off the mainframe”. That’s been the story for almost 30 of my 40 years in the industry. So I’ll leave my thoughts on that topic for some other future blog.

The colleges and universities have done no one any service by undermining the z/OS platform in its offerings. Most graduates today have little knowledge of the platform that sent man to the moon but are very acquainted with the platform that gave us Mario Kart.

I get it. Distributed platforms are sexy. There’s an immediate gratification to seeing something you’ve coded be completely under your control doing whatever you want on your system. You’re operator, systems programmer, developer, and user all rolled into one!

Third, and arguably most insidiously, “open source”….

Let’s first be clear on what “open source” means.

“1. Free Redistribution

“The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

“Rationale: By constraining the license to require free redistribution, we eliminate the temptation for licensors to throw away many long-term gains to make short-term gains. If we didn’t do this, there would be lots of pressure for cooperators to defect.

“2. Source Code

“The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed…..” https://opensource.org/osd-annotated

It seems to me that the combination of “free distribution” and “source code” has become a siren’s song to the colleges and universities that are creating the IT professionals of tomorrow. As centers-of-excellence, they have instilled a sense of “rightness” about using “free software” to which “anyone can modify”.

When I worked at CA, we used to say “you get what you pay for” with no one expecting any enterprise would possibly subject itself to relying its business on “open source” software.

My, how things have changed!!

Fast forward to today, and the distributed software DevOps environment is rife with “open source software” providing the back office applications (and processes) that drive many businesses applications today.

Think about that for a moment…..

Enterprises allow or are allowing the introduction of software that can be changed by anyone anywhere in the world in an unaccountable manner. Software that controls the software developers are creating that drive the business of the enterprise. Software that no one ensures source-to-load integrity.

I don’t get it.

Where are the auditors? Why are they accepting such a dangerous environment to make its way into their businesses?

Where is the demand for proper and secure (and arguably proprietary) storage methods? Build methods? Component tracking mechanisms? Accountability for ALL components in the development cycle?

Sure, you can find free open source software to provide those functions…. But that’s the point! They’re open source! So how do you know (and I mean really know) there isn’t imbedded “ET call home” commands buried in there? You trust an open source community that much??

It’s like HIPAA or Sarbanes-Oxley never happened!

I don’t get it.

Yes, I recognize that vendor provided software configuration management (SCM) software is not as necessarily “flexible” or “easy to use” as what the young developer learned using open source solutions at their local college/university.

But this isn’t academia we’re talking about; this is now the real world.

My own opinion is that any site that uses open source software for more than just a pass through to vendor supported software running as the engine is playing with fire. The bottom-line is you do not and cannot know the integrity of open source software and you cannot hold an “open source community” accountable if someone sneaks through a malicious code element.

With a vendor, you have an accountability trail.

I don’t get it.