Where are the supply chain safe programming languages?
-
Programming languages currently offer few defences against supply chain attacks where a malicious third-party library compromises a program.
I think they're called, "write everything yourself"
-
Programming languages currently offer few defences against supply chain attacks where a malicious third-party library compromises a program.
I think they're called, "write everything yourself"
Which is exactly what's done in any safety relevant industry. Also, getting any OSS library to pass A-SPICE and MISRA is a pain in the ass, even worse if you must write them with built-in code path validation.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
Programming languages currently offer few defences against supply chain attacks where a malicious third-party library compromises a program.
I think they're called, "write everything yourself"
MSFT has made some subtle improvements to VS here. One thing is now in the nuget management where you can explicitly source packages. So you can specify exactly where each nuget package should come from so that you lean on internal corporate nuget feeds instead of nuget.org. You vet/add stuff to the corporate feed as needed. I think there will be more than few bigger orgs pushing to insulate their supply chains like this and keep internal vetted copies of the dependencies that go into their builds. It should've always been that way. Ancillary to this is protection in VS from source controlled repos being tampered with. Some supply chain attacks have happened because an attacker swapped the code in on the developer's machine so that the developer then committed the malicious code themselves. You might notice the newish "confirm this repo is legit" dialog. There are a few different "triggers" mostly to do with domains, vpns, and windows security (like if you clone a repo under one account and then try to use it VS with another account). This doesn't prevent an ever-malicious/compromised pkg from use. It just prevents you from sucking a newly compromised dependency into your build chain by sourcing things from yourself (even if they aren't your things - because you previously grabbed and cached a good copy).
-
Programming languages currently offer few defences against supply chain attacks where a malicious third-party library compromises a program.
I think they're called, "write everything yourself"
I must say that I've never understood why people thought it was a good idea to drag in code from libraries (potentially buried multiple levels deep) without validating them. As someone said not too long ago: Do you know what's in your code? It's exploits all the way down. The whole thing of automated library imports that some language tooling pretty much seems to demand is beyond bizarre to my mind.
-
I must say that I've never understood why people thought it was a good idea to drag in code from libraries (potentially buried multiple levels deep) without validating them. As someone said not too long ago: Do you know what's in your code? It's exploits all the way down. The whole thing of automated library imports that some language tooling pretty much seems to demand is beyond bizarre to my mind.
You mean we can’t trust that hyper-valuable is-odd library forever and ever? :wtf: (1.7 million downloads/month, 108 depending libraries)
TTFN - Kent