DevOps Inadvertently Opens Up New Challenges: How to Resolve Them

App modernisation for cloud will continue to be a big driver in 2021. The world of developers has moved on massively since the early days of COBOL programming and large monolithic code bases.  ISVs and their clients are reviewing the way applications are written and updated to take advantage of modern services and infrastructure options.  The move to use a modular and API-driven technology approach is facilitated by modern GUI developer tools and cloud services, and modern software development will predominantly use open source components and libraries.

However, the new approach can inadvertently introduce risk to ISVs and their clients if security is not part of the build process. In this blog we’ll explore the risks, and how to mitigate them.

Open Source Saviour/Sinner for Developers 

Modularisation of the applications and API code for using services or application integration have opened up two potential areas of challenge regarding security and risk when open source code is used. A recent Forrester report quoted modern applications typically composed of 90% open source 10% proprietary. Legacy applications were 10% open source 90% proprietary. Vulnerabilities within open source code can expose an ISV and its clients to cyber-attacks and legal challenges.

Expedited code development to meet deadlines or unexpected requirements can also introduce security vulnerabilities over time, and these vulnerabilities need to be identified and managed. At Six Degrees we answer this need with our advanced Managed Detection and Response (MDR) capabilities which actively seek out vulnerabilities. It is advancements like these that mean vulnerabilities become visible in a timely fashion.

However, clients using open source code do not necessarily know the version and vulnerabilities that might be present in their IT landscape; some of the famous hacks that have exploited vulnerabilities in client environments have had patches or fixes for a long time.

Open Source Vulnerability Audit/Scan

Visibility of what and where open source code is being used is becoming an important part of managing security risk within a client’s security posture. In some cases, the risk has been recognised by compliance organisations and regulators, with requirements being introduced for managing the risk associated with vulnerabilities in open source code.

A point in time application assessment will identify current risk and version diversity, enabling clients to remediate the known risk at that point in time. However, the IT landscape is constantly changing as new code is used or vulnerabilities identified. It is therefore important to view this as a regular service task requirement for clients, enabling an audit of where code is being used and therefore the risk associated with vulnerabilities can be managed to meet the compliance requirements.          

License Management 

The use of open source code can also introduce risk through the license agreement associated with the code. Code developers can specifically include a customised license for the code if specific to a vendor or application. However, there are implied licenses for many other components when they are made available through the open source route. There are over 2,000 documented open source licences with varying obligations from copyright attribution to an obligation to disclose source code.

There have been famous cases where clients have had to contest in court situations where the end-user license agreement has made provision for changes and use clauses for the open source code. This has led to fines or expensive code changes. As part of the regular vulnerability audit or review process there must be consideration for user licenses to be managed in parallel, helping to identify any risks associated with the use of particular components, or API integrations which have been gifted to the open source community. 

Because of the risk associated with vulnerable components, industry bodies including NIST, FDA and PCI are forcing tracking of open source.

Open Source Risk Management

The use or reuse of open source components directly or through their inclusion in black box application packages should be reviewed with a risk lens for both vulnerabilities and the legal precedent included in the open source licence. Is it right for developers to choose what components and libraries to use in a code without any guidance on business risk?       

When planning the modernisation of applications where new code or integrations are required, the open source route is very compelling. However, the processes should ideally be put in place for an internal or third party organisation to help manage the use of the open source code.