Where are the supply chain safe programming languages?

Pony has a concept of Object Capabilities[1]. Basically it lets you whitelist capabilities like network access or more granular access like specific protocol access. In the docs it states "If the library is asking for more authority than it needs, do not use the library."

This doesn't solve the problem of people pulling in huge dependencies that they can't reasonably scan, or so many dependencies that they can't scan, but surely it's a step in the right direction.

[1]: https://tutorial.ponylang.io/object-capabilities/object-capa...

It seems relatively well established that C requires a trusted environment. You need to have faith in your collaborators and in your toolchain, and in your dependencies, to get something that works reliably. This trusted environment is looking increasingly optimistic as time goes on.

The sandbox approach works relatively well where it's applied. If you're given a lua interpreter that doesn't know how to talk to the network, you're going to have a tough time compromising the underlying kernel to gain that capability. But your performance will be grim. Web assembly is roughly what you get if you run far enough down that path trying to engineer out the inherent limitations.

I wonder if the microservices people are onto something here. Some boundary around a unit marked "database" or "hashtable" that can't talk to the internet, something RPC themed to tie the pieces together, possibly all fed into a single address space to bring the performance overheads down to something reasonable. The problem is it's a huge pain to work with and makes the dev process slower, i.e. you get outcompeted by something broken-by-design that shipped faster.

It's an interesting problem space. Agreed with the OP that it seems underserved.

I feel like this is just going to end up like phone (android at least) app permissions where they give some vague justification to ask for every capability under the sun.

(a) I'm all for more widespread attempts at capability security*

(b) failing that, an alternate approach to the problem of deep and wide supply chains is vertical integration: just spitballing here, but we're programmers (and these days, it's even claimed we have AI support); is it too much to ask that most of us ought to be able to code up wheels that roll?

* free market mechanisms, at least as currently implemented, seem to me much better at figuring out how to compensate people after something bad has happened than at preventing it from happening in the first place.

.net actually does support a lot of what you are talking about, although the features are rarely used/enforced in reality.

You can use something like this with Ada/SPARK programing language https://wikibook-ada.sourceforge.net/samples/pragmas_restric...

I'd like to think that there are supply chain safer languages.

Which are languages that have a large comprehensive official standard library backed by a large corp.

Those corps have the manpower to better audit contributions.

Examples: Microsoft's .NET (C#/F#) and Google's Go.

I have one literally withering on the vine.

I released it today. A week ago, I released a blog post that mentioned [1] a supply chain-safe build system and language.

Despite that post and the traction it got, the 6-hour-old Show HN is already long gone, not even on the first 10 pages.

Long ago, Java had something for supply chain safety in the form of SecurityManager. It was removed.

There are no supply chain-safe languages because the industry doesn't care.

[1]: https://yzena.com/2024/03/what-computers-cannot-do-the-conse...

Maybe I am missing something,but it sounds like the features the author is looking for could be part of an OS, not a language. For example:

> An example is that a hash table lookup function should be unable to connect to the internet. That way the function can be used without fear of it becoming a liability if it contains bugs or its source code is manipulated by an attacker.

Reminds me of OpenBSD's pledge [1].

[1] https://man.openbsd.org/pledge.2

World looks weird. All need infrastructure existed in 1990s in Ada, Modula-2/3, IBM works (even with hardware security, which still exists in Power machines), but nobody care.

Now, sure all these things outdated, somebody have to rewrite ocean of code, add support of modern architectures, device drivers, even to teach people, as most programmers from that niches already retired, etc.

I liked the idea, but as I was reading it I realised that if we could provide that level of isolation within software, it would solve many of the issues of software security in general. And it would really need to be provided at the O/S layer.

I wondered when it was going to start talking about capabilities and I was not disappointed!

Supply chain security is a tool chain problem, not a language problem. Unfortunately, I don't think this author is able to contribute anything useful to the topic currently.

I feel like the article misses the point, tho. The xz attack didn't happen because of an unsafe language, but for it's legacy build tools and social engineering. The relevant backdoor part about patching a vulnerability into C code, could just as well have been skipped/changed for another form of persistence/RCE. In the end, the original sin of breach was smuggling and execution of the malicious build script and payload, if I understand correctly. I don't see how a capability sensitive language would have prevented this, assuming the build environment remained the same.

Of course certain features of a language are exploited, but for a supply chain attack, I think the real vulnerability is complexity, neglect, carelessness, social pressure and (arcane) code beyond immediate comprehension. Since, before any malicious xz code was shipped, the human element was manipulated and exploited. The same pull request about the introduction of IFUNC, could have been about extending capabilities for another made-up reason. The same exploitation of trust, which allowed packing malicious scripts, would have allowed for... well, packing malicious scripts.

With the xz backdoor, the vulnerability was large chunks of infrastructure being the burden of a single human. I really don't see how this attack dynamic could have been prevented by language design alone. Sure, you wouldn't attack a compression library, if capabilities were tight. You would attack the neglected privileged code base elsewhere...

Ok, lets be realistic about our threat models.

This attack wouldn't have done much if you were running fast and loose with dependencies but had proper layered network infrastructure. There should never be a single point of failure where a single supply chain attack, 0-day, insider threat, etc should be able to kill you and it's not that hard to achieve this.

Put your shit inside a VPN, secure the systems inside the VPN as if they're connected directly to the internet, vlan or even airgap systems that are hyper critical, etc.

I build satellites where we actually do some of the supply chain caching and review, but it's for very specific things that are absolutely mission critical and the risk of >0days is lower than the risk of a memory leak locking up a system.

Think critically about what it would take to access and pivot within your network.

Almost no one grasps, or interested in, formal verification. It's difficult to get software devs to even do unit testing much less prove their compilers always produce correct code.

Do not use dependencies. Implement everything from scratch. Maybe having a huge reviewed std library solves this, if you never need to import anything from a third party.

As long as there are supply chains there are attacks. reduce your dependencies to bare minimum.