Two reports on the security of open source software identifies risks to development processes that are not always addressed in the DevSecOps process.
The widespread use of open source components is posing an ever-increasing threat to secure software, according to new research.
WhiteSource today published it’s first ‘State of Open Source Vulnerabilities Management’ report. According to the WhiteSource research, the number of reported open source software (OSS) vulnerabilities rose by 61.2 percent last year. It also found that 96.8 percent of developers rely upon open source components, and 32 percent of the top 100 projects have at least one open source vulnerability.
Meanwhile, the fourth Sonatype State of the Software Supply Chain report was also published this week and reveals just how widespread the use of vulnerable software components is.
Sonatype researchers point to in excess of 300 billion open source components being downloaded by developers in the past 12 months and said that 12 percent of downloads by UK developers contained a vulnerability. Combine this with 62 percent of businesses admitting to having no proper knowledge of the open source components in their applications, and you have a recipe for an insecure disaster.
Hardly surprising, then, that developers questioned by WhiteSource researchers rated security as the top challenge posed by open source component use – even above integration, functionality and licensing.
More surprising, perhaps, was the finding that an ‘absence of standard practices’ became apparent when developers were asked what they do when such vulnerabilities are discovered. “Since most organisations do not have visibility into the open source components with known vulnerabilities in their projects, there is no standard process for discovery and mitigation of these vulnerabilities,” Rami Sass, co-founder and CEO of WhiteSource, told SC Media UK. “We believe that most organizations do not provide their developers with the right tools.”
This lack of ‘the right tools’ along with an absence of standard practices in dealing with open source vulnerability discovery, could be why the WhiteSource report suggests developers have difficulty in prioritising these vulnerabilities.
SC Media asked the wider security industry if developers are indeed focusing on ‘the wrong vulnerabilities’ and how this can best be mitigated against?
“Clearly developers are focusing on the wrong open source vulnerabilities,” says Ed Williams, director EMEA of SpiderLabs at Trustwave, “as we are still seeing issues to this day.” Williams adds that it should always be remembered that the bad guys only need to win once “whereas the developers need to get everything right, all the time”.
Darron Gibbard, managing director (EMEA North) at Qualys, told SC Media UK that it is crucial to have visibility of the components being used, but the growth of more container-based applications makes visibility challenging as “you can have open source components in place within an application that go unpatched – without this accurate list of IT assets you run the risk of missing out issues that are important to you regardless of any overall priority.”
“The first step in the vulnerability remediation process is knowing what you’re working with,” says Skybox Security threat analysis team leader, Sivan Nir. “There’s a need to continuously track which open source projects are embedded in the code and all their instances, and what might need immediate attention.”
Of course, the collaborative and decentralised nature of the open source community results in information on both vulnerabilities and remediation being published across multiple repositories, advisories and bug trackers. “All of those sources need to be pulled together,” Nir says. “Then a risk assessment is necessary for all vulnerabilities found, looking at the organisation’s system configuration, the likelihood of an occurrence, exploit availability and activity in the wild, its impact and the security controls already put in place.”
So, are existing security policies, whether part of a DevSecOps implementation or organisational security posture, not sufficient to cope with vulnerability discovery and remediation at the development team level then?
“Security policies are often defined at an organisational level far removed from the actual development team,” says Tim Mackey, senior technical evangelist at Synopsys, adding: “And it’s the development team which makes code composition decisions. Unless security policies are designed with the realities of how open source development functions, a nominally good policy could lead to increased security risks to the organisation.”
Wicus Ross, the lead security researcher at SecureData, thinks that organisations making use of OSS projects “must accept additional responsibility for mapping and evaluating the attack surface of components or software provided by the OSS supply chain”. Each organisation must evaluate vulnerabilities uniquely with their given vulnerability management programme in order to allow mature organisations to identify vulnerabilities with the greatest business impact, thus facilitating prioritisation and mitigation.
However, complete mitigation comes, as it always does, in ensuring the basics are done well across the entire organisation and at every layer, argues Ed Williams. “That’s hard to do in reality due to the complexity of organisations and the need to get applications out and not incurring any security debt,” he said.
News by Davey Winder. On SC Magazine – 27 September 2018.