I built Subumbra because credential theft is out of control and the main advice seems to be panic and rotate your keys right away!
I never liked the idea of storing secrets or secure files on publicly accessible servers. Before this project, I experimented with split VPS setups where one server stored secrets behind an internal private IP while another handled public traffic. It felt better architecturally, separation of concerns and all, but at the end of the day the secrets were still plaintext on a device I didn't control.
After the LiteLLM incident, I started thinking harder about split-trust systems where:
-encrypted secrets could exist locally
-decryption happens off the main server
-plaintext credentials are never permanently stored
-apps continue functioning the same with no core edits or lag
I am not a security expert or even really a coder, so I figured this is obviously the perfect project for my first open-source “vibe coded” project.
Subumbra’s main goal is to reduce the usefulness of credentials that an attacker can steal from a compromised machine or server. It also helps reduce updating several env or config files after a compromise.
The system currently stores encrypted credential envelopes separately from the decryption authority. Requests use Key IDs and app tokens instead of plaintext credentials. Credentials are decrypted only during an outbound request in isolation, destroyed and are not returned back to the server.
I also tried to build some guardrails around abuse and credential extraction. Nothing is “hack proof,” but I tried to add the protection I assumed would benefit this type of system. The alpha still has rough edges and there are known gaps noted in the documentation.
Right now I have mostly tested it with OpenAI-compatible providers and LLM based apps because that was my immediate use case. Generic HTTP endpoint support is mostly implemented but not nearly as battle tested yet.
Long-term, I would like the system to broker secrets for things like: npm, PyPI, GitHub, AWS, CMS/ecommerce platforms, basically anything using API keys, tokens, or credentials.
Documentation and app comments are still rough, but I set a hard limit to release it before my birthday. I also hope to get feedback from people smarter than me before continually building based on assumptions rather than real world use.
I would appreciate feedback, criticism, ideas, and suggestions on where the system can improve and what secrets should be implemented next. Thank you for your time!
I built Subumbra because credential theft is out of control and the main advice seems to be panic and rotate your keys right away!
I never liked the idea of storing secrets or secure files on publicly accessible servers. Before this project, I experimented with split VPS setups where one server stored secrets behind an internal private IP while another handled public traffic. It felt better architecturally, separation of concerns and all, but at the end of the day the secrets were still plaintext on a device I didn't control.
After the LiteLLM incident, I started thinking harder about split-trust systems where: -encrypted secrets could exist locally -decryption happens off the main server -plaintext credentials are never permanently stored -apps continue functioning the same with no core edits or lag
I am not a security expert or even really a coder, so I figured this is obviously the perfect project for my first open-source “vibe coded” project.
Subumbra’s main goal is to reduce the usefulness of credentials that an attacker can steal from a compromised machine or server. It also helps reduce updating several env or config files after a compromise.
The system currently stores encrypted credential envelopes separately from the decryption authority. Requests use Key IDs and app tokens instead of plaintext credentials. Credentials are decrypted only during an outbound request in isolation, destroyed and are not returned back to the server.
I also tried to build some guardrails around abuse and credential extraction. Nothing is “hack proof,” but I tried to add the protection I assumed would benefit this type of system. The alpha still has rough edges and there are known gaps noted in the documentation.
Right now I have mostly tested it with OpenAI-compatible providers and LLM based apps because that was my immediate use case. Generic HTTP endpoint support is mostly implemented but not nearly as battle tested yet.
Long-term, I would like the system to broker secrets for things like: npm, PyPI, GitHub, AWS, CMS/ecommerce platforms, basically anything using API keys, tokens, or credentials.
Documentation and app comments are still rough, but I set a hard limit to release it before my birthday. I also hope to get feedback from people smarter than me before continually building based on assumptions rather than real world use.
I would appreciate feedback, criticism, ideas, and suggestions on where the system can improve and what secrets should be implemented next. Thank you for your time!