Challenges in Open Source Software Development

A few things on this awful CVE dumping issue that plagues open source projects, and how this vulnerability got a "Low" from Github, a 9.8 from NVD, and caused the maintainer to archive their project before recently unarchiving it: 1. This is essentially what my talk at Upstream by Tidelift was about this year, we are at a critical breaking point of pretending open source maintainers are our "vendors." The talk is here: https://lnkd.in/e57kJKmz 2. This article ends with, "Until the security research, developer, and vendor communities come together to identify an effective solution, developers are bound to get frustrated with bogus reports burning them out" - there is only one solution: companies need to have relationships with (pay) open source maintainers for the projects that they use. 3. Here are four possible solutions, I'm sure they're all controversial: a. Either increase compliance requirements so that real contact methods are required with open source providers that are listed in SBOMs. If most compliance frameworks require "vendor management" then why doesn't it apply to open source? b. Or drop the vendor notification requirements so that companies don't need to ask open source maintainers about fixing CVEs while providing zero context or attempts to reproduce c. Microsoft/Github working with Tidelift to create a contractor ecosystem out of open source, where vendors and maintainers can be held accountable to shared standards and get paid in response for a "support tier" d. Part of the vulnerability disclosure scoring process includes a "real score" that includes maintainer feedback in the scoring process. In this case, Github lowered their score in response to maintainer feedback, but NVD still shows 9.8 This issue raised all the red flags in open source vulnerability management in a single issue: 1. Maintainers have total control over their project and they can go away at any time 2. Compliance teams pestering maintainers like they work for them does nothing but frustrate people 3. The CVSS scoring system does not indicate real world likelihood or impact Article: https://lnkd.in/e8Dr_-er "Twitter" Thread: https://lnkd.in/ecnmR6mw

Open-source projects work well for certain types of individuals/personalities/businesses and not so well for others. When you work on an open source project, all code, communication, and criticism are open. The community decides the direction of the project. The open source mindset is completely different from lots of "corporate communication standards." When you send an OSS contributor a direct message (DM), they might respond by suggesting you create an issue that's open for the whole world to see. In corporate environments, you may send a message in a team chat and get the opposite feedback - feedback to send a DM instead. As an OSS developer, you need to be comfortable getting frequent negative feedback in public. For some people, this isn't a big deal. It's an absolute nightmare for others. When I was OSS'ing spark-daria & quinn, some of my coworkers didn't agree with the abstractions. They are smart people, and I understood their feedback. For me, the OSS abstractions were a great idea for the codebase because they forced a clear delineation between business logic and open-sourceable logic. When I open-sourced mack, the codebase initially consisted of a single function. My coworker made fun of me for publishing a package with a single function to PyPI, and we laughed about it together. I thought it was hilarious, forged ahead anyway, built a little community, and we had fun hacking on some cool open source Delta Lake functionality. But that feedback would be way too hard for other folks to handle. So open sourcing a project is much more than publishing code in a public repo. You need to like open communication, interfacing with the community, and constant public criticism. The criticism is usually more frequent than the praise. Sometimes the feedback is gentle like "maybe you should consider...", but people from direct communication cultures will often say "this is a bad idea because...". The code part of open source is hard. The "human feelings" part of open source is even harder for some.

Open source powers most software. And for good reason. But there are risks: That’s why we assembled the top 10 security and operational risks into a consolidated list. The OSS Top 10 represent the biggest challenges security and engineering teams face when leveraging reusable code: 1/ Known Vulnerabilities A component version may contain vulnerable code, accidentally introduced by its developers. Vulnerability details are publicly disclosed, e.g, through a CVE. Exploits and patches may or may not be available. 2/ Compromise of Legitimate Package Attackers may compromise part of an existing legitimate project - or its distribution infrastructure - in order to inject malicious code into a component, e.g, through hijacking the accounts of legitimate project maintainers or exploiting vulnerabilities in package repositories. 3/ Name Confusion Attacks 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 (combo-squatting). 4/ Unmaintained Software A component or component version may not be actively developed any more, thus, patches for functional and non-functional bugs may not be provided in a timely fashion (or not at all) by the original open source project 5/ Outdated Software A project may use an old, outdated version of the component (though newer versions exist). 6/ Untracked Dependencies 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. 7/ License Risk A component or project may not have a license at all, or one that is incompatible with the intended use or whose requirements cannot be met. 8/ Immature Software An open source project may not apply development best practices, e.g., not use a standard versioning scheme, have no regression test suite, review guidelines or documentation. As a result, a component may not work reliably or securely. 9/ Unapproved Change 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. 10/ Under/over-sized Dependency 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). Bottom line: There are good reasons why open source powers the digital economy, but that isn’t to say we can rely on it without scrutiny.