4 ms·

I don't understand all this modern "supply chain security" stuff. What is the point of getting cryptographic signatures and bills of material from people you do

by remram 4y ago

I don't understand all this modern "supply chain security" stuff. What is the point of getting cryptographic signatures and bills of material from people you don't know and don't trust?

pxc 4y ago
One useful thing you can do with an SBOM is quickly check whether your dependencies carry any known vulnerabilities. That kind of thing can be harder than you'd think to track, especially across large organizations with many projects.
lucideer 4y ago
It's a step (and I guess for many, a coping strategy). Getting a BOM about people you don't know/trust lets you know who you don't know/trust: known unknowns. At the very least it present a quantifiable risk profile that you can use to push for disengaging from untrusted dependencies. At best, it's a stepping stone to start building relationships.
- remram 4y ago
  It's a step towards what? What's the next step? Some rando's BOM does not give you "known unknowns", it gives you "unknown knows"/"untrusted knows", an untrustable list of stuff they say they know, which only give you a risk profile if the potential attacker is not attacking you, and is definitely not "quantifiable risk".
  - lucideer 4y ago
    I'm not really sure what "unknown knowns"/"untrusted knowns" are (or how switching the order of the words is significantly different in this particular context). If I'm using a piece of software from Alice, & Mallory is using a supply-chain attack to compromise that software, I have chosen to trust Alice without knowing who Alice has chosen to trust (unquantified risk). An SBOM tells me that Alice has chosen to trust Mallory - it doesn't necessarily tell me whether Mallory should be trusted, but it allows the risk associated with trusting Alice to be better quantified. The next (out-of-band) step is actively engaging with & trust Mallory (or not).
    - remram 4y ago
      This assumes that you trust the manifest from Alice. You rely on Alice being truthful to evaluate the risk in trusting Alice. This is a catch-22.
      - lucideer 4y ago
        I'm not sure we're talking about the same thing. What manifest are you referring to here? The post is detailing a feature offered by GitHub to generate SBOMs from source code repositories - these will provide machine-readable inventory based on the files within the repository. You can upload a dependency graph to feed the SBOM as an out-of-band step, but trusting Alice's out-of-band dep graph is only a function of access to the source code as a source of truth. Ultimately that's what all if this comes down to: creating a machine-readable graph from a predicable central place that tells us information we could have ascertained ourselves before anyway (just with considerably more effort).
  - ahepp 4y ago
    If they're wrong, you don't trust them in the future. Sure, they can just generate a new key. Eventually there will be businesses with good reputations, and ones with unknown reputations. Just like in "real life" right? Maybe I'm misunderstanding the discussion here?
    - remram 4y ago
      We're all already doing this, what benefit does the key provide?
dane-pgp 4y ago
The first step in solving the trust problem is solving the identity problem. At the very least, once you've got cryptographic identities for entities involved in your supply chain, you can use a TOFU policy and check whenever an identity changes. Simple operations like rotating a key shouldn't trigger any security warnings, as long as they new key is signed by the old one, and even adding new people to a team should happen seamlessly if (a majority of) the existing team members approve that new identity being added. Of course it doesn't solve key compromise, or someone selling their keys to someone else, but with long-lived (even pseudonymous) identities, it becomes possible to reason about the trust level of packages just based on how long an identity has been used without being compromised. No system is perfect, and there's still a long way to go, but the existing systems make the remaining problems more tractable, and already increase the cost for attackers, which should reduce attacks.
- remram 4y ago
  > The first step in solving the trust problem is solving the identity problem I disagree entirely. Knowing that the random "leftpad" library you pulled it was in fact authored by "John Brown, 46 years old, from Milwaukee" does absolutely nothing for your software security. The only way to audit your dependencies is to actually have someone you trust (e.g. works for you) go and audit your dependencies. The entire system is built on a broken premise.
  - dane-pgp 4y ago
    I'm glad you agree that knowing someone's name, age, and address doesn't prove their trustworthiness, because I don't want trust decisions to be dependent on threats of state-backed violence or mob vigilantism. It is possible to build up trust in an identity based on how long that identity has been used, and the "transitivity of trust" principle. So you wouldn't trust someone because "John sounds like a trustworthy name", and instead you'd look at how long the author's key had been associated with the library, and whether their key had previously been endorsed on other people's projects (for example having their PRs reviewed and accepted). Admittedly this introduces a new danger that the social graphs start to become very dangerous honeypots of metadata, especially if we start letting employers vouch for their employees, but the ultimate goal here should be to use something like Verifiable Credentials with zero knowledge proofs, which will allow very strong probabilistic arguments to be made about whether an author (and all the code reviewers) have suddenly gone rogue and decided to burn their hard-earned reputations.
cxr 4y ago
This is targeted at public sector and other enterprise customers. It doesn't need to actually solve the problem. It just needs to clear the hurdle of giving the people who work at these companies a way to look like they got something done. Bonus points when it does so in terms (like "bill of materials") that they're already familiar with.
thenerdhead 4y ago
Would you rather have a receipt for something you buy or to take someone's word on it if anything goes wrong?
- remram 4y ago
  I don't understand what you mean at all. If I don't trust you or the software you sell me, how does you handing me a receipt that says "software is trustworthy I swear" increase that trust? What do I do with that receipt if anything goes wrong?
  - thenerdhead 4y ago
    Say you bought a car from someone. They give you their word that it runs. It runs for awhile but then something breaks. You have no idea why so you take it to a shop and they find a number of reasons it could be faulty. After many days and countless dollars later you finally find a root cause. Say you bought a car and this time they gave you an itemized receipt of every part in that car and the current condition of each part. It breaks down. Now when you go to take it in to a shop to investigate, you may correlate a specific defective or unmaintained part as the reason. You replace that part and move on with life. You’ve saved time, energy, and got plenty of peace of mind. You do not trust who you got the car from, that largely doesn’t matter. Because now you have to deal with real problems owning that car can bring.
    - remram 4y ago
      This is a fine analogy for accidents. I am talking specifically about security.
      - thenerdhead 4y ago
        It wouldn’t be far fetched to include in the same analogy any known safety recalls or provenance of where you got the part. You may just have a different definition of security here. Best of luck.
Joeri 4y ago
Or maybe you do trust it, but you want to verify. Centrally collected SBOMs are useful to match against CVE’s and other vulnerability sources to quickly identify affected codebases.
adrianmonk 4y ago
I admit I don't know a lot about these systems, but aren't they trying to solve a different problem? Aren't they trying to solve visibility? Once you know a vulnerability exists in a particular version of a particular piece of software, you need a way to go from there, through dependencies, to builds, and then to deployments. You can't push fixes to all the right places without knowing what those places are. In other words, you need to correctly and completely answer questions like, "Oh, CVE-YYYY-NNNNN was just announced. What's the list of every binary on every machine of every platform we have in every environment (production, corporate network, employee cell phones) that needs a fix?" You can do it manually, but that's basically asking for failure because you'll miss things. Also it's tedious.

by remram 4y ago

I don't understand all this modern "supply chain security" stuff. What is the point of getting cryptographic signatures and bills of material from people you don't know and don't trust?

pxc 4y ago

One useful thing you can do with an SBOM is quickly check whether your dependencies carry any known vulnerabilities. That kind of thing can be harder than you'd think to track, especially across large organizations with many projects.

lucideer 4y ago

It's a step (and I guess for many, a coping strategy). Getting a BOM about people you don't know/trust lets you know who you don't know/trust: known unknowns. At the very least it present a quantifiable risk profile that you can use to push for disengaging from untrusted dependencies. At best, it's a stepping stone to start building relationships.

remram 4y ago
It's a step towards what? What's the next step? Some rando's BOM does not give you "known unknowns", it gives you "unknown knows"/"untrusted knows", an untrustable list of stuff they say they know, which only give you a risk profile if the potential attacker is not attacking you, and is definitely not "quantifiable risk".
- lucideer 4y ago
  I'm not really sure what "unknown knowns"/"untrusted knowns" are (or how switching the order of the words is significantly different in this particular context). If I'm using a piece of software from Alice, & Mallory is using a supply-chain attack to compromise that software, I have chosen to trust Alice without knowing who Alice has chosen to trust (unquantified risk). An SBOM tells me that Alice has chosen to trust Mallory - it doesn't necessarily tell me whether Mallory should be trusted, but it allows the risk associated with trusting Alice to be better quantified. The next (out-of-band) step is actively engaging with & trust Mallory (or not).
  - remram 4y ago
    This assumes that you trust the manifest from Alice. You rely on Alice being truthful to evaluate the risk in trusting Alice. This is a catch-22.
    - lucideer 4y ago
      I'm not sure we're talking about the same thing. What manifest are you referring to here? The post is detailing a feature offered by GitHub to generate SBOMs from source code repositories - these will provide machine-readable inventory based on the files within the repository. You can upload a dependency graph to feed the SBOM as an out-of-band step, but trusting Alice's out-of-band dep graph is only a function of access to the source code as a source of truth. Ultimately that's what all if this comes down to: creating a machine-readable graph from a predicable central place that tells us information we could have ascertained ourselves before anyway (just with considerably more effort).
- ahepp 4y ago
  If they're wrong, you don't trust them in the future. Sure, they can just generate a new key. Eventually there will be businesses with good reputations, and ones with unknown reputations. Just like in "real life" right? Maybe I'm misunderstanding the discussion here?
  - remram 4y ago
    We're all already doing this, what benefit does the key provide?

dane-pgp 4y ago

The first step in solving the trust problem is solving the identity problem. At the very least, once you've got cryptographic identities for entities involved in your supply chain, you can use a TOFU policy and check whenever an identity changes. Simple operations like rotating a key shouldn't trigger any security warnings, as long as they new key is signed by the old one, and even adding new people to a team should happen seamlessly if (a majority of) the existing team members approve that new identity being added. Of course it doesn't solve key compromise, or someone selling their keys to someone else, but with long-lived (even pseudonymous) identities, it becomes possible to reason about the trust level of packages just based on how long an identity has been used without being compromised. No system is perfect, and there's still a long way to go, but the existing systems make the remaining problems more tractable, and already increase the cost for attackers, which should reduce attacks.

remram 4y ago
> The first step in solving the trust problem is solving the identity problem I disagree entirely. Knowing that the random "leftpad" library you pulled it was in fact authored by "John Brown, 46 years old, from Milwaukee" does absolutely nothing for your software security. The only way to audit your dependencies is to actually have someone you trust (e.g. works for you) go and audit your dependencies. The entire system is built on a broken premise.
- dane-pgp 4y ago
  I'm glad you agree that knowing someone's name, age, and address doesn't prove their trustworthiness, because I don't want trust decisions to be dependent on threats of state-backed violence or mob vigilantism. It is possible to build up trust in an identity based on how long that identity has been used, and the "transitivity of trust" principle. So you wouldn't trust someone because "John sounds like a trustworthy name", and instead you'd look at how long the author's key had been associated with the library, and whether their key had previously been endorsed on other people's projects (for example having their PRs reviewed and accepted). Admittedly this introduces a new danger that the social graphs start to become very dangerous honeypots of metadata, especially if we start letting employers vouch for their employees, but the ultimate goal here should be to use something like Verifiable Credentials with zero knowledge proofs, which will allow very strong probabilistic arguments to be made about whether an author (and all the code reviewers) have suddenly gone rogue and decided to burn their hard-earned reputations.

cxr 4y ago

This is targeted at public sector and other enterprise customers. It doesn't need to actually solve the problem. It just needs to clear the hurdle of giving the people who work at these companies a way to look like they got something done. Bonus points when it does so in terms (like "bill of materials") that they're already familiar with.

thenerdhead 4y ago

Would you rather have a receipt for something you buy or to take someone's word on it if anything goes wrong?

remram 4y ago
I don't understand what you mean at all. If I don't trust you or the software you sell me, how does you handing me a receipt that says "software is trustworthy I swear" increase that trust? What do I do with that receipt if anything goes wrong?
- thenerdhead 4y ago
  Say you bought a car from someone. They give you their word that it runs. It runs for awhile but then something breaks. You have no idea why so you take it to a shop and they find a number of reasons it could be faulty. After many days and countless dollars later you finally find a root cause. Say you bought a car and this time they gave you an itemized receipt of every part in that car and the current condition of each part. It breaks down. Now when you go to take it in to a shop to investigate, you may correlate a specific defective or unmaintained part as the reason. You replace that part and move on with life. You’ve saved time, energy, and got plenty of peace of mind. You do not trust who you got the car from, that largely doesn’t matter. Because now you have to deal with real problems owning that car can bring.
  - remram 4y ago
    This is a fine analogy for accidents. I am talking specifically about security.
    - thenerdhead 4y ago
      It wouldn’t be far fetched to include in the same analogy any known safety recalls or provenance of where you got the part. You may just have a different definition of security here. Best of luck.

Joeri 4y ago

Or maybe you do trust it, but you want to verify. Centrally collected SBOMs are useful to match against CVE’s and other vulnerability sources to quickly identify affected codebases.

adrianmonk 4y ago

I admit I don't know a lot about these systems, but aren't they trying to solve a different problem? Aren't they trying to solve visibility? Once you know a vulnerability exists in a particular version of a particular piece of software, you need a way to go from there, through dependencies, to builds, and then to deployments. You can't push fixes to all the right places without knowing what those places are. In other words, you need to correctly and completely answer questions like, "Oh, CVE-YYYY-NNNNN was just announced. What's the list of every binary on every machine of every platform we have in every environment (production, corporate network, employee cell phones) that needs a fix?" You can do it manually, but that's basically asking for failure because you'll miss things. Also it's tedious.