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.
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.