Wipro: Why an Open Source Software Risk Assessment Is Critical

As companies embark on business transformation initiatives, C-level execs must understand the risk and governance implications of digitization. Because modern applications and cloud-based infrastructure solutions have numerous open-source components, it opens a whole new set of considerations. Wipro is among many consultancies that have built a practice around creating a suitable open source software (OSS) governance framework.

Reza Alavi, a cybersecurity risk management consultant at Wipro, helps large companies discover how their organizations are using OSS. Alavi and his team then create a risk mitigation strategy and governance plan. In a keynote session at Channel Evolution Europe on 2 December, Alavi will discuss the risks and opportunities. In advance of next month’s conference, Channel Futures spoke with Alavi about why OSS governance is a good practice for IT consultants to offer.

Channel Futures: Do clients need a different security and governance approach for open source software versus the rest of the software they have in their organization?

Wipro’s Reza Alavi

Reza Alavi: Open source starts with digital transformation. When organizations start considering how their digital transformation projects should look, they consider a number of new technologies. Whether that’s cloud, machine learning, artificial intelligence, security from infrastructure as code and DevSecOps from a DevOps perspective, digital transformation is heavily reliant on open source software. Major companies – such as Microsoft and IBM – have shifted a lot of their attention toward open source software. Some people don’t know it, but 60-70% of Microsoft Azure runs open source software. Now organizations are consuming a lot of open source software, but they don’t know how to deal with it.

CF: Deal with it from what perspective?

RA: From a third-party, risk management, supply chain, license management and clearly from a security and availability management perspective. Because they don’t have enough knowledge around open source software.

CF: How do you help them with that?

RA: First, we provide a gap analysis assessment of what open source software they have. And believe it or not, we find they don’t have the right inventory for open source software. They don’t know what sorts of critical applications are using open source software. And clearly, they don’t know, in terms of risk score, the risks they face with it. So they cannot put in any controls because they don’t know what the risks are. For the inventory, there is no risk control. They normally just stop everything, and they start sandboxing, blacklisting and looking at it from a very traditional security approach. What we do is provide a gap analysis and maturity assessment of the current treatment of open source software in their whole ecosystem. And then we show them what is missing.

CF: Is there typically a lot missing?

RA: Most companies don’t have any policies for open source software; they don’t have any guidelines. On top of that, they don’t have any strategic understanding of open source from a risk versus opportunities and benefits standpoint. So we give them a maturity assessment with a gap analysis to provide them with understanding of the risk versus opportunities on open source.

CF: What happens next?

RA: Then we dive into quite technical stuff in terms of looking at the whole ecosystem. We look at what assets they have, and what assets are consuming open source at what level of the organization. For instance, we have a client that was starting a cloud transformation, looking at hybrid cloud. They consume a lot of cloud related services and software. But then they can’t secure them because they don’t know what they have when it comes to open source. They know containers; they use Docker for instance. But they don’t understand how the concept of how security works with it from open source perspective.

CF: What types of things do you tend to discover when conducting these assessments?

RA: We use the CMMI maturity model. My team has worked with over 100 organizations and we never found any organization that was higher than maturity level 2 for open source software governance. We get all of our clients up to level four at least.

CF: What kinds of risks are these companies typically exposing themselves too?

RA: If you look at different aspects of open source governance, from the discovery up to contribution to the community, the risk is …

… they may have vulnerabilities they consumed from open source that they’re not aware of. For example, if you remember Equifax, back in 2017, they had a vulnerability that existed for about a month. And they didn’t know the vulnerability existed. Because when you work with commercial software, the vendor is responsible for dealing with vulnerabilities. From a security perspective, the problem with open source is you have to find your own vulnerabilities and mitigate and run the patch management. The beauty with open source is you can run this quickly, because you find it, you patch it. But if you don’t allocate the right level of resources, then you can’t find them. And then you expose your organization to the outside world. And then bad publicity, regulatory fines and all sorts of things may come to play.

CF: What is involved in doing these assessments in terms of what resources do you have to bring? Obviously, that depends on the size of the organization, etc. But how many people? What kind of tools do you need to do this? And how long can it take?

RA: With a current client I am working with, one of the largest banks in the U.K., we have 50 people. But these 50 people don’t start immediately or work at the same time. There are people who come in at the start of the process, interviewing, looking at documentation, looking at the current controls and how the current controls work. Obviously, we check the auditor’s report and what evidence the auditors provided in terms of specific controls failing if that’s the case. And then we have some technical teams looking at infrastructure and applications to get a good view of how the whole DevOps pipeline and the application environment works. There are different stages, basically. But from an open source perspective, we’ve got our own bespoke processes and guidelines and templates so software development teams can address the shortcomings of their governance and code, code quality, code security and the rest of it, basically to ensure end to end compliance.

CF: What kind of skills do the people on your team require?

RA: People with risk security background, people with programming background, security architects and app sec cloud engineers. Also, consultants and advisory teams provide high-level views and reports. For instance, one of the things we do is provide monthly reports back to the top technical risk committee. These are people on the senior management team and don’t have a great deal of understanding of technical terms. In order to update them on the risk management strategy, you need auditors, people with experience in quality engineering and quality assurance.

CF: Besides the core applications and infrastructure, do you assess client devices and IoT endpoints?

RA: We look at all aspects whether it’s the endpoints, the network or data center infrastructure. The thing with open source is it touches basically everywhere. So we’ve got people and a number of activities in order to put the whole governance framework together for them.

CF: It that sounds like this is something anybody undergoing this transformation project should be doing. And I should be doing it before they do anything else. Do you find they tend to be coming into these things midway into the game or after they’ve gone through it? Or are they taking this as a first step?

RA: It’s really interesting to see because they start thinking about their transformation journey at quite a high level. Unfortunately, they’re not approaching it today with their eyes wide open and seeking the right consultation at the right time. You have to start with the basics of what has to be done from a governance and compliance perspective at the top, and then going down into infosec management and infrastructure. The problem is they underestimate open source and its vitality and therefore, they underestimate open source risk and security. You can’t just insert security at the end of the process; you need to think of risk and security from the start of the process.