I'm the founder of the OSS project windmill  that, among others, separates the code logic from the management of secrets. We are in the same boat of being a small team doing too many features and hence have covered very lightly the secret management. I would love to see if we could write some integrations between our projects so that scripts and workflows could leverage advanced secret management.
You’ll be surprised but I actually heard a lot about windmill - would love to talk! I sent you a LinkedIn invite
You mention password-based encryption of user private keys, do you have more information on how it's done? I can think of a famous "secret manager" that got this very wrong recently.
Also, when you have the time, consider adding a security.txt  to your main website so security researchers know how to report vulnerabilities.
I quickly glanced at the GitHub repository and basically couldn't find any test for example.
It'd be fine for any other startup, but this is something hosting seriously sensitive data and I feel like the focus is not right.
Any considerations about security you can share?
The copy on their website is somewhat non-committal on this:
> Infisical uses end-to-end encryption (E2EE) whenever possible [...] it makes no security guarantees for malicious events that can occur beyond its control [...] we do our best to maintain platform privacy and security [...] we will be adding more opt-in security measures
> -- https://infisical.com/docs/security/overview
Don't get me wrong - I do prefer honesty over empty promises and hot-air, but the above caveats seem worded as if intended for a legal document, rather than copy selling your product.
As for the code - on cursory scan it's three apps: a CLI written in golang, a frontend on next.js, and the backend is a NodeJS express server backed by mongodb, with 1042 transitive NPM package dependencies. That doesn't indicate anything in and of itself, but it's a lot of surface area (and growing if their README roadmap is anything to go by).
None of the above is a major red flag though - certainly things one would expect (& much much worse) from any closed-source competitor (just those don't have the transparency to check it out yourself). Yes, the focus does seem to be on feature addition & iteration though rather than instilling confidence in a solid, secure core, which is a bit of a pity, but all that said it would take much more than a cursory glance to audit properly, and they've stated they intent to have a full professional independent audit this year, so probably best to just wait for that. The fact it's open-source out-the-gate is extremely promising.
100% going to keep an eye on this.
I agree with all of your points. This phrasing is just something we need to write for legal reasons - if you check vault, you will see that they have similar words in their TOS.
We are currently still in public alpha - with time, Infisical will become more stable and the security measure taken will only improve from here on! As we mentioned earlier, we do want to go through the security and compliance audits this year.
We will be working on reducing the number of dependencies - stay tuned!
If you are interested, please join our Slack community to stay updated: https://join.slack.com/t/infisical-users/shared_invite/zt-1k...
Quality of the code is something that we care about increasingly more as we go further. We currently have a huge frontend revamp in process that will make the code much more organized and clearer.
Tests are also something that we are going to add very soon! Currently all the testing is manual - but I must say it's a pretty extensive process, so the quality of features is maintained.
Famous last words.
I used to say this for years before we finally got around to it, but at that point it had become such a chore (and the team so used to not writing them) that it took much longer than necessary to add any.
Start while you still can.
Feedback: the MongoDB dependency is annoying, from an enterprise (self-hosting) perspective. Due to their licencing, you can't have a managed service provider host it for you (unless that provider is Mongo itself). I have not looked into what data you store, but I can't imagine it's that schema-less at this point, so perhaps it could be possible to store in an SQL database instead? Or in PostgreSQL via its JSON support?
Had no idea!
For anyone looking for an open source community project without business aspirations in a much simpler and easier to audit format, have a look at SecureStore. It's encrypted and versioned secrets stored alongside your code in your git repo. Cross-language, cross-platform, with native libraries for different languages/frameworks. Useable by teams big and small, up until the point you want a standalone, full-fledged secrets management server and are fine with adding that heavy network dependency to all your services.
Frankly speaking, I don't believe in open-source projects without paid components (and this can be in different ways) - there have been so many examples of rug pulls for full FOSS just because maintainers are tired of running the project and there is no money to support it.
Can you clarify your scope here? I mean, there are thousands of of active projects out there maintained by their creators or communities and are not monetized. They contribute to open source because they get enjoyment from working on the project, participating in a community around it, or derive meaning from putting something nifty into the world.
Making money in relation to open source projects is not a new idea, but the notion that every good idea needs to be monetized certainly is pretty recent.
What I mean is that there is a point until which the open-source project is not popular enough to be fully supported by the community. If this point takes too long to reach, and there is no way to financially support the project - the project might go bust or stop being maintained. We’ve seen it happen with quite a few even very popular projects.
Which is why personally I think the best way to build a sustainable open source project that is helpful for the community is to provide the most needed functionality for free and find a way to monetize the enterprise-level features.
When we spoke with engineers that work in companies of all sizes - most of them have mentioned how complicated Hashicorp Vault is. And indeed, while Vault has a lot of features, it is pretty overwhelming to setup and maintain.
With Infisical, we want to take a modern approach to secret management by simplifying the whole process of configuring secrets to injecting them into your stack with little friction as possible. We invested a lot in the UI/UX in order to make everything more intuitive for developers when compared to Hashicorp Vault or any other alternative.
Also, Infisical is meant to be multi-cloud unlike the cloud-specific secret managers/vaults. Give it a go and let me know what you think
I generally like Vault, but on top of being a bit overwhelming to set up, it's also quite expensive to run in a HA setup.
I asked ChatGPT, but this appeared to be one of its "there-is-no-horsehead-in-Godfather" moments.
Secret can technically be any piece of information (e.g., API-key, credential). Though it may also include some non-sensitive data like environment variables
Secret versioning is a feature which tells you how the secret was changed over time (you can think of it as google docs history); it also tells which user it was modified by