Code Review Weekly Workshop - Sep 30, 2022

Understanding Dependency Management in Code Reviews

The Importance of Dependencies

• Discussion on the significance of dependencies in code reviews, highlighting that new dependencies can introduce various concerns compared to traditional merge requests (MRRs).

• A question raised about the criteria for adding new dependencies, focusing on project maturity and release stability.

Balancing Latest Versions with Security Risks

• Emphasis on using the latest versions of dependencies while acknowledging potential stability and security risks associated with cutting-edge releases.

• Noting that many companies do not disclose all security fixes, which complicates dependency management.

Monitoring Dependency Activity

• The necessity for ongoing monitoring of dependencies to ensure they are actively maintained; lack of updates can be a red flag.

• Example given about a specific dependency that hasn't been updated in over 11 years, raising concerns about its reliability.

Evaluating Dependency Complexity

• Preference for simpler gems or libraries that serve a single purpose to minimize security vulnerabilities.

• Warning against using complex libraries where unused features could be exploited by attackers, leading to severe vulnerabilities.

Decision-Making in Adding Dependencies

• Inquiry into when it is more sensible to create a function instead of relying on third-party libraries, emphasizing the need for clear metrics.

• Highlighting the importance of developer experience and discussions around maintenance implications when considering adding a dependency.

Discussion on Dependency Management and Security Concerns

Importance of Communication with Maintainers

• The speaker emphasizes the need for discussions in merge requests (MRs) regarding security issues, suggesting that direct communication with authors often leads to effective resolutions.

Forking as a Solution

• The possibility of forking a package is discussed as a potential solution when specific functions within a package are overly complex or problematic. However, this approach has drawbacks, such as missing upstream updates.

Complexity of Dependencies

• The speaker references the "left pad" incident to illustrate how even simple packages can have extensive dependencies, complicating maintenance and security.

Vulnerability Risks

• There is an acknowledgment that vulnerabilities in one dependency can compromise entire systems, highlighting the importance of tools like Package Hunter for detection. However, there are concerns about evasion tactics used by malicious actors.

Real-world Examples of Targeted Attacks

• An example is given where malware was embedded in a Rust package targeting GitLab CI/CD environments, drawing parallels to other instances where software behaves differently under testing conditions.

Evaluating Third-party Libraries

Criteria for Using Third-party Libraries

• The discussion shifts towards identifying red and yellow flags when selecting third-party libraries. The speaker notes the lack of standardized criteria and suggests relying on gut feelings alongside existing activity metrics.

Development of Trust Score Systems

• A project aimed at creating a dependency review bot is mentioned, which would assess libraries based on metadata and build trust scores related to vulnerabilities.

Need for Formal Security Discussions

• While discussing security issues broadly, there's an indication that more specific examples could enhance understanding. The speaker hints at having confidential information relevant to these discussions but pauses before sharing further details.

Dependency Review and Security Practices

Discussion on Open Source Software Foundation Projects

• The speaker mentions wanting to share a screen regarding a dependency review but holds off, prompting discussion about the Open Source Software Foundation (OSSF) and its projects.

• OSSF has a project called "cor card" that includes criteria for assessing the health of open-source projects, which aligns with common best practices in software development.

Criteria for Assessing Project Health

• Key assessment factors include continuous integration (CI), code reviews, contributor engagement, and security practices such as fuzzing.

• The speaker expresses confidence in their project's practices, suggesting they would score well against these criteria due to strong adherence to best practices.

Transparency in Security Issues

• Existing vulnerabilities that have been patched should not be viewed negatively; rather, transparency about security issues is seen as a positive indicator of project health.

• A repository's lack of disclosed security advisories may indicate poor transparency rather than safety. A clear process for reporting issues is essential.

Importance of CVE Requests

• GitLab's approach to disclosing all security issues—even minor ones—demonstrates their commitment to transparency and user awareness.

• The process of requesting Common Vulnerabilities and Exposures (CVE) numbers is discussed; it’s optional but important for informing users about potential risks associated with dependencies.

Ownership and Reporting Security Issues

• The responsibility for requesting CVEs lies primarily with the project owner; however, if they do not act, others can report vulnerabilities directly to organizations like MITRE.

• If an organization is designated as a CVE Numbering Authority (CNA), they cannot request CVEs for their own projects without following specific protocols.

Challenges in Reporting Vulnerabilities

• There are challenges when reporting vulnerabilities in libraries owned by CNAs; if the CNA chooses not to disclose an issue, it complicates external reporting efforts.

• The conversation highlights the reliance on goodwill among developers to report issues transparently.

Personal Experience with Reporting Security Issues

• One participant shares their experience reporting a denial-of-service vulnerability in a popular library but notes that no CVE was requested afterward, leaving users unaware of potential risks.

• This reflects broader concerns about accountability within open-source communities where individuals often rely on each other’s diligence.

Conclusion on Open Source Ethics

• The discussion concludes with reflections on the hacker ethic prevalent in open source: sharing knowledge and being transparent fosters community trust and collaboration.

Discussion on Security and Dependencies

Importance of Positive Practices in Organizations

• The speaker emphasizes the need for organizations to adopt positive practices, inspiring others to follow suit. This highlights a collective responsibility towards security and best practices.

Challenges with Code Review and Dependencies

• A confidential issue related to code review is introduced, indicating ongoing struggles with dependencies that may not be entirely trustworthy or secure.

Sandbox Solutions for Risk Management

• Discussion revolves around using sandboxing techniques, particularly with iframes, to mitigate risks associated with unreliable libraries. This approach allows for safer usage of dependencies while acknowledging inherent risks.

Limitations of Sanitizers

• The conversation touches on the limitations of sanitizers in preventing vulnerabilities. Even when sanitizers are employed, bugs can occur that compromise security, as illustrated by a recent talk on fuzzing sanitizers.

Real-world Example of Sanitizer Failure

• An example is provided where a fuzzer identified a failure in an HTML sanitizer after extensive testing. This underscores the complexity and potential pitfalls in relying solely on sanitization methods for security.

Defensive Programming Culture

• The importance of adopting a defensive programming culture is discussed. It’s crucial to prepare for potential vulnerabilities proactively rather than reactively addressing issues as they arise.

Server-Side Security Mechanisms

Complexity of Server-Side Sandboxing

• The speaker notes that server-side equivalents to sandbox mechanisms are more complex but necessary when dealing with untrusted inputs or libraries.

Change Root Tool Usage

• A discussion about using change root tools illustrates how user access can be restricted within temporary directories to minimize risk during command execution from potentially compromised environments.

Microservices vs Monolithic Architecture

• The advantages of microservices over monolithic architectures are highlighted regarding security management. Microservices allow isolating workflows into separate machines, reducing the risk of compromising the host system.

Discussion on Code Review and Quality Attributes

Importance of Security in Code Review

• The conversation highlights the ease of discussing security compared to managing processes, suggesting a preference for simpler discussions despite complexities involved.

• A call for participants to present small code reviews is made, indicating an interactive approach to learning and sharing insights within the group.

• Emphasis is placed on the significance of security as a quality attribute in code reviews, stressing that it should be considered alongside performance and other attributes.

• A key takeaway from the discussion is that code reviewers must not only focus on functional aspects but also consider all quality attributes, particularly how security and performance can conflict with each other.