Myrror Security CEO: Strategies to Combat Open-Source Vulnerabilities

In an interview with Yoad Fekete, CEO and Co-founder of Myrror Security, we uncover the critical vulnerabilities plaguing open-source components and the methods by which attackers exploit them. Fekete sheds light on the prevalent risks of Injection Flaws, Cross-Site Scripting, Insecure Deserialization, and Broken Authentication, offering insights into their execution and impact.

What vulnerabilities are most commonly exploited in open-source components, and how are these attacks typically executed?

Given that open-source packages are widely accessible, malicious actors can easily find vulnerabilities by freely examining their code. Consequently, vulnerabilities in open-source components are frequently exploited by attackers. One common type of vulnerability is an Injection Flaw, which includes SQL, NoSQL, OS, and LDAP injections. These occur when attackers inject malicious code into a program, often through input fields, to execute unintended commands or access unauthorized data. For instance, in an SQL injection, attackers manipulate SQL queries to infiltrate a database by inputting malicious data into fields meant for user input, thereby manipulating the interpreter to execute unintended commands.

Another prevalent kind of vulnerability is Cross-Site Scripting (XSS), where attackers inject malicious scripts into content from otherwise trusted websites. This exploit allows the script to access cookies, session tokens, or other sensitive information retained by the browser, compromising user security. Typically, attackers embed these malicious scripts (most commonly JavasScripts) in web pages through forums, comment sections, or web forms where users can input text, enabling the script to execute within the hacked browser and potentially steal cookies or session tokens.

Insecure Deserialization also poses a substantial risk, leading to remote code execution, replay attacks, injection attacks, and privilege escalation attacks. This vulnerability arises from deserializing data from untrusted sources, which can be manipulated by attackers to execute harmful functions. By altering serialized objects sent to a web application, which are then deserialized into live objects, attackers effectively modify serialized data and are then able to force the application to perform unintended actions, including executing malicious code.

Lastly, Broken Authentication is a critical type of vulnerability that enables attackers to impersonate legitimate users by guessing or capturing passwords, tokens, or keys and gain unauthorized access to systems. This is often achieved by exploiting weaknesses in the authentication process, such as brute-forcing passwords, exploiting poorly configured session management, using stolen credentials, or manipulating tokens to gain unauthorized access.

How do you recommend organizations develop a culture of OSS security awareness, and what key practices should be included in this?

Developing a robust culture of OSS security awareness within an organization is essential to safeguarding against vulnerabilities and ensuring the integrity of software development processes. To foster this culture, organizations should prioritize regular, engaging training sessions focused on OSS security best practices, common vulnerabilities, and secure coding guidelines. These sessions not only educate but also keep the team updated on the latest security trends and threats.

In addition to training, establishing a Security Champions program within development teams can significantly enhance security practices. These high-performing and additionally trained Security Champions act as go-to experts for OSS security, promoting best practices and facilitating the integration of security into the software development lifecycle. 

Encouraging developers to actively contribute to OSS projects is another key strategy. This involvement not only contributes to the overall security of the OSS ecosystem but also deepens the developers' understanding of OSS security challenges and solutions, fostering a sense of ownership and responsibility towards secure coding practices. 

Recognition and rewards for contributions to security improvements can also motivate team members to prioritize security in their work. This, combined with an environment that encourages open communication about security concerns—without fear of blame or retribution—helps in identifying and mitigating risks early.

Furthermore, it's crucial to promote the understanding that security is a shared responsibility across all roles within the organization, not just confined to the security team or developers. This collective approach ensures that security considerations are integrated throughout the organizational processes and decision-making.

Finally, developing clear policies for the use of OSS is vital. These policies should outline clear guidelines for the selection, approval, and maintenance of OSS components, ensuring that only authorized packages are used. Criteria for OSS use can include only using authorized packages, which can be done by incorporating an internal artifact repository. Authorized packages should be packages with a healthy reputation, meaning they have had active maintenance in the past year, at least 2 contributors, a short average vulnerability response times, adherence to source control management best practices, and test coverage. Additionally, authorized packages should be verified as not containing high/critical vulnerabilities, malicious code, tampering or otherwise compromised integrity. Aside from using authorized packages, OSS best use policies should ensure uniformity in the OSS packages used across teams to eliminate security and operational inconsistencies, while continuous verification of the security posture of these packages guarantees that any changes are promptly addressed.

By implementing these practices, organizations can cultivate a proactive culture of OSS security awareness, making security an integral part of their operational ethos.

Can you elaborate on the risks posed by malicious packages deliberately embedded in open-source code, and how can organizations identify and protect against such hidden threats?

Malicious packages embedded in open-source code represent a significant and insidious risk to organizations. Unlike vulnerabilities, which are often flaws unintentionally introduced by developers and require specific conditions to be exploited, malicious packages are intentionally crafted by bad actors to execute harmful actions without prerequisite conditions. This makes them particularly dangerous as they are designed to either mimic legitimate functionality or hide within seemingly benign packages, making detection challenging. To identify and protect against these hidden threats, organizations should look beyond CVEs and use a solution that can detect both malicious code in their open-source 3rd parties' code repositories as well as check the packages themselves for tampering.

What role do you believe rigorous security practices during the Software Development Lifecycle play in mitigating the risks associated with using open-source components?

Incorporating rigorous security practices throughout the Software Development Lifecycle (SDLC) is crucial for mitigating the inherent risks associated with using open-source components. These practices serve several critical functions that collectively enhance organizations’ security posture.

First and foremost, the early identification of vulnerabilities and malicious code is essential to be able to address potential security issues before they get to the product, where they could be exploited. Secondly, compliance and adherence to best security practices and standards play another vital role in the secure use of open-source components. Security best practices within the SDLC ensure that software projects align with industry regulations and standards, such as the General Data Protection Regulation (GDPR) or the Payment Card Industry Data Security Standard (PCI DSS). This is particularly important when open-source components are used, whose compliance status might not be immediately clear, as evident in the recent rising demand for Software Bill of Materials (SBOMs).

Finally, education and awareness among developers about the importance of security in the use of open-source components play an equally critical role in OSS risk mitigation. This includes training on secure coding practices, understanding the security implications of using certain open-source libraries, and how to evaluate them for security risks. Incorporating a security step in the CI/CD pipeline may help teach that this is a best practice and should be applied to other projects and future workplaces. 

How can security professionals balance the benefits of open-source software, such as cost-effectiveness and efficiency, with the increased security risks in today's digital landscape?

In the fast-paced realm of today's digital landscape, the allure of open-source software (OSS) lies in the efficiency it brings to the software development process ─ given the speed at which developers must work, they should not be spending time developing code that is already available to them through OSS. However, most developers lack the knowledge of best security practices. Having governance in the form of automation and integration of security testing across developers’ existing workflows ensures a balance between using the OSS they need while still keeping their software secure.