3 ms·

so let me rephrase my original comment using more text I see them "bending over backwards" to protect their right to keep an advantage to use, if they deem it

so let me rephrase my original comment using more text I see them "bending over backwards" to protect their right to keep an advantage to use, if they deem it necessary, against any one else. this is why they go to such lengths to avoid publishing what they consider to be "the secret sauce". as I see things, that they even came up with the notion of a "software bill of materials" is a bit disingenious from my perspective. already the concept is obscure and lends itself (in my opinion) to shading, hiding, and occulting the software source code and (or) the hardware designs (as appropiate) finally, I consider that the concept of "SBOM" (which TIL existed) is designed with the intentions I already mentioned: to occult information (anti-open) for the sake of keeping a perceived advantage (pro-centralization)

kube-system 3y ago
I'm honestly having trouble understanding your comment. SBOMs are just a list of dependences. Creating such a list is not a new concept, but it is one that is gaining traction recently. This is useful for people who use software, for example, if they learn that a particular dependency has a vulnerability in it, they can quickly determine if they are affected. I'll give you an example of what they're intended to be useful for: Let's say you're an organization and you use, say, 500 different pieces of software made by 100 different companies. If you learn that there's a vulnerability in a particular dependency, what do you do? In the past, there was no standard way that vendors communicated this information, so the answer is that you would go through your list of 500 software programs, and email 100 different vendors asking about each one. This is not a good process. If, instead, everyone provided an SBOM with their software, all you need to do is run a query against whatever inventory management system you're using and you have the answer in seconds.
- narinxas 3y ago
  my point has very little to do with process it seems to me that you're arguing back that SBOMs are just a list, so how can it be a big deal? my point is an issue about the whole reality of needing SBOMs. clearly they have something to do with supply chain trust. but I think your perspective is focused too closely on the engineering aspects of the problem. I find that the technical realities (all of which I understand to be, in the end, some kind of engineering decision) that motivate having to share vulnerabilities of all components without revealing their designs sources (of either software, hardware, both, or neither) to be morally dubious. so keeping in mind that hardware, by this point, is stored as code so it's code, and software also has a source code, I find it necessary by this point to open source all the things!!1!
  - numpad0 3y ago
    Lots of open source projects distribute prebuilt binaries too.
  - kube-system 3y ago
    Open sourcing doesn't alleviate the need for an SBOM. Regardless of source availability or license type, it shouldn't be a lengthy engineering exercise to determine what software components an organization is running every time a CVE is published. The people doing patch management at large organizations are typically not software engineers, and even if they are, they don't have time to read source code. The questions they are trying to answer should be able to be answered programmatically in seconds. This isn't an engineering problem, it's an operational problem.
    - narinxas 3y ago
      it's the political principles I'm critizicing. the technical problem is really essentially a matter of trust, blockchains solved this problem in the technical sense. the opreations of large organization are typically private property... this is a touchy issue because technology corporations are essentially the government by this point I guess I should be glad this isn't really my problem, I'm just worried about the public and political consequences of what I see as potentially dangerous mistakes being made on the idelogical level
      - kube-system 3y ago
        You're misunderstanding the factors driving this initiative. This isn't an attempt to address the problem of trust. Software can be found to have vulnerabilities even if they are highly trustworthy, and almost all vulnerabilities in commercially used software are accidental. The organizations asking for SBOMs (this is currently receiving a lot of attention due to changes the US government has made to require them for their internal use) have other mechanisms to establish trust with their software vendors. The straw that broke the camel's back on this issue was CVE-2021-44228 -- which was a vulnerability in open source software. If you missed that debacle -- the problem wasn't that people distrust Apache or software that use Log4j. The problem was that people didn't know where all it was installed. This was because it isn't currently a standard for software developers to provide a list of all of their dependencies, regardless of whether they're open source or not. This isn't because they are untrustworthy. It just simply isn't standard practice. SBOMs are an attempt to standardize such a list. A blockchain isn't necessary here -- nobody is trying to lie about what version of Log4j they're depending on in a piece of software they're selling.

kube-system 3y ago

I'm honestly having trouble understanding your comment. SBOMs are just a list of dependences. Creating such a list is not a new concept, but it is one that is gaining traction recently. This is useful for people who use software, for example, if they learn that a particular dependency has a vulnerability in it, they can quickly determine if they are affected. I'll give you an example of what they're intended to be useful for: Let's say you're an organization and you use, say, 500 different pieces of software made by 100 different companies. If you learn that there's a vulnerability in a particular dependency, what do you do? In the past, there was no standard way that vendors communicated this information, so the answer is that you would go through your list of 500 software programs, and email 100 different vendors asking about each one. This is not a good process. If, instead, everyone provided an SBOM with their software, all you need to do is run a query against whatever inventory management system you're using and you have the answer in seconds.

narinxas 3y ago
my point has very little to do with process it seems to me that you're arguing back that SBOMs are just a list, so how can it be a big deal? my point is an issue about the whole reality of needing SBOMs. clearly they have something to do with supply chain trust. but I think your perspective is focused too closely on the engineering aspects of the problem. I find that the technical realities (all of which I understand to be, in the end, some kind of engineering decision) that motivate having to share vulnerabilities of all components without revealing their designs sources (of either software, hardware, both, or neither) to be morally dubious. so keeping in mind that hardware, by this point, is stored as code so it's code, and software also has a source code, I find it necessary by this point to open source all the things!!1!
- numpad0 3y ago
  Lots of open source projects distribute prebuilt binaries too.
- kube-system 3y ago
  Open sourcing doesn't alleviate the need for an SBOM. Regardless of source availability or license type, it shouldn't be a lengthy engineering exercise to determine what software components an organization is running every time a CVE is published. The people doing patch management at large organizations are typically not software engineers, and even if they are, they don't have time to read source code. The questions they are trying to answer should be able to be answered programmatically in seconds. This isn't an engineering problem, it's an operational problem.
  - narinxas 3y ago
    it's the political principles I'm critizicing. the technical problem is really essentially a matter of trust, blockchains solved this problem in the technical sense. the opreations of large organization are typically private property... this is a touchy issue because technology corporations are essentially the government by this point I guess I should be glad this isn't really my problem, I'm just worried about the public and political consequences of what I see as potentially dangerous mistakes being made on the idelogical level
    - kube-system 3y ago
      You're misunderstanding the factors driving this initiative. This isn't an attempt to address the problem of trust. Software can be found to have vulnerabilities even if they are highly trustworthy, and almost all vulnerabilities in commercially used software are accidental. The organizations asking for SBOMs (this is currently receiving a lot of attention due to changes the US government has made to require them for their internal use) have other mechanisms to establish trust with their software vendors. The straw that broke the camel's back on this issue was CVE-2021-44228 -- which was a vulnerability in open source software. If you missed that debacle -- the problem wasn't that people distrust Apache or software that use Log4j. The problem was that people didn't know where all it was installed. This was because it isn't currently a standard for software developers to provide a list of all of their dependencies, regardless of whether they're open source or not. This isn't because they are untrustworthy. It just simply isn't standard practice. SBOMs are an attempt to standardize such a list. A blockchain isn't necessary here -- nobody is trying to lie about what version of Log4j they're depending on in a piece of software they're selling.