DevOps and Open Source Software Continuous Compliance
0 likes264 views
DevOps aims to rapidly develop and deploy software applications through cross-company collaboration. While open source software allows for faster development, it can introduce legal, security and operational risks if not properly managed. The document proposes integrating continuous compliance checks into the DevOps process to proactively monitor for risks from open source components throughout development. This catches issues earlier and avoids delays from fixing problems found later through audits. It recommends pre-approving open source packages and monitoring components for policy compliance and vulnerabilities to balance rapid development with risk management.
DevOps and Open Source Software Continuous Compliance
- 1. 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.
- 2. 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.
- 3. 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
- 4. 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.