4 ms·

Solving Open Source Supply Chain Security for the PHP Ecosystem

80 points by CiPHPerCoder 5y ago

eitland 5y ago
This sounds brilliant and I see no immediate reason why something like this shouldn't be useful for most software ecosystems. Also, in addition to the pure security perspective of this I also have a feeling that it might become a useful piece of the puzzle to solve open source funding.
- Foxboron 5y ago
  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://github.com/kpcyrd/pacman-bintrans https://www.sigstore.dev/ 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.
  - CiPHPerCoder 5y ago
    https://defuse.ca/triangle-of-secure-code-delivery.htm https://defuse.ca/triangle-of-secure-code-delivery.htm was published in July 2014, which included Userbase Consistency Verification as a requirement... so I think that's when the use of transparency logs in solving this problem was earliest recorded. But I'm no internet historian, so I may have missed something.
    - Foxboron 5y ago
      I'm no historian either. I believe there is multiple overlapping efforts that has been cropping up over the years without necessarily being aware of each other. It would be interesting to collect the published research and blogs and get an overview.
deanc 5y ago
I don't get it, who is going to pay for the time and energy required to audit everything? I presume the big package maintainers already have eyes on their stuff - symfony etc. In theory we should always diff upstream package changes - in practice hardly anybody does. There's a trade-off between using OSS code and the cost of maintaining it yourself. That said I guess this adds an option to the ecosystem that wasn't there, or possible before.
- goalieca 5y ago
  I do wonder if companies like snyk could somehow incorporate some sort of assurance model into their service. Hashing and lock files are a pretty common practice and perhaps for the bigger packages they could maintain a list of trusted hashes.
  - deanc 5y ago
    Imagine a scenario where an OSS developer with a package with millions of downloads a week is getting paid a few beers worth of money a month for all their work. And then a company like Snyk is building a verification service on top of this and making bank. Do you not think the money should be going to the OSS community?
    - CiPHPerCoder 5y ago
      These are two separate things, and it's perilous to conflate them. The OSS developer is providing software that anyone can use under whatever license terms for free. How they monetize this is entirely their responsibility. Choosing a permissive license makes them generally indistinguishable from the developers who don't want to monetize their work at all. Solving the "how do we ensure they get paid?" problem is nontrivial, but certainly out of scope for this discussion. The verification service is provided by a company to protect their customers from malicious changes to said OSS software. (Yes, even if they were deliberate changes by the original developer!) In some sense, you could try to frame the verification services as somehow predatory, but that's like saying that safety inspectors are predatory to independent carpenters. (I'm not happy with that last analogy, but it's the best I could come up with on the spot. Real-world analogies to software problems are always messy, so feel free to suggest a better one if you think of any.)
hermanradtke 5y ago
crev for Rust’s cargo package manager is a similar concept: https://web.crev.dev/rust-reviews/ https://web.crev.dev/rust-reviews/
- CiPHPerCoder 5y ago
  Rust is delightfully forward-thinking. Thanks for sharing.
tkfu 5y ago
I think this is a really nice and important project, and at a cursory glance the design looks sane from a crypto perspective. But I question the basic UX design. The attestation system seems like it's reproducing one of GPG's UX problems: you have these categories of attestation, and it's seemingly pretty sane as long as everyone uses the attestations right (and there are enough players in the ecosystem doing the work of attesting). GPG's trust levels have the same idea, but in reality people often just pull keys from some public keyserver and then assign them Full trust. I also think the true meaning of attestations is a bit murky. The `spot-check` and `code-review` attestations are about source code, `reproduced` is about the build artifact, and `sec-audit` is somewhere in the middle (ideally both). But it seems like these attestations are always attached to artifacts, not source code? So spot-check and code-review are really only relevant if the build is reproducible (and has been attested as such), right? Since that's rarely-if-ever going to be the case in the real world, it seems like another reason the attestation system will likely be misused in practice. Finally, although I in-theory admire the goal of allowing the user to define their own policy about trusting updates (defining how many attestations of which types are required/sufficient), my experience in software update systems tells me that real people absolutely won't do this. What will happen, if Gossamer sees good adoption, is that (1) there will be a standard trust config that gets distributed and reproduced, (2) everyone will use that config, and (3) it will be very permissive, because users don't want updates to be delayed/denied. The authors seem to envision a world where there is an ecosystem of independent security vendors out there doing reviews and publishing attestations, but don't really provide any compelling reason why that world will spring into existence.
- CiPHPerCoder 5y ago
  >I also think the true meaning of attestations is a bit murky. The `spot-check` and `code-review` attestations are about source code, `reproduced` is about the build artifact, and `sec-audit` is somewhere in the middle (ideally both). But it seems like these attestations are always attached to artifacts, not source code? So spot-check and code-review are really only relevant if the build is reproducible (and has been attested as such), right? Since that's rarely-if-ever going to be the case in the real world, it seems like another reason the attestation system will likely be misused in practice. This probably should be made clearer, but: Reproducible builds are necessary for the security of any such system. It's outlined in earlier blog posts. Consequently, the inclusion of reproducible build verification is taken as a premise. > The authors seem to envision a world where there is an ecosystem of independent security vendors out there doing reviews and publishing attestations, but don't really provide any compelling reason why that world will spring into existence. That's true, and should probably be tackled in a future blog post.
colek42 5y ago
I think this type of attestation gets us part of the way there, however, the solution needs to be a bit more generalized to cover all the threats. At TestifySec we are working on a open source pluggable attestation framework with a rego policy engine for verification. A review attestation (as proposed in this article) is pretty interesting and is an attestor I will probably add to our project. I wrote some high level thoughts on attestation here: https://www.testifysec.com/blog/what-is-a-supply-chain-attestation/ https://www.testifysec.com/blog/what-is-a-supply-chain-attes...
jbirer 5y ago
- rambojazz 5y ago
  What kind of ecommerce damage is php's fault?
- itrollpussies 5y ago
totony 5y ago
In "What Happens if a Third Party is Compromised?" they mention you cannot revoke an attestation once it's committed. What happens if a security audit is conducted, concludes, but a vuln is found a few years down the line? Security audits are not perfect. Is there a way to say "new information has come up, and this version is no longer secure?" Even with perfect security audits such a feature might be useful, e.g. when you conducted a security audit, but new SPECTRE-like attack vectors are found.
- CiPHPerCoder 5y ago
  Yes, it's called a timestamp. Revocation of trust here isn't automated. "I just greenlit ransomware" is a very different category than "Attacks got better, as they do".
  - totony 5y ago
    How do you know a timestamped vouch is no more valid? Isn't that the point of revocation?
    - CiPHPerCoder 5y ago
      It's not about "valid" or "no more valid". It's about context. If you want to distrust a security vendor for greenlighting something that was found to be vulnerable the following week, you'd probably be in the clear. If it was 6 years ago? Maybe don't count that against them; especially if it's a novel vulnerability that was discovered. But also, if you're running 6 year old software, maybe update to a newer version of it.

80 points by CiPHPerCoder 5y ago

This sounds brilliant and I see no immediate reason why something like this shouldn't be useful for most software ecosystems. Also, in addition to the pure security perspective of this I also have a feeling that it might become a useful piece of the puzzle to solve open source funding.

Foxboron 5y ago
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://github.com/kpcyrd/pacman-bintrans https://www.sigstore.dev/ 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.
- CiPHPerCoder 5y ago
  https://defuse.ca/triangle-of-secure-code-delivery.htm https://defuse.ca/triangle-of-secure-code-delivery.htm was published in July 2014, which included Userbase Consistency Verification as a requirement... so I think that's when the use of transparency logs in solving this problem was earliest recorded. But I'm no internet historian, so I may have missed something.
  - Foxboron 5y ago
    I'm no historian either. I believe there is multiple overlapping efforts that has been cropping up over the years without necessarily being aware of each other. It would be interesting to collect the published research and blogs and get an overview.

deanc 5y ago

I don't get it, who is going to pay for the time and energy required to audit everything? I presume the big package maintainers already have eyes on their stuff - symfony etc. In theory we should always diff upstream package changes - in practice hardly anybody does. There's a trade-off between using OSS code and the cost of maintaining it yourself. That said I guess this adds an option to the ecosystem that wasn't there, or possible before.

goalieca 5y ago
I do wonder if companies like snyk could somehow incorporate some sort of assurance model into their service. Hashing and lock files are a pretty common practice and perhaps for the bigger packages they could maintain a list of trusted hashes.
- deanc 5y ago
  Imagine a scenario where an OSS developer with a package with millions of downloads a week is getting paid a few beers worth of money a month for all their work. And then a company like Snyk is building a verification service on top of this and making bank. Do you not think the money should be going to the OSS community?
  - CiPHPerCoder 5y ago
    These are two separate things, and it's perilous to conflate them. The OSS developer is providing software that anyone can use under whatever license terms for free. How they monetize this is entirely their responsibility. Choosing a permissive license makes them generally indistinguishable from the developers who don't want to monetize their work at all. Solving the "how do we ensure they get paid?" problem is nontrivial, but certainly out of scope for this discussion. The verification service is provided by a company to protect their customers from malicious changes to said OSS software. (Yes, even if they were deliberate changes by the original developer!) In some sense, you could try to frame the verification services as somehow predatory, but that's like saying that safety inspectors are predatory to independent carpenters. (I'm not happy with that last analogy, but it's the best I could come up with on the spot. Real-world analogies to software problems are always messy, so feel free to suggest a better one if you think of any.)

hermanradtke 5y ago

crev for Rust’s cargo package manager is a similar concept: https://web.crev.dev/rust-reviews/ https://web.crev.dev/rust-reviews/

CiPHPerCoder 5y ago
Rust is delightfully forward-thinking. Thanks for sharing.

tkfu 5y ago

I think this is a really nice and important project, and at a cursory glance the design looks sane from a crypto perspective. But I question the basic UX design. The attestation system seems like it's reproducing one of GPG's UX problems: you have these categories of attestation, and it's seemingly pretty sane as long as everyone uses the attestations right (and there are enough players in the ecosystem doing the work of attesting). GPG's trust levels have the same idea, but in reality people often just pull keys from some public keyserver and then assign them Full trust. I also think the true meaning of attestations is a bit murky. The `spot-check` and `code-review` attestations are about source code, `reproduced` is about the build artifact, and `sec-audit` is somewhere in the middle (ideally both). But it seems like these attestations are always attached to artifacts, not source code? So spot-check and code-review are really only relevant if the build is reproducible (and has been attested as such), right? Since that's rarely-if-ever going to be the case in the real world, it seems like another reason the attestation system will likely be misused in practice. Finally, although I in-theory admire the goal of allowing the user to define their own policy about trusting updates (defining how many attestations of which types are required/sufficient), my experience in software update systems tells me that real people absolutely won't do this. What will happen, if Gossamer sees good adoption, is that (1) there will be a standard trust config that gets distributed and reproduced, (2) everyone will use that config, and (3) it will be very permissive, because users don't want updates to be delayed/denied. The authors seem to envision a world where there is an ecosystem of independent security vendors out there doing reviews and publishing attestations, but don't really provide any compelling reason why that world will spring into existence.

CiPHPerCoder 5y ago
>I also think the true meaning of attestations is a bit murky. The `spot-check` and `code-review` attestations are about source code, `reproduced` is about the build artifact, and `sec-audit` is somewhere in the middle (ideally both). But it seems like these attestations are always attached to artifacts, not source code? So spot-check and code-review are really only relevant if the build is reproducible (and has been attested as such), right? Since that's rarely-if-ever going to be the case in the real world, it seems like another reason the attestation system will likely be misused in practice. This probably should be made clearer, but: Reproducible builds are necessary for the security of any such system. It's outlined in earlier blog posts. Consequently, the inclusion of reproducible build verification is taken as a premise. > The authors seem to envision a world where there is an ecosystem of independent security vendors out there doing reviews and publishing attestations, but don't really provide any compelling reason why that world will spring into existence. That's true, and should probably be tackled in a future blog post.

colek42 5y ago

I think this type of attestation gets us part of the way there, however, the solution needs to be a bit more generalized to cover all the threats. At TestifySec we are working on a open source pluggable attestation framework with a rego policy engine for verification. A review attestation (as proposed in this article) is pretty interesting and is an attestor I will probably add to our project. I wrote some high level thoughts on attestation here: https://www.testifysec.com/blog/what-is-a-supply-chain-attestation/ https://www.testifysec.com/blog/what-is-a-supply-chain-attes...

jbirer 5y ago

rambojazz 5y ago
What kind of ecommerce damage is php's fault?
itrollpussies 5y ago

totony 5y ago

In "What Happens if a Third Party is Compromised?" they mention you cannot revoke an attestation once it's committed. What happens if a security audit is conducted, concludes, but a vuln is found a few years down the line? Security audits are not perfect. Is there a way to say "new information has come up, and this version is no longer secure?" Even with perfect security audits such a feature might be useful, e.g. when you conducted a security audit, but new SPECTRE-like attack vectors are found.

CiPHPerCoder 5y ago
Yes, it's called a timestamp. Revocation of trust here isn't automated. "I just greenlit ransomware" is a very different category than "Attacks got better, as they do".
- totony 5y ago
  How do you know a timestamped vouch is no more valid? Isn't that the point of revocation?
  - CiPHPerCoder 5y ago
    It's not about "valid" or "no more valid". It's about context. If you want to distrust a security vendor for greenlighting something that was found to be vulnerable the following week, you'd probably be in the clear. If it was 6 years ago? Maybe don't count that against them; especially if it's a novel vulnerability that was discovered. But also, if you're running 6 year old software, maybe update to a newer version of it.