SBOM is a 'massive galaxy of mess' for supply chain security

Supply chain attacks are a serious problem – yet they're long-term operations, and that gives canny admins a chance to nip them in the bud. Always remember to check the Software Bill of Materials (SBOM), and never drop your guard. "Supply chain attacks take a long time. It's not something that you can cook up very quickly," …

[Claptrap314]

I'm not so sure...

1) While it surely took months to set up Solar Winds, not every attack of this sort is going to be this deep.

2) Not every attack is going to hang out for years until it is discovered.

But yeah, if you think that an sBOM is going to do you any good, never look at your node dependencies.

So I agree that these threats are better viewed from the standpoint of defending against sophisticated actors, I'm just not as smiley about our ability to actually do so.

I do wish they had talked about running your own semi-mirrors. Just because rubygems.org goes down doesn't mean you have to. Just because someone pulls their code in a snit doesn't mean you have to manage some kind of workaround. Just because someone screws up a version indicator doesn't mean you have to wait for half of the community to produce a fix. And should a library actually be compromised on the main server, it's simple to blackhole it on your own server & be done.

Yes, there is a significant cost involved. Security is not cheap.

But again, sBOMs seem to poorly address issues that should be handled at a slightly higher level.

[Anonymous Coward]

Re: I'm not so sure...

+1 to mirroring but an approval process is also mandatory - with and without mirroring.

Every included module in code should also be vetted and approved to clarify if: the package is actively maintained, has a compatible license, we have purchased a support contract (give back people), has no CVE's, has no insecure secrets, etc, etc.

I work for a security vendor that does code scanning (so anon) and SBOM is coming but remembering 'leftpad' breaking the Internet, local mirrors are a no-brainer.

[martinusher]

Illegal?

War is by definition an illegal act. It just depends on who you're asking and who's jurisdiction you're referring to. Sometimes its convenient to have an international fig-leaf -- a UN resolution, perhaps -- but it would take some persuading that our (US) actions in Iraq, Afghanistan and Syria were legal. (Certainly not for the numbers of locals that were killed, injured and their livelihoods destroyed).

I think we have to admit that a state of war exists between Russia and NATO and, furthermore, something very similar exists between NATO (and the US's allies in the region) and China. Its not quite total war in the WW2 sense, the situation's a bit weird, but then our experience is either shaped by World War or by a very powerful nation invading or intervening with one or more much weaker ones (what used to be called 'police actions' back in the grand old days of Empire). There's also a problem that a country's leadership is disconnected from its populace -- despite a full on propaganda barrage over our various actions in the past I'm yet to be convinced they're legitimate or justified. Also, this sort of thing doesn't help the cause one bit:-

https://www.theguardian.com/world/2023/mar/01/ukraine-lobbyists-washington-defense-industry

So while I do think that attacks on the software supply chain might be a result of this war, or any war, the more likely cause is still extortion by criminal groups. There's also a burgeoning 'Software as a Fear Source' (SaFS) industry which will do its damnedest to spread FUD.

Incidentally, those that have read other things I've posted know that I'm opposed to sanctions as an industry. Not just because they're relatively ineffective, can have negative long term consequences for us and so on but also because we're developing a huge industry directly involved in anti-competitive behavior. This is going to end up strangling us -- as we all know, once bureaucracy is created it will never die, it will never cease to find reasons for its existence. It will hold us down while the rest of the world just goes on its way, bypassing the has-beens.

[Anonymous Coward]

Misdirection???....you know....."Someone Is Doing Something, so please stop worrying"!!!

Is a "software bill-of-materials" (SBOM) really going to help, say:

(1) When some software vendor (maybe a compiler vendor) is pretty keen on the "Ken Thompson" hack?

(2) When the ONLY way some of the hardware in a Linux box can be used is by loading a binary "blob" from the hardware originator?

(3) When you ask (for example) Cisco Systems for the SBOM(s) of all the software on the latest and greatest version of IOS? (Clue: many of the software items might be secret!!)

(4) ....and so on...

Oh....and I forgot to mention that neural networks (so called AI implementations) are VERY poor at explaining their conclusions.....and even worse when they "learn as they go"!! Good luck auditing the software....by the time it's been running for a few seconds, the audit horse is miles out of the barn!

Ref: https://dl.acm.org/doi/pdf/10.1145/358198.358210

Ref: https://www.schneier.com/blog/archives/2006/01/countering_trus.html

[Anonymous Coward]

SBOM = Pass the buck

The problem I see with the SBOM is the end user/customer is then expected to manage the risk around it, but that should be the job of the company who decided to adopt X registry, not the end user.

We buy cars, we aren't expecting to deal with the quality of rubber going into the tyres. IT products should be the same - it's a supply chain responsibility with each link along that chain responsible for it's step.

There should be legal ramifications for those not doing so, rather than simply lumping the entire responsibility on the end user as Talos seem to expect. not every company has "their own people" who can contribute to code even if they have an SBOM, which is fantastically unlikely at best.

[Richard 12]

Re: SBOM = Pass the buck

Yes and no.

It's not possible for any software house to even start managing the risk unless they know which components are in their products.

So far, all the tools are really about ensuring compliance with licensing terms. Not "unexpected change".

Though this is a far smaller problem for precompiled software as the toolchains have to do dependency management in order to actually operate, so "unexpected change" tends to be more visible.

"Web" apps seem to be built assuming daily upstream changes, making "malicious" change far easier to hide among the hundreds of other daily changes.

[Anonymous Coward]

I can highly recommend Dependency Track for your first steps into controlling this

As a CTO looking after a significant amount of Java and other languages I can highly recommend Dependency Track, dependencytrack.org, as a first step into controlling this issue and gaining visibility of your vulnerabilities.

I've gone from manually figuring out our exposure to CVEs to having a system email me and the architects when a new issue is raised that we should be aware of. I've been able to massively reduce the issues we have to worry about and set up process for handling new ones and deciding a course of action. Now we are much closer to handling one-off library updates little and often instead of putting off major library updates for years.

The other side is that we are benefitting from a multi-year hard investment in Katalon testing and our QA team to give us extensive coverage. This allows up to do platform upgrades with much less risk.