DevSecOps series: your software is built on unknown, untrusted and potentially vulnerable code

Publish date:

Click here to take our online assessment. It’s free, anonymous, and allows you to benchmark your DevOps maturity against other organisations and industries.

The principles that characterise DevSecOps are based on combining the DevOps and the CAMS principles – culture, automation, measurement, and sharing, but with the addition of adding security from the start and throughout. However, we have learned that one aspect of development proves to be difficult to track:  the use of open source software (OSS) components, see Figure 1.

Figure 1: DevSecOps development lifecycle & the introduction of OSS

These days technology mostly follows the route of re-using software components. Open source and commercial products are commonly incorporated into packaged software and microservices, and ultimately bundled to meet customer demands. Such integration of software components is common because it enables the delivery of new features at speed and scale. However, it carries a considerable risk as there may be components which are potentially untrusted and contain vulnerable code.

Everything is under control, or is it?

The DevSecOps Community Survey for 2018 conducted by Sonatype, revealed a 55% year-on-year increase in participants confirming or suspecting breaches tied to security vulnerabilities in open source components. Sonatype’s analysis of 500 applications in 2018 found the median number of open source components in an application was 127, while a few maxed out at over 5,000. From this set of applications, the average share of components with a known security vulnerability was 11.7%. These figures go to show just how vulnerable your software supply chain is; attackers can simply infiltrate the open source software supply chain by adding a malicious dependency to a trusted component.

Address your OSS risk by following an iterative approach

Regardless of how mature your organisation is, the underlying approach to reducing your OSS risk remains the same:

  • Gain visibility of all OSS in your code base and application architecture

“You can’t protect what you can’t see”, and that’s also true in this instance. Your software code can be many thousands of lines long so working out where your dependencies on third party code are can be impractical. Automated scanning tools can help identify where these dependencies exist, as well as simple processes such as asking developers to log when they integrate open source code into your own.

  • Work out where the OSS vulnerabilities are

Start identifying where potential vulnerabilities exist in your open source code as soon as you’ve gained visibility – don’t wait for complete visibility. Some automated scanning tools not only identify your OSS but also alerts when the code has known vulnerabilities.

  • Reduce your risk by iteratively fixing the vulnerabilities

Not every OSS vulnerability needs to be immediately fixed. Just because a vulnerability is categorised as ‘critical’, it does not necessarily mean it’s critical to your application. A contextual understanding of your architecture and technology stack is necessary in determining which vulnerabilities to address first, and which ones can wait.

For example, you may consider any vulnerabilities associated with the storage of your customer’s sensitive information is unacceptable and should be addressed before all other vulnerabilities. Addressing the vulnerabilities can be done through ‘sprint retrospectives’ which encourages an iterative risk reduction approach, an idea we have talked about in a previous blog post.

Once you map the vulnerabilities, applying the remedial and preventative steps above will reduce the risk without hampering the speed and frequency of development and service delivery. The use of open source software libraries may be convenient, but the risk associated with its use will sooner or later materialise over time so don’t leave it unmanaged.

We are growing our team

Capgemini Invent are seeking like-minded cybersecurity professionals to join our team – follow the below link to apply now.


Kristian Sommer

Related Posts

Public Sector

Three Perspectives on ‘Government as a Platform’

Date icon May 6, 2020

What UK, Dutch and German governments can learn from each other’s digital initiatives


Process Mining in Process Optimisation: An Introduction

Date icon April 24, 2020

Process Mining is a form of business process analysis based on recorded process data by IT...

Predictions 2020

Predictions 2020: public sector

Nikita Mahajan
Date icon February 3, 2020

Trends, technologies, key topics, and issues around the public sector in the UK that will...