AlwaysNewb23

If you stretch the definition a bit, I still like the site as an example of a site that appeals to developers and isn't just marketing fluff.

I really like Midjourney (https://www.midjourney.com) just because it looks cool.

This is why you should use a secrets manager like Doppler (https://doppler.com) or AWS Key Management Service (AWS KMS). Hardcoding your secrets or storing them in .env files will always risk something like this happening.

How hard would it be to add support for Doppler (https://doppler.com)?

Good point. I'm going to trim some of the fluff off of that tldr.

I wouldn't have expected to see Augmented Reality (AR) Marketing as one of the trends listed in this post. I think we're a little far off from it being a truly viable tactic.

Yeah this article title is a little misleading.

At least they didn't blame 'supply chain' issues.

I like the design of Heinz's 404 page. Mostly because of the clever use of ketchup in the design. https://www.heinz.com/404

Did anyone else need to read the pricing a few times to understand it?

You should know what they are doing and keep an eye on them, but I think it's important to be careful not to copy them and solve problems in your own way.

We've been using commit messages to tell a story using our git history and it's improved our code review process. By doing this, we've created a commit history that clearly details all the steps leading up to each change. By organizing our commits this way, we’re making our PRs easier for others to understand and giving ourselves a chance to refine our work. We also often spot opportunities to simplify or improve the code that we might have missed the first time around.

This is really impressive. Do you plan to use it for anything or another project?

The biggest impact seems to be on team culture. I would love to know if anyone has tired something similar.

Thanks for clarifying this.

Thanks for taking the time to write this up. You shared some interesting opinions to consider.

"I absolutely refuse to use a security service that's hosted on the cloud." - I run into this a lot.

"Every cloud service will be hacked" - I totally get this. It's the reason it's hard to build trust for a cloud service.

I've always liked this model for my own projects. However, I'm not sure it really builds trust, especially from a security standpoint. Open sourcing could mean more eyes on the code, potentially leading to better security through community audits. Yet, it also means exposing the inner workings to everyone, including those with malicious intent. A hosted version does offer a layer of professional oversight, which is reassuring, but I wonder about the implications for users who opt for the self-hosted route. How would you ensure they feel confident in the security and reliability of the software, knowing that they have the same access to the code as anyone else?

I would love to hear more thoughts on balancing these aspects to build and maintain trust with users.

Tracking for you and your team. So if a developer on your team goes rogue, you know when and what happened, just like how you can see who committed when and what on GitHub.

Your backend is as secure as you make it. The critical point is that if designed properly, this method is better than directly storing and using API keys from within your app.

I can assure you that another Software Engineer at Doppler and I wrote this blog - not AI. Feel free to ask anything. Thank you for the feedback.

Doppler is exploring adding the ISO 27001 certification in the near future.

Doppler (https://doppler.com) is my preferred tool for storing API keys. It centralizes where you manage all of your environmental variables and makes it so you never risk exposing your API keys in a code repo. There's a CLI tool that makes it easy to use all of your environment variables while you're developing and a ton of integrations for wherever you prefer to deploy your code. Feel free to ask me anything about Doppler or secrets management - I'm a developer advocate at Doppler.

Audit logs for secret managers are an underrated feature. It really helps to encourage best practices as well as track changes.

For personal projects, it's probably fine to just use environmental variables and .env files the traditional way. The security risk really increases when you start to scale and work with other team members.

Are you familiar with the recent Mercedes-Benz Source Code Exposure [1]? It's a good example of why you should consider a secrets manager for any serious project. Environment variables come with a lot of risks and are difficult to manage as teams grow. 1) ENV files are easy to accidentally push to a repo. 2) It's easy for environment variables to get out of sync among developers. 3) In the case of exposure, it's often difficult to rotate secrets quickly. A secrets manager removes this risk - but you do need to trust whatever service you decide to use, as well as make sure it's compatible with your infrastructure/cloud environment.

[1] https://www.doppler.com/blog/lessons-from-mercedes-benz-sour...)

A secrets management service would be most convenient. Documentation makes them easy to set up without having to build anything extra yourself. A secrets manager like Doppler (https://Doppler.com) or AWS Secrets Manager (https://aws.amazon.com/secrets-manager/) has the advantage of protecting your secrets in a secure place and the advantage of minimizing exposure of those secrets - even to your own developers. That way, you don't end up with a data breach that could have easily been avoided. These types of leaks can cost companies everything and are becoming way more common.

You are very correct but it’s also not on the dev product teams to decide the best practices for secrets at large companies. It’s the responsibility of the security and devops team to implement best practices.

Yes- More people need to know secrets managers exist and the types of problems they solve. I'm passionate about helping people discover and understand what secrets managers do. Using any secrets manager would be better than none at all - it does not need to be our solution as there are plenty to consider.

Yes I am. More people need to know secrets managers exist. Doesn't have to be Doppler - but they should be used more often.

It seems like they made a lot of assumptions that something like this wouldn't happen. They assumed employees would never leak secret information, and that their GitHub repos would never be exposed. They could've used https://doppler.com or AWS Secrets Manager (https://aws.amazon.com/secrets-manager/) and never had this problem. It's a little too easy to get comfortable thinking things work well the way they are. This should be a warning to other companies to seriously evaluate how they're storing and managing application secrets and credentials.

What I want to know is how are they not using a secret manager (like Doppler or AWS Secrets Manager) at a company of this size? They could have avoided all of this. These types of leaks can cost companies everything (from their data to customer trust).