4 ms·

> I don't get it, who is going to pay for the time and energy required to audit everything? Not everything has to be audited. That's why there's different leve

> I don't get it, who is going to pay for the time and energy required to audit everything? Not everything has to be audited. That's why there's different levels of attestations. In terms of economic incentives: If you're a company bit by one of the recent supply chain issues (colors.js, etc.), you might be able to justify hiring a security vendor to audit the code that your company depends on. This would provide a net-positive benefit to the entire ecosystem, even if it's only a small set of audited code. Maybe one day, we can even make this an expectation of large players. But that's a discussion for down the road. On the opposite end of things, you have independent security consultants that want to establish their reputation so they can get paid engagements with software companies. One avenue available to everyone is review open source software, report vulnerabilities to their maintainers. This can be thankless or even traumatic; i.e. https://github.com/opencart/opencart/pull/1594 https://github.com/opencart/opencart/pull/1594 Gossamer would open an alternative approach: Hang your shingle out by publishing negative (vote-against) attestations of vulnerable versions of open source software and positive attestations (e.g. code-review) of the versions that mitigated the issues they disclosed. Anti-malware vendors (e.g. WordFence) could even issue weaker positive assertions (spot-check) for WordPress plugin/theme updates after vetting the known-good releases. Security companies depend heavily on their ability to earn trust to thrive, and that's a hard market to break into; this offers another way in. In short, the economic challenges you're imagining aren't the ones that this project will face. (Although, there will assuredly be challenges.) Companies acting in their own self-interest can be leveraged to cover the hot paths of the universal dependency graph, and security up-starts can be leveraged to cover their blind spots. Given enough time, the ecosystem will eventually reach some sort of equilibrium, and many new opportunities will be made in the process. > I presume the big package maintainers already have eyes on their stuff - symfony etc. Read the discussion on the Symfony Encryption component: https://github.com/symfony/symfony/pull/39344 https://github.com/symfony/symfony/pull/39344 Just because they have eyes on their stuff doesn't mean that those eyes have the necessary domain-specific expertise to identify problems. If it weren't for Paragon (paragonie-security on Github) and their associates in the security industry, the issues identified in the earlier versions of the module would likely have persisted and been shipped.

deanc 5y ago
> Hang your shingle out by publishing negative (vote-against) attestations of vulnerable versions of open source software and positive attestations (e.g. code-review) of the versions that mitigated the issues they disclosed. I don't know. I have sat here rewriting this comment now about 4-5 times. I guess we'll see how it plays out but I don't share your optimism for the economic incentives being there for people to undertake this kind of work. I do applaud you for this work though, and the efforts. The work you and Paragon have performed as part of the PHP ecosystem has been exemplary.
carols10cents 5y ago
> Hang your shingle out by publishing negative (vote-against) attestations of vulnerable versions of open source software and positive attestations (e.g. code-review) of the versions that mitigated the issues they disclosed. So you're imagining that a bunch of people trying to break into security work will do work for free in hopes of gaining potential employers'/clients' trust? And you're imagining that this ecosystem of attestations will be seeded by a bunch of people looking to gain the community's trust? So who audits the auditors? And how long do you expect it to take to get a critical mass of people reviewing code who have gained the community's trust to be reviewing enough packages to solve open source supply chain security?
- CiPHPerCoder 5y ago
  > So you're imagining that a bunch of people trying to break into security work will do work for free in hopes of gaining potential employers'/clients' trust? We're talking about open source software. People are already doing this sort of free work. You run into them when you start a bug bounty program, or once you've created at least one open source package with a nontrivial userbase. The way you're wording this sounds precariously like I'm creating some barrier to entry to extract free labor out of people. Quite the opposite: I'm suggesting a mechanism for taking the free work people are already doing in the open source security space, and using it to build rapport with the market a security researcher is trying to break into. If you're wondering how I would know about the motivations about someone trying to build a customer base out of free labor performed for open source software, take a look at... virtually everything publicly shared on paragonie.com. I'm speaking from experience. ;) > And you're imagining that this ecosystem of attestations will be seeded by a bunch of people looking to gain the community's trust? Not just people. Companies too! (I think most of us view them as separate things still?) > So who audits the auditors? The same people who make these kinds of decisions today, albeit far less formally than what I'm envisioning. For the PHP ecosystem, you have the big players (WordPress, Drupal, Joomla, Magento) and frameworks (CodeIgniter, Symfony, Laravel, etc.) with dedicated security teams that field vulnerability reports from the larger community. Beyond them, you have this large, distributed, ad hoc emergent network of security experts that have a loose consensus on whether or not a self-proclaimed security expert is credible. It's messy and uncoordinated and decentralized, and very imperfect. > And how long do you expect it to take to get a critical mass of people reviewing code who have gained the community's trust to be reviewing enough packages to solve open source supply chain security? I don't have a time estimate on hand, due to how this will need to unfold. I don't expect to have "[solved] open source supply chain security" in any immediate sense. Going from "improved state of affairs" to "solved problem" is a long tail. Marginally, improving the security of the open source supply chain is trivial: Any effort expended is more than is currently being done today. That's the dx part of the equation. What I predict is as follows: 1. Highly impactful codebases (i.e. a dependency of lots of projects), which are in the hot path for many dependency graphs, will end up being covered by third-party reviewers. 2. A lot of niche codebases will be covered because of community interest or due to extant social relationships. 3. A large swath of what remains will remain uncovered by third-party review despite being open source. Today, the software in category 3 is an unknown unknown. With Gossamer, it will become a known unknown. This is a meaningful step towards "solved problem", even if it doesn't prima facie solve it immediately.

deanc 5y ago

> Hang your shingle out by publishing negative (vote-against) attestations of vulnerable versions of open source software and positive attestations (e.g. code-review) of the versions that mitigated the issues they disclosed. I don't know. I have sat here rewriting this comment now about 4-5 times. I guess we'll see how it plays out but I don't share your optimism for the economic incentives being there for people to undertake this kind of work. I do applaud you for this work though, and the efforts. The work you and Paragon have performed as part of the PHP ecosystem has been exemplary.

carols10cents 5y ago

> Hang your shingle out by publishing negative (vote-against) attestations of vulnerable versions of open source software and positive attestations (e.g. code-review) of the versions that mitigated the issues they disclosed. So you're imagining that a bunch of people trying to break into security work will do work for free in hopes of gaining potential employers'/clients' trust? And you're imagining that this ecosystem of attestations will be seeded by a bunch of people looking to gain the community's trust? So who audits the auditors? And how long do you expect it to take to get a critical mass of people reviewing code who have gained the community's trust to be reviewing enough packages to solve open source supply chain security?

CiPHPerCoder 5y ago
> So you're imagining that a bunch of people trying to break into security work will do work for free in hopes of gaining potential employers'/clients' trust? We're talking about open source software. People are already doing this sort of free work. You run into them when you start a bug bounty program, or once you've created at least one open source package with a nontrivial userbase. The way you're wording this sounds precariously like I'm creating some barrier to entry to extract free labor out of people. Quite the opposite: I'm suggesting a mechanism for taking the free work people are already doing in the open source security space, and using it to build rapport with the market a security researcher is trying to break into. If you're wondering how I would know about the motivations about someone trying to build a customer base out of free labor performed for open source software, take a look at... virtually everything publicly shared on paragonie.com. I'm speaking from experience. ;) > And you're imagining that this ecosystem of attestations will be seeded by a bunch of people looking to gain the community's trust? Not just people. Companies too! (I think most of us view them as separate things still?) > So who audits the auditors? The same people who make these kinds of decisions today, albeit far less formally than what I'm envisioning. For the PHP ecosystem, you have the big players (WordPress, Drupal, Joomla, Magento) and frameworks (CodeIgniter, Symfony, Laravel, etc.) with dedicated security teams that field vulnerability reports from the larger community. Beyond them, you have this large, distributed, ad hoc emergent network of security experts that have a loose consensus on whether or not a self-proclaimed security expert is credible. It's messy and uncoordinated and decentralized, and very imperfect. > And how long do you expect it to take to get a critical mass of people reviewing code who have gained the community's trust to be reviewing enough packages to solve open source supply chain security? I don't have a time estimate on hand, due to how this will need to unfold. I don't expect to have "[solved] open source supply chain security" in any immediate sense. Going from "improved state of affairs" to "solved problem" is a long tail. Marginally, improving the security of the open source supply chain is trivial: Any effort expended is more than is currently being done today. That's the dx part of the equation. What I predict is as follows: 1. Highly impactful codebases (i.e. a dependency of lots of projects), which are in the hot path for many dependency graphs, will end up being covered by third-party reviewers. 2. A lot of niche codebases will be covered because of community interest or due to extant social relationships. 3. A large swath of what remains will remain uncovered by third-party review despite being open source. Today, the software in category 3 is an unknown unknown. With Gossamer, it will become a known unknown. This is a meaningful step towards "solved problem", even if it doesn't prima facie solve it immediately.