If the XZ Utils backdoor had not been discovered in time, it could have been the most impactful software supply chain breach today. While the XZ Utils backdoor was not exploited as widely as Log4j, it is a wake-up call to the vulnerabilities of the modern digital ecosystem and the need to mature the way we consume and protect OSS.
OWASP(Open Web Application Security Project)의 Top 10 Risks for Open Source SoftwareResources and guidance for cybersecurity practitioners, such as the OWASP Top 10, were originally developed by Endor Labs, a software supply chain and application security company, with a focus on secure consumption and vulnerability management in OSS and CI/CD pipelines. The project included support from industry leaders such as Palo Alto, HashiCorp, and Citibank.
Traditional vulnerability management methods are often CVE(Common Vulerabliity and Exposures) It’s about looking at known vulnerabilities in the database. But there’s a growing recognition that known vulnerabilities are lagging indicators of risk.
A mature open source usage culture requires a paradigm shift to look at the leading indicators of risk that can indicate the presence of risks associated with specific OSS libraries, components, and projects. This will help to use OSS more safely overall and mitigate potential risks that lead to exploits and vulnerabilities.
Here are OWASP’s top 10 OSS risks and their mitigations:
1. Known Vulnerabilities
OSS components can contain known vulnerabilities. These vulnerabilities are often introduced accidentally by software developers and maintainers and then discovered and disclosed by security researchers in the community. These vulnerabilities can be exploited depending on the context in which they are used in the enterprise and application. Even if they seem trivial, not providing context to developers can result in significant effort, time wasted, and frustration.
CISA’s for troubleshooting KEV(Known Exploited Vulnerability) List or EPSS(Exploit Prediction Scoring System)It is helpful to look at the . Companies can take mitigation measures such as scanning for known vulnerabilities in all OSS components they use and prioritizing the discoveries. Priorities can be based on known exploits, probability of exploitation, and reachability analysis (which can reduce noise discoveries by up to 80%).
2. Damage to legitimate packages
Malicious attackers are well aware that compromising legitimate packages can have the potential to impact downstream consumers, either organizationally or individually. They exploit this attack vector in a variety of ways, including compromising project maintainer accounts or exploiting vulnerabilities in package repositories. Or they may volunteer to be project maintainers with malicious intent. This is exactly what happened with the recent XZ Utilities incident, where someone masqueraded as a legitimate contributor for an extended period of time and inserted a backdoor into their code.
One way to mitigate these risks is to use new resources and guidance, such as the Secure Supply Chain Consumption Framework (S2C2F), developed by Microsoft and now donated to OpenSSF.
3. Name confusion attack
This is when malicious components with names similar to legitimate OSS packages or components are created in order to trick potential victims into downloading them by mistake. This attack is also listed in the CNCF Software Supply Chain Attack list, and includes typosquatting and brand jacking. If such compromised packages are introduced into a company’s IT environment, it can affect the integrity, availability, and confidentiality of systems and data.
To combat name confusion attacks, developers need to start by verifying that the OSS package or component they are trying to download is legitimate. Developer education is essential for this.
4. Unmaintained software
This reflects the harsh reality of OSS, where, unlike proprietary software, there is no ‘vendor’. OSS maintainers provide software ‘as is’, so there is no guarantee that the software will be maintained, updated, or sustained. OSS Report from SynopsysAccording to the study, 85% of the evaluated codebases contained OSS components that were more than four years old, and some of them had not been developed in the past two years.
Software is aging at a rapid pace today. New vulnerabilities are appearing at an even faster rate. This does not bode well for the security and hygiene of modern applications that use OSS components that are not actively updated according to the annual NVD index.
The people who maintain OSS are mostly unpaid volunteers. As a result, components may not be actively developed or maintained, and defects may not be fixed. Even when fixes are made, they may not meet the schedules desired by software consumers who use the component, or may not match the timeframes specified in SLAs with downstream customers. In the world of OSS, ‘to use is to own’.
Another reason OSS is not maintained is the lack of staff. 94% of projects are managed by 10 or fewer developers, and in particular, about 25% have only one developer contributing code. For a comprehensive understanding of this problem, see Fordham Law School Professor Chinmay Sharma’s paper,A Tragedy of the Digital CommonsI hope you read it.
Software maintenance is so critical that the industry has a term called the “Bus Factor,” which stands for “the minimum number of people required to maintain a project without affecting someone who gets hit by a bus.” Having only one maintainer on a project is clearly dangerous. Considering that 60-80% of modern code bases are OSS, it is concerning that a significant portion of today’s digital ecosystem, even the most critical systems, are based on software that receives minimal support and maintenance.
To address these risks, it is essential to check the project’s activity and health, including the number of maintainers and contributors, release frequency, and MTTR (mean time to repair).
5. Old software
There are cases where older versions of components are used despite the existence of newer versions and updates. As cited in the synopsis report, this is a common occurrence in an overwhelming majority of code bases and repositories.
Of course, the problem is further complicated by the fact that many modern software applications and projects are complex and have a dizzying number of dependencies. This problem has also been pointed out in reports from groups such as Sonatype and Endor Labs. Endor Labs published a report titled:The State of Dependency ManagementAccording to , 95% of vulnerabilities are related to transitive dependencies.
6. Untracked dependencies
Developers and enterprises are not always aware of whether they are using a particular dependency or component. This may be because enterprises do not use tools such as software composition analysis (SCA) to understand their OSS consumption, or have not adopted new tools such as software bills of materials (SBOM) to provide visibility into the components of the software they consume or distribute.
In fact, SBOM is part of a broader movement to ensure software supply chain security. Incidents like SolarWinds and Log4j have made the industry realize that while software asset inventory has been a critical management practice for years as recommended by SANS/CIS, most companies do not create software inventories that go all the way down to the component/library level. SBOM aims to address this problem by allowing companies to have a component inventory at the enterprise level.
7. License and Regulatory Risks
A component or project may not be licensed or may have a license that prevents downstream consumers from using it. OWASP states that enterprises must comply with the license terms of the component when using OSS components. Failure to do so may result in license or copyright infringement, and even legal action. This can impact an enterprise’s business objectives, M&A activities, etc., as enterprises use OSS components extensively in their proprietary products, services, and offerings.
You can mitigate this risk by understanding the licenses and intended use of the components you use in your software. It is also recommended that you completely avoid using unlicensed components and identify components that are subject to multiple or conflicting licenses.
8. Immature software
Not all software is developed in the same way. There is a spectrum of maturity levels due to different levels of maintenance involvement. Some OSS projects may not apply security practices such as those cited in the NIST Secure Software Development Framework (SSDF). For example, there may be a lack of documentation, regression testing, review guidelines, and other best practices.
There is also the inconvenient reality that many developers are not interested in security, as evidenced by a study by the Linux Foundation and the Laboratory for Innovation Science at Harvard University (LISH) that found that free and open source software developers spend only 2.3% of their time improving the security of their code.
Provides robust checks on OSS projects on GitHub, including branch protection, number of contributors and organizations, CI testing, fuzzing, maintenance, licensing, etc. OpenSSF’s ScorecardTools such as the ‘ developed by CISA and OpenSSF are also widely available.Principles for Package Repository SecurityIt is also helpful to refer to a principle called:
9. Unauthorized changes (or potential changes)
OWASP warns that there are situations where a component can be changed without the developer being aware of, reviewing, or approving the change. This can happen when a download link changes, points to an unversioned resource, or is tampered with to indicate insecure data transfer.
Recommended actions and mitigations include using resource identifiers to ensure and point to the same immutable artifact. Additionally, signatures and digests can be verified before components are actually installed and used. Additionally, to mitigate the risk of components being compromised in transit, enterprises should use secure protocols for the transmission and communication of network traffic.
10. Too much or too little dependency
Finally, there are situations where a component provides very little or a lot of functionality, but only a small portion of it is actually used. This is often referred to as “software bloat.” In the case of small dependencies, the number of lines of code is limited, so the component depends on upstream projects for security. Conversely, when the code is bloated or has an exponentially large number of lines of code, it increases the attack surface and results in introducing potentially exploitable code/dependencies that are not actually needed or used for the intended purpose.
In such cases, it is recommended to internally redevelop the necessary functions to mitigate the risk of insufficient or excessive dependencies. ‘Chainguard’ is a minimally hardened base image with few vulnerabilities in a cloud native container environment.Security Base ImageThe movement to utilize ‘ is also spreading.
editor@itworld.co.kr
Source: www.itworld.co.kr
