We use proprietary tools (QNX compiler, Coverity static analysis, ...) and those require access to a license server which requires some secret.

I don't really understand what you mean by "secure enclave style"? How would that be different?

▲

amluto a day ago | parent [-]

With a secure enclave or an HSM, there's a secret, but the users do not have access to the secret. So, if you have a workflow that needs to, say, sign with a given private key, you would get an API that signs for you. If you need to open a TLS connection with a client certificate, you get a proxy that authenticates for you.

I suppose I would make an exception for license keys. Those have minimal blast radii if they leak.

	▲	gcr a day ago \| parent [-]
		And how is that exposed to the CI/CD? An environment variable? Some bespoke tool that the CI runs to read the secret from the Secure Enclave? Your approach boils down to “lets give each step its own access to its own hardware-protected secrets, but developers shouldn’t otherwise have access” Which is a great way to “support secrets,” just like the article says.