OWASP Top 10 Risks for Open Source Software

Description: A component version may contain vulnerable code, accidentally introduced by its developers. Vulnerability details are publicly disclosed, e.g, through CVE, GitHub Security Advisories or other, more informal communication channels. Exploits and patches may or may not be available. The vulnerability may be exploitable in the context of the downstream software, which could compromise the confidentiality, integrity or availability of the respective system or its data, allow lateral movements in the target environment or have other negative effects. Examples: Actions: References:

Description: Attackers may create components whose names resemble names of legitimate open-source or system components (typo-squatting), suggest trustworthy authors (brand-jacking) or play with common naming patterns in different languages or ecosystems. Malicious code can be executed on end-user systems or on systems belonging to the organization that develops and/or operates the dependent software (e.g., build systems or developer workstations). The confidentiality, integrity and availability of systems and the data processed/stored thereon is at risk. Examples: Actions: Prior to installing/using a component: References:

Description: A component or component version may not be actively developed or supported any more, i.e. patches for new functional and security bugs may not be developed. Patch development may therefore need to be done by downstream developers with potentially less experience and knowledge regarding the affected component. This can result in increased efforts and longer resolution times. During that time, system access or functionality may need to be restricted to avoid continued exposure. Examples: Actions: References:

Description: Project developers may not be aware of a dependency on a component at all, e.g., because it is not part of an upstream component’s SBOM, because SCA tools are not run or do not detect it, or because the dependency is not established using a package manager. Flying under the radar, the respective component cannot be checked or monitored for any of the other deficiencies. Examples: Actions: References:

Description: A component or project may not have a license at all, one that is incompatible with the intended use by a downstream consumer, or one whose requirements are not or cannot be met by a downstream user. A component may also violate license terms independent from downstream use, e.g., if it is licensed as GPL but includes files licensed under the original (4-clause) BSD license. A component may also conflict with legal and regulatory requirements, e.g., related to FedRAMP certification or export control. It is important to use components in compliance with their license terms. The absence of a license or non-compliant use can result in copyright or license infringements, which the copyright holder can take legal action against. The violation of legal and regulatory requirements can constrain or hamper addressing certain verticals or markets. Examples: Actions: References:

Description: A component may change without developers being able to notice, review or approve such changes, e.g., because the download link points to an unversioned resource, because a versioned resource has been modified or tampered with or due to an insecure data transfer. Using components that are not guaranteed to be identical when downloaded at different points in time are primarily a security risk. Attacks such as on the Codecov Bash Uploader demonstrate the risk of piping downloaded scripts directly to bash, without checking their integrity beforehand. Mutable components also threaten the stability and reproducibility of software builds. Examples: Actions: References:

Description: A component may provide very little functionality (e.g. npm micro packages) or a lot of functionality (of which only a fraction may be used). Very small components, e.g. ones containing few lines of code only, are subject to the same supply chain risks as large ones, e.g. account take-over, malicious pull requests or CI/CD vulnerabilities, for comparably little functionality. In other words, in exchange for very few lines of code used, the consumer’s security becomes dependent on the upstream project’s security and development posture. Very large components, on the other hand, may have accumulated many features that are not needed in standard use-cases, but contribute to the component’s attack surface. Additionally, such unused features may also bring in additional, unused dependencies (bloated dependencies). Examples: Actions: References: