Recently, the publication of a new report from developer security firm Snyk and the Linux Foundation, about their joint research into the state of open source software security.
In your post detail that the results are not encouraging for companies, for there are a wide variety of significant security risks resulting from the widespread use of open source software within modern application development, as well as how many organizations are currently ill-prepared to manage these risks effectively.
Specifically, the report found:
More than four in ten (41%) organizations are not very confident in the security of their open source software;
The average application development project has 49 vulnerabilities and 80 direct dependencies (open source code called by a project); Y,
The time it takes to fix vulnerabilities in open source projects has been steadily increasing, more than doubling from 49 days in 2018 to 110 days in 2021.
It is mentioned that generally a project application development has an average of 49 vulnerabilities and 80 direct dependencies. Additionally, the time required to fix vulnerabilities in open source projects has steadily increased, more than doubling from 49 days in 2018 to 110 days in 2021.
» Today's software developers have their own supply chains: instead of assembling car parts, they assemble code by joining existing open source components with their unique code. If this leads to increased productivity and innovation,” explains Matt Jarvis, Director of Developer Relations at Snyk. Together with the Linux Foundation, we plan to build on these findings to further educate and equip developers around the world, enabling them to keep building fast, while staying safe."
Among other results, only 49% of organizations have a security policy for the development or use of free software (and this figure is only 27% for medium and large companies). While 30% of organizations without a free software security policy openly acknowledge that no one on their team deals directly with free software security.
Supply chain complexity is also an issue, with more than a quarter of respondents indicating they are concerned about the security impact of their direct dependencies. Only 18% say they are confident in the controls they handle.
Up to this point, It is important to highlight two situations, the first of them is at the time developers add a component open source in your applications, you are immediately become dependent on that component and are at risk if that component contains vulnerabilities.
The other and that has been seen frequently in recent years is that this risk is also aggravated by indirect or transitive dependencies, which are the dependencies of the "other dependencies", here many developers do not even know about these dependencies, which makes it even harder to track and protect.
With this, we can understand a little that the report shows how real this risk is, with dozens of vulnerabilities discovered in many direct dependencies in each application evaluated. That said, to some extent, respondents are aware of the security complexities created by open source in today's software supply chain:
More than a quarter of respondents said they are concerned about the security impact of their direct dependencies; only 18% of respondents said they trust the controls they have for their transitive dependencies; and,Forty percent of all vulnerabilities were found in transitive dependencies.
It is also important to mention that if these companies or developers are not "safe" with the software they use, many of us will think of the most logical thing, so that they "pay" or "support development, either by allocating resources or developers", but here in this point is where one of the great debates of open source software comes in, where if open source should be “paid”.
As such, there are many examples of open source software that handles two versions, which are paid and free, and even only paid, but the source code is available.
On the other hand, there have also been movements by developers and large companies, in which they decide to change the distribution model or move to a payment model, for example QT.
No more for those interested in knowing more about it about the note, you can consult the details in the following link.