Insight: 21
Thank You, US Border Patrol
I don't have a Border Patrol problem, but I do have a problem with environment variables.
A couple weeks ago, I noticed an article in the New York Times about someone who was stopped at border control. Border Patrol requested access to his machine, or more specifically, demanded access to his phone. He handed them the phone, and when they requested a code, he gave them a code that caused the machine to brick. He’s now been charged with a federal crime.
A U.S. Citizen Deleted His Phone’s Data. Now He Faces a Felony Charge.
Honestly, I don’t have any of those problems. I’m not really worried about my machine being looked at. This article made me think I don’t really have this problem, except that I kind of do.
I carry a laptop with me, and my laptop has access to the codebases of 15 to 20 clients. Each one of these codebases has environment variables. If someone were to force me to log into the machine, they could get access to 50 different companies and 50 different environment variables that would give them access to client materials that are technically covered under an NDA.
This made me think, huh? I don’t have a Border Patrol problem, but I do have a problem with environment variables.
I have no desire to hide data in a legal search, but I do have an NDA. For each client. So the ability to hand over the machine, but know that I am not violating the security requirements for clients is key.
Travel with a wiped version
Years ago, I worked with a company that had severe hacker risk from state intelligence agencies. The evaluation at the time was: don’t travel with your laptop or your phone. Travel with a wiped version that doesn’t have all the history and everything else.
If you’ve been raising money, if you’re working with confidential data, and that’s on that laptop, you may not be as safe in Mexico City in a taxi. Or it could be as simple as the laptop gets stolen, and you have no way to know how much vulnerability is on that machine.
If the machine really never has the variables in the first place, and they only are accessible at runtime, you’re fine. It’s perfectly fine to hand my laptop or my phone to the Border Patrol, because while they can see the artifacts of the work, they can’t get access to things that they have no access to or right to. They would have to go get a subpoena to get that. If their target is one of my clients, then my clients have a right to have their attorneys weigh in and control this. I’m not hiding data. I’m just not carrying that data in a way that is sensitive and easy to share.
There might be a better way
First, when I work on a team with other developers, we regularly have environment variables that are changing, and so we keep them in the local .env file. When someone jumps on a project, I need to give them a copy of the env file, but if I have three different developers, there could be three different copies. We’re always playing, “Hey, who has the right keys?” Sometimes we do that with a secure program, sometimes we do it with 1Password. I thought about this and said, “This is really not great.”
Note: .env is a coder practice of putting secrets into a local file so that when the app starts locally it reads the variables. It keeps a builder from hardcoding these values in the code.
And the second problem I noticed is that my server variables, when I come up with a new environment file, I need to store it somewhere. I have to put it on a server, but if I lose that, it’s one-way. Once I give it to Supabase, I can’t get it back again. Env files are dangerous. We know not to commit them to code, but we do let them sit around on our machines for years. We do share them. Honestly, we shouldn’t, but we do.
I started going deep and thinking, “There might be a better way.” I started getting into two different products, Doppler and Infisical, and I found Infisical to be the one I cared most about. I wrote it up in the tool book.
I now don’t have env files on my local machine. I actually don’t manually set environment files on my server. I set up Infisical. I store all my environment variables there. When my local machine starts, my machine knows how to reach up, log in, grab a copy, and inject them into the runtime. I actually technically don’t know what my environment variables are.
When I have multiple servers, if I change an environment variable, I can deploy it, and it auto-deploys out to Cloudflare, AWS, or Heroku. When I work with a team, I can give my team access to one project or another, but as soon as they’re done with that project, technically I can follow SOC compliance and cut off their ability. I can rotate my keys fast and easily. I can say, “This is all of my tokens for my Cloudflare tunnel,” and that means that I can change it in one place and deploy it to all of them.
If someone steals my laptop, I can sever my API keys or my login sessions, and it doesn’t brick. It doesn’t delete. It just means that there are no environment variables there.
I like solutions that are subtle and simple, that solve multiple problems with one. Since I discovered this on three different projects, I went through, upgraded all my projects using AI, and injected all the variables. The end result is that I actually have a far more stable configuration. The other big win for this is that Infisical is perfectly good at segmenting off a group of variables that I can give to an agent.
One small issue in the New York Times led to an insight that dramatically improves my ability to deliver value to the client.
I know in the security world that no one really cares about security until there is an insurance risk, a sales risk, or a legal problem. Even in large organizations with the CIO, we still find that data leaks sideways. If you want to stop data leaking sideways or security holes, then you remove the ability for human effort to be the solution.
I had a manager at a startup when I first got started in the late and early 2000s who was an owner who got fired and escorted to the door because he was sloppy with environment variables. The client found out, and the contract was pretty brutal. If you’re launching something, even if you’re a seasoned developer, you need the ability to know that what you launch is safe.
A simple prompt
Here is a simple prompt that you can do from Cursor, Bolt.new or Lovable.
Review my codebase and the variables and secrets. Then I want you to connect to my Infisical account, and store each variable. Once we have them all set up, I want you to update my local development setup so that these secrets are accessed when I start my local work.
There is more you can do, but this one is huge. And it can be used in any AI tooling setup. You do not need to be a coder. If you are a vibe coder, same process.
If you want a second pair of eyes on how secrets sit in your stack, book a Tech Stack Clarity Check (15 min).