DevOps and Open Source Software Continuous Compliance

Introduction The term DevOps (Developer Operations) has been around as a concept since around 2009 and has

quickly evolved into a broadly adopted practice within many organisations. It is an evolution of

software development practices such as Agile and IT operational practices such as ITIL Service

Management (and their related standards e.g. ISO/IEC 20000 Standard for IT Service Management).

The need for DevOps is driven by new areas of technology such as cloud computing, mobile

applications, Big Data, and social media. These technologies have created the requirement for rapid

delivery of innovation or in other words to develop and deploy software applications at a faster.

Some organisations have moved from upgrading applications annually to in some cases daily.

DevOps requires cross company collaboration involving the likes of product management, software

development and QA, IT operations and end users.

Rackspace published a DevOps Automation Report in

2014http://www.rackspace.co.uk/sites/default/files/devops-automation-report.pdfwhich gives a

global view of how and why organisations are adopting DevOps. Chris Jackson from Rackspace sums

up the drivers for DevOps in this quote:

“The momentum behind DevOps is driven by a perfect storm for disruption based on Internet

business and collaboration technologies, open source software” Chris Jackson CTO DevOps Services

RACKSPACE

DevOps and Open Source Software Development Open Source Software is now broadly used in the development of software applications. The ability

to reuse components of code already created allows development teams to create more code, with

more functionality, faster. It also promotes the adoption of standards and makes applications more

interoperable.

Although Open Source Software components typically require no licensing fee, it does come at a

cost. This cost is uncertainty – or perceived uncertainty in many cases. That is, uncertainty of the

ownership structure, of the licensing terms, of the stability of the code. Most software developers

will be meticulous about what components they use from the perspective of functionality as they

want to build code that works.

However those Open Source Software components could have inherent business risks associated

with them which should not be solely down to individual developers to be responsible for. Those

risks are:

Legal risk/licence IP compliance – Open Source Software components license analysis

discovers legal obligations as well as potential intellectual property (IP) risks.

Security vulnerabilities - uncovers security vulnerabilities contained within Open Source

components.

Operational risk - Ensuring Open Source Software components meet required technical and

architectural standards.

Organisations should have Open Source Software policies that govern how developers use Open

Source Software components. These policies should be included in DevOps. Figure 1 shows a typical

DevOps process where the focus is on Continuous Delivery driven by the pressure to rapidly build

and deploy applications and updates to applications. It is not uncommon for there to be no focus on

the risk highlighted previously that could be being engineered in to the source code of the

application.

Figure 1 – Standard DevOps Process

One way to address the code risk is shown in Figure 2. Here there is a source code review or audit at

the end of the development cycle prior to releasing an application to the operations team to deploy

to end users.

This is to all intents and purposes a discovery task which will identify individual Open Source

Software components in use and the whole chain of dependencies that these components require in

order to function correctly. Any risks should flagged in line with requirements defined in the

organisation’s Open Source Software Policy. (If there is no policy this will need to created and

communicated across DevOps stakeholders). If there are issues in the code then the release will

have to be delayed while development remediate the issues. Although this is avoiding risk for the

organisation it is not the most efficient way controlling source code risk in DevOps.

Figure 2. DevOps process including Source Code Audit

When is the right time to be concerned about Open Source Software component risk? The earlier in

the DevOps cycle issues are located, the less impact it will have on development, DevOps as a whole

and ultimately on meeting business deadlines. Equate finding licensing irregularities, problematic IP,

or potential security vulnerabilities in a software application to finding a bug in a software

application. The earlier it is discovered the less expensive and impactful it is to correct.

A more efficient DevOps process including pro-active Source Code monitoring is show in Figure 3.

This could be thought of as continuous compliance in a DevOps implementation. In this model there

is monitoring of Open Source Software components throughout the development cycle. The first

stage to implement Component Package Pre-Approval which if implemented well should head off

issues from a risky component being integrated in an application. This is where a developer must

have approval from a designated manager to use an Open Source Component package in their code.

As stated earlier there would need to be a policy the manager is guided by to accept or reject the

request. Typical information that would enable a decision to be made would be

Project & Package Information

Project name, URL, license, author(s), type, exportability, etc.

Usage Model

Distribution model

(Binary, source, hosted, internal only, etc.)

Types of derivatives

(Modified? Linked? Loosely coupled?)

Organization specific information

Business unit

Business justification

Support and maintenance

Maintenance and support

Figure 3. DevOps Process with proactive Source Code management or Continuous Compliance

Conclusion DevOps and the use of Open Source Software to create applications have significant benefits.

However there are inherent risks in Open Source Software components which could be engineered

into deployed applications. The earlier Open Source Software component risks and vulnerabilities

are captured the less impact on meeting deadlines there will be. Developers should be focussed on

their core function which is creating great applications that deliver the business value required by

end users. The DevOps process and proactive risk management of source code should minimise the

overhead to development teams and individual developers and maximise their productivity.