Solving Open Source Supply Chain Security for the PHP Ecosystem

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • OpenCart

    A free shopping cart system. OpenCart is an open source PHP-based online e-commerce solution.

    > 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

    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

    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.

  • Symfony

    The Symfony PHP framework

    > 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

    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

    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.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • pacman-bintrans

    Experimental binary transparency for pacman with sigstore and rekor

    Generally speaking, Transparency Logs for securing software distribution has been a research topic since around 2015, I also wrote my master thesis on the subject.

    Sigstore is a Transparency Log intended for provenance and software artifacts which has support for a few different build artifacts. The container ecosystems also appears to be embracing it.

    Cool practical example is pacman-bintrans from kpcyrd that throws Arch Linux packages on sigstore and (optionally) checks each package for being reproducible before installation.

    https://github.com/kpcyrd/pacman-bintrans

    https://www.sigstore.dev/

    I think this is generally useful for a lot of ecosystems indeed, and it's cool to also see similar scoped projects pop up to address the these issues.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts