Stop sharing your variables in Slack

Onboarding sucks

The delicate balance of providing enough information so an employee feels informed while not having their brain explode from too much data can feel impossible at times. When I onboarded at Henry Schein One this past January, I cannot even begin to describe the stress and anxiety that came along with my first few days. Learning everybody's name, their role, who they report to, who reports to me, it was a lot. I do not mean to slight my co-workers in any way. They did a great job and my boss Jen provided that guiding hand when it was necessary. But despite all the back and forth of this process, things can be lost in translation. What's worse: this is just the human side of onboarding.

Minimum viable setup

The part that can be even more stressful than remembering your new computer password as part of your onboarding journey is configuring your development environment (queue the "dun dun duuuunnnn" sound effects). Let's assume for a second you are lucky enough to have decent documentation and tutorials that have been written by someone else in your organization to aid in your setup. You are still likely going to be missing some key pieces of information or files to complete your environment. This could be a backup of the database, API keys, OAuth token pairs, or SSL certificates. Whatever it is, handing these things off to people can be hard. So what do we usually do? Copy and paste or drag and drop these files and environment variables into the team's Slack channel. It's quick, it's easy, and at least it's more secure than sending them via email. Or is it?

Collaboration tools are a crutch

We are all guilty of using collaboration tools like Slack and Teams to share information with our teammates that is sensitive. Again, this could be a password, API key, or even an RSA secret. Everything in the workplace is about speed. Gotta get this done fast, send that faster, are you using AI like you should to code this feature faster? It's an endless cycle. But are we really that safe? GitGuardian’s State of Secrets Sprawl 2025 says 38% of incidents in collaboration tools were classified as highly critical or urgent, higher than in code repositories. Its 2026 report says ~28% of incidents now originate outside source code in tools like Slack, Jira, and Confluence, and more than half of those collaboration-tool incidents were critical. So despite the bullet-proof security provided to us by the folks in the IT closet and the guarantees from the guys at Salesforce (Slack is owned by Salesforce in case you didn't know 😜) and Microsoft, we are still susceptible to breaches. All because we need to share something quick!

The usual suspects just didn't cut it

So if it's soo easy to compromise these pieces of information, why don't we do it more often? Other than laziness (I can say that because I'm guilty of it too), credential storing processes usually take time to set up and maintain, not to mention the DX (developer experience) is garbage. Sure, there is AWS Secrets Manager and HashiCorp has their solution. These are all viable, but again, their flexibility is also what makes them difficult for most developers. When retrieving a list of secrets, everything is returned in JSON. Most frameworks do not leverage JSON as their method of secret management. Configuration and customization: absolutely. But the source of truth is usually a DotEnv file or .env located in the code base that needs to be written and formated in a special way.

I didn't like the options I had in front of me. For a while I used some self-hosted open source tools, and they worked. But as soon as the maintainer abandons the project and the application goes into deprecation hell, you are screwed. Like I said above, there are enterprise solutions. However, these require some time to set up, can be insanely costly even for a small implementation, and can lack the developer experience that I also referenced. This is why I wanted to come up with my solution, something that I knew would answer this question that I knew was important.

This is why I developed SecretStash.

My own solution

SecretStash is a developer-first platform that helps developers securely manage and share environment variables across teams, applications, and environments. This can easily and quickly be done by installing one of the first-party CLI packages and begin interacting with the zero-knowledge cloud service; all within about 1-2 minutes. This ensures your credentials are securely stored away and cannot be retrieved, even in the event of a data breach. You can then invite your teammates to reference the same variables across environments to ensure you are all in sync.

Click here to get started for free.

It's hard, I get it

Being a developer myself, I know how hard secret management can be. These hardships double and even triple when you begin to look at how the CI / CD process will be impacted by rotating tokens. These things should be easy, or at least that's what I thought. But after some research and failed open source projects, I came to the tough realization that I was going to have to solve this "secret sharing issue" myself. SecretStash was the result.

So in the future, stop uploading your .env files into Slack or Teams, just use SecretStash. Your IT team will appreciate the added security as well.