[slajax]

Founder here - 100% not. We've build a specialized PaaS that ensures your credentials and workflows are encrypted and there is no additional security vector here. Also Slack is one of our investors and they have worked with us a great deal to make sure that the security is handled properly!

[throwaway29102]

It’s going to take a lot more detail than that to convince me to let this anywhere near infrastructure I care about.

Care to elaborate for the skeptics reading this?

Investment <> Secure

[slajax]

Of course, generally difficult to explain in HN threads but there are a number of things at play here...

The first is secrets + credentials. You can use our hosted vault or bring your own vault so that your credentials are encrypted and can only be accessed directly by your user code.

The next ACL - we set up teams so that you can control which Slack channels (private or public) they can run in, to deeply control who has access to the workflow. Even if someone has access to the workflow, they can't see the secret as if it's printed, we remove it from the output. Additionally, we push your user outside of Slack (browser or CLI) to manage secrets.

Next, is the actual PaaS itself. Slack doesn't know what's being run, they just send us a webhook and we deal with executing the workload, completely outside Slack. Slack is just a client, it doesn't really know anything about your systems or workflows.

Next is the shared workflow environment, which has multiple layers of virtual sandboxing to ensure, what runs inside your container, only runs inside your container. You can make requests to external wide area network io or inside your container to disk. All of this goes through a sidecar type analysis that we use to ensure security at a very granular level for anything that runs inside these systems.

Lastly, Slack never has access to your code. They are simply the client which tells our platform to run it and in a secure enterprise case, our PaaS can run inside your VPC, which gives you full control end to end as long as you are willing to let Slack send you HTTP request - but this is a standard expectation for any Slack app, we just dramatically simplify it.

I've been thinking about doing a detailed blog post about this in the near future, so i really appreciate these questions!

[deeblering4]

What prevents a slack employee from issuing chat commands as an authorized user? Similar to what we saw in the recent twitter hack.

[slajax]

Well first of all, as a public company Slack is held to extremely well regulated security protocols to ensure this never happens, so we get the benefit of that out of the box.

Additionally, we require the user to associate their Slack user to their CTO.ai account using a secure authentication layer that has dependencies outside of Slack.

Theoretically, if a Slack employee were to try to execute a workflow, we would be able to see that they don't have this privilege and flag / reject that request because they wouldn't have the CTO.ai associated membership.

At this point, it's just as secure as any web application or even CLI, which have better understood virtual and physical attack vectors. We take it a step further by ensuring that tokens MUST be vaulted, avoiding the chance that you leak them through a lost laptop or public commit.

We're also looking at 2fa for some of our enterprise use cases and have been working on a deeper integration with Slack enterprise grid which makes this even more secure.

Are there additional approaches you'd recommend we take here?

[dvohro]

Looks like their secrets feature pops you out to an external site where you have to authenticate separately, and the secrets are entered there, and stored for later use. Check out their video, seems they thought it all through

[slajax]

Thanks, we've tried to re-think DevOps from a Slack first point of view and this was a major consideration so I'm glad to see you recognize it but we've still got a long way to go and we're very open to feedback too!