Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The world needs a software bill of materials

drrispens.medium.com

Post reply on HN
Print view View original

51–60 of 138 posts

Re: The world needs a software bill of materials

#51

Post by ozim »

fulafel wrote: post #17
dlor wrote: post #9

My big problem with all the SBOM efforts is that any kind of compliance/accuracy will be best effort and most likely wrong, leading to more problems and blame. This is not as simple as writing down your dependencies. Most people don't even know what their full set of transitive dependencies is, or how to even go about finding it. How do you know the SBOM you get is even accurate? You can't just crack open a binary an…

You can, in fact, crack open the binaries and look at what's inside. The field of tooling for it is called SCA (software composition analysis).

Technically you are right.

Question is who is going to pay for that?

In my job we dealt with enterprise customers that required list of all libraries we use and what license those have. But they had buckets of money to spend on compliance.

Re: The world needs a software bill of materials

#52

Post by jmull »

wpietri wrote: post #5

At least on first reading, I find this unpersuasive. He correctly lists a variety of problems. But he doesn't explain how his proposed solution, listing all the components of a technological product, would make a practical difference. Creating a list is valuable only if people a) read the list, b) recognize problems, and c) do something based on that. And for some of the examples he gives, it seems pretty obvious to…

I’m a bit skeptical too. (It didn’t seem to me that a SBOM would have helped with solarwinds either.) But I’ll play the devil’s advocate:

* Perhaps end-user systems could automatically monitor the SBOMs of all software installed, cross-reference it with a live vulnerabilities database, and produce vulnerability reports and notifications. This increases the visibility of vulnerabilities and the chance they will be resolved quicker.

* Software companies will feel the increased exposure of the SBOM they need to publish causing them to think more carefully about when and how to take on dependencies. Some do this well already, but this would likely cause more companies to do so.

Re: The world needs a software bill of materials

#53

Post by jmull »

dlor wrote: post #9

My big problem with all the SBOM efforts is that any kind of compliance/accuracy will be best effort and most likely wrong, leading to more problems and blame. This is not as simple as writing down your dependencies. Most people don't even know what their full set of transitive dependencies is, or how to even go about finding it. How do you know the SBOM you get is even accurate? You can't just crack open a binary an…

> Most people don't even know what their full set of transitive dependencies is, or how to even go about finding it.

I think that’s the point.

Also: you really do know your direct dependencies since you need them to build your software. If the efforts to promote or require SBOM are successful, your dependencies will all have SBOM and your tooling will be update to help you generate yours.

Re: The world needs a software bill of materials

#54

Post by TeMPOraL »

wpietri wrote: post #5

At least on first reading, I find this unpersuasive. He correctly lists a variety of problems. But he doesn't explain how his proposed solution, listing all the components of a technological product, would make a practical difference. Creating a list is valuable only if people a) read the list, b) recognize problems, and c) do something based on that. And for some of the examples he gives, it seems pretty obvious to…

I wonder how many companies already have SBOM internally for legal reasons? I know I recently participated in building a partial one, to help the company ensure we comply with exports regulations of multiple countries.

After a casual inspection, we thought we had it all covered, but I felt a bit uneasy, so I dug deeper. Only after I actually read the build scripts of the transitive dependencies, one by one, cover to cover, I discovered we are actually pulling some extra libraries and features we weren't aware of.

I've spent several days manually digging through build scripts of our dependencies, and manually[0] inspecting all the dynamic libraries we ship, to provide a complete list of artifacts that include components subject to legal requirements of interest. And the only reason I could complete this work to my satisfaction, is because there was a select set of things we were looking for. Even after this, I don't know what all the stuff our project depends on do - I only know the stuff the legal team cared about is accounted for.

What this experience made me wish for is better tooling for figuring out what exactly goes into a software product. I'd love to have a tool I could attach to our build system, that would be able to track every single library and library feature that's actually being used. It's a tough job, given how many ways there are for some seemingly innocent piece of code to pull in some other innocent piece of code. Such tool would probably have to be launched on a freshly configured VM and intercept all network traffic, just to be sure.

--

[0] - Well, I quickly scripted that part away. Thank God for people who provide CLI interfaces for GUI tools they write. And yes, inspecting the build output was very useful too - that's how we learned a binary-only commercial dependency we ship is also subject to legal requirements. This wasn't at all visible in the build system - the only way to know was to read the vendor's documentation thoroughly, or audit the symbols in the export tables.

Re: The world needs a software bill of materials

#55

Post by varispeed »

yowlingcat wrote: post #48
rjknight wrote: post #32

Earlier quoted context omitted.

A different approach might be insurance markets. If I want to use component X, but the use of that component creates a risk (however small) that my business will be hacked, then my business could buy an insurance policy to cover that risk. If the software is maintained by an unpaid guy in a basement, the insurance is likely to be relatively expensive. The insurance company then has a strong incentive to pay basement…

I like this approach more because it incentivizes fulfillment of the risk interface without precluding flexibility in how that might be accomplished. I agree with your conclusion that a significant factor in improvements in safety have been seen in other industries with this approach -- align the incentive of not externalizing the risk and I think you'll see a lot of the misbehavior disappear because it's no longer p…

This is not a bad idea, but I am thinking whether this will only shift who is making money off the software from one big corporation to another. Maybe a combination of both - royalties to ensure developers are paid and insurance to ensure big corporations become conscious of their responsibilities.

Re: The world needs a software bill of materials

#56

Post by Shared404 »

pessimizer wrote: post #41
varispeed wrote: post #21

I find it obscene that there are some important software tools that are often developed by one guy in his rented basement and big corporations make billions on the back of it without sharing a penny. We need a royalty system for open source software, so that these companies will have to start paying fair share to the developers they exploit. This will also ensure the overall safety as developers will have funds to do…

That's not Open Source software, that's proprietary software whose source you let people read. If you want to force people to contribute back if they distribute, make your software Free, if you want to force people to pay you, make your software proprietary.

Free as in Speech, not Free as in Beer.

It is perfectly possible to charge for open source software.

Re: The world needs a software bill of materials

#57

Post by kodah »

We already produce a "SBOM", which is just an export of our dependencies. Our dependencies are also scanned for open CVE's, which is non-optimal because it's retroactive. The strongest forms of security operations we implement proactively are fuzzing and linting (in combination with strongly typed languages and language variants).

The article references the SolarWinds attack but then doesn't go on to explain how it occurred nor how their SBOM would've defeated it. Instead it quotes Microsoft in saying that it was highly sophisticated. Just a reminder that the origins of the SolarWinds Orion hack are still up in the air [0], which makes the definitive tone of this article all the more confusing. It is speculated that hackers compromised TeamCity and that TeamCity injected code during compile time into Orion. This wouldn't be caught by any kind of dependency inspection and doubly so if the attackers were smart enough to use all standard libraries.

Like all hacks, this one had signatures too [1]. Some that stand out to me are the network calls:

  avsvmcloud[.]com
  deftsecurity[.]com
  freescanonline[.]com
  thedoccloud[.]com
  websitetheme[.]com
  highdatabase[.]com
  incomeupdate[.]com
  databasegalore[.]com
  panhardware[.]com
  zupertech[.]com

  13.59.205[.]66
  54.193.127[.]66
  54.215.192[.]52
  34.203.203[.]23
  139.99.115[.]204
  5.252.177[.]25
  5.252.177[.]21
  204.188.205[.]176
  51.89.125[.]18
  167.114.213[.]199
It's impossible to hold definitive allow lists for IP addresses or domains, but knowing characteristics about these calls might at least make finding hacks faster, though this logic is also easily defeated.

In what I would call a very sterile software environment you might install fully-configured SE Linux on a system, limit your outbound network call destinations to approved locations, run linting with static compilation, fuzzing on your functions and binary inputs. I can still think of a myriad of ways of compromising a distributed system like that. That's not to say, "do nothing" and more to say, this is a very complex problem and something like an "SBOM" isn't new or going to solve this problem if replicated.

[0] https://www.nytimes.com/2021/01/06/us/politics/russia-cyber-...

[1] https://blog.malwarebytes.com/threat-analysis/2020/12/advanc...

Re: The world needs a software bill of materials

#58

Post by TeMPOraL »

spacemanmatt wrote: post #14
sokoloff wrote: post #10

Earlier quoted context omitted.

If that became a problem, companies intending to skirt the disclosure would fork and “maintain” private branches of dependencies such that it couldn’t be determined if they were out of date.

True story: They already do. I know one company that forked Ruby, and would likely claim every library they run under it is thereby forked for the sake of reporting.

It's a natural next step after pinning versions and keeping all dependencies cached in-house. If the rolling disaster that NPM is taught us anything, is that it's critical to have control over the update process of the code that goes into your product. Not to mention, CI runs faster if you don't have to redownload everything from GitHub on each build :).

(Though then developers don't get a day off when GitHub goes down, as it does every couple months.)

Re: The world needs a software bill of materials

#59

Post by dlor »

fulafel wrote: post #38
dlor wrote: post #23

Earlier quoted context omitted.

Sort of. The quality of the data this tooling generates varies GREATLY among languages, build systems and environments. For packaged software like Solarwinds, sure you can try to run an SCA tool. But is anyone claiming an SBOM or SCA tool could have prevented that attack? The bigger issue is services and hosted software. You can't crack open an API or website that stores your data to see what database they're using.…

I feel you're moving the goalposts a bit. Perfect is the enemy of good, etc. Also surely the tooling would get a lot of investment and improvement poured into it if the proposal went through. Anyway, if this kind of thing really took off, I could well imagine there being regulation for SaaS products having to do audits involving this, for example.

I sort of see this as a situation where an imperfect SBOM is worse than nothing. It would do nothing but add false confidence. I still haven't seen an example of a single supply-chain attack that an SBOM would have prevented.

Re: The world needs a software bill of materials

#60

Post by bryanrasmussen »

package managers tend to give you something wherein you can read exactly what is in your solution, which I suppose is why people are always reading what their dependencies are and making sure that everything is updated as it should be and security holes plugged.

So, given the existence of modern package managers, surely problem solved.

Post reply on HN