I saw your post a few months ago and already thought it was awesome. Congrats on quitting your job to devote yourself to this project. I would assume that you have considered joining YC?
I'm the founder of the OSS project windmill [1] 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 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 [1] to your main website so security researchers know how to report vulnerabilities.
With such a huge load of new features in such a short lapse of time, I wonder about the quality of the code.
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?
lucideer 7 days ago [-]
> Any considerations about security
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.
vmatsiiako 7 days ago [-]
Thank you so much for 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!
I would say the quantity of the features does not mean that their quality is bad. We are very grateful to our open-source community for helping us out with many of these features (e.g., custom environment names were developed fully by one of our contributors Akhi - https://github.com/akhilmhdh).
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.
Aeolun 7 days ago [-]
> Tests are also something that we are going to add very soon!
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.
llarsson 7 days ago [-]
Cool idea, and would love to take it for a spin!
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?
vmatsiiako 6 days ago [-]
This is very interesting - we keep hearing about this pretty frequently. Will definitely look into this
Alifatisk 7 days ago [-]
> Due to their licencing, you can't have a managed service provider host it for you (unless that provider is Mongo itself).
Had no idea!
ComputerGuru 7 days ago [-]
Congrats on the launch.
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.
Infisical's goal is to provide the main functionality to the community for free - only enterprise-level features will be paid.
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.
bityard 7 days ago [-]
> Frankly speaking, I don't believe in open-source projects without paid components
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.
vmatsiiako 6 days ago [-]
Yes, I think I phrased it in a wrong way. Sorry for misunderstanding.
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.
8n4vidtmkvmk 7 days ago [-]
The idea sounds good, but the Github is very buried.
ComputerGuru 6 days ago [-]
Thanks. I didn’t know which repo to link to since there is one for C# and one for rust.
whazor 7 days ago [-]
From my experience (running Kubernetes at home), the biggest problem is that secrets managers are used to bootstrap clusters. Having to run three deployments (backend, frontend, mongodb) is a lot for a component that is supposed to bootstrap the cluster. Especially the MongoDB component is annoying, as it needs an username and password. That is why Vault from Hashicorp is so good, it supports many backends and provides distributed integrated storage (Raft), which is perfect for bootstrapping.
varunsharma07 7 days ago [-]
How does this compare with secret managers like HashiCorp vault, Azure Key Vault, AWS Secrets manager, etc.? Are some of those needed to use this? Or can those be replaced with Infisical?
vmatsiiako 7 days ago [-]
The main goal is to provide similar levels of security at a significantly reduced learning curve. These services can all be replaced with Infisical.
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
spoiler 7 days ago [-]
> And indeed, while Vault has a lot of features, it is pretty overwhelming to setup and maintain.
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.
vmatsiiako 7 days ago [-]
That is true - that's also one of the reason why we made our pricing for Infisical Cloud per person/month.
zokier 7 days ago [-]
Hello sso tax on "let's talk" level
MollyRealized 7 days ago [-]
In this context, what does the noun (secrets manager) and adjective (secret versioning) mean? Asking for purposes of learning. If this is laid out on a particular "for dummies" page, linkage would be appreciated ('secrets' being such a common word otherwise).
I asked ChatGPT, but this appeared to be one of its "there-is-no-horsehead-in-Godfather" moments.
vmatsiiako 7 days ago [-]
Yeah! It's not a common term - just something that we call it
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
Well, this project seems to reproduce one of our features. It seems like they only sync environment variables. I couldn’t find any information about their API, UI, integration with 3rd party services, RBAC, etc…
I'm the founder of the OSS project windmill [1] 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.
[1]: https://github.com/windmill-labs/windmill
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 [1] to your main website so security researchers know how to report vulnerabilities.
[1] https://securitytxt.org/
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.
https://neosmart.net/blog/tag/securestore/
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