4 ms·

Thank you for pointing this out! Happy to take a look and discuss what you're building! I agree with some of these tips, but I think it's best to report them pr

Thank you for pointing this out! Happy to take a look and discuss what you're building! I agree with some of these tips, but I think it's best to report them privately to team@infisical.com. We can then see with our team if these points are correct. Otherwise, this goes against responsible practices of security notifications and sounds more like an ad for your project.

pc86 4y ago
Wow, this comment is more than enough to make sure I never use your product.
ianpurton 4y ago
OK. I'll stop looking now. However if you do require a security review then I would be happy to oblige.
sveme 4y ago
You open-sourced your code - isn't this scrutiny exactly what you would want to achieve? Alternatively, I would expect these reports to be reported via your issues tracker.
- dangtony98 4y ago
  Yup! We appreciate feedback we can get across all aspects including security but employ a security policy of reporting any security concerns via email - this is pretty standard practice we've seen.
  - whylo 4y ago
    > employ a security policy of reporting any security concerns via email You don't have a security.txt, https://infisical.com/docs/security/overview https://infisical.com/docs/security/overview doesn't mention it and it's not on your FAQ, so I don't blame ianpurton for not finding it. You have a 'Report a vulnerability' issue template on GitHub (https://github.com/Infisical/infisical/security/advisories/new https://github.com/Infisical/infisical/security/advisories/n...) but then your readme points to a security policy which says to email: https://github.com/Infisical/infisical/security/policy https://github.com/Infisical/infisical/security/policy
    - dangtony98 4y ago
      There are 3 different locations in the GitHub repo regarding the security policy: a SECURITY.md file containing instructions to report security vulnerabilities to team@infisical.com — this is employed in other open core repos like Strapi, PostHog, Chatwoot; a security policy on the sidebar that links to the SECURITY.md; and a security section in our README that also links to the SECURITY.md. There's also an issue template for reporting vulnerabilities as well as you mentioned. That said, we'll add info to the security page in our docs to contact us regarding vulnerabilities. Thanks!
  - 1ba9115454 4y ago
    Standard practice is to do a full security audit before you onboard customers.
    - dangtony98 4y ago
      We're preparing to do a SOC2 with Vanta first followed by a security audit with some firm like Trail of Bits next. We're fortifying the codebase every day and would expect this process to be complete in the next 2 quarters.
      - Implicated 4y ago
        > the next 2 quarters 6 months? I'm not being sarcastic here - I'm not on the security or enterprise side of things, but this seems like a long way off for something like a secrets manager. Just out of curiosity, what would hold you back from doing this _prior_ to launching?
        vmatsiiako 4y ago
        I completely agree! I must say though, this is not fully dependent on us! SOC2 is a very lengthy process that also depends on auditors. This is one of our main priorities at the moment.
        dangtony98 4y ago
        Getting certified is unfortunately not an overnight task … SOC2 alone will likely take months and that’s not yet factoring in the security audit as well. As much as we’d like to have it done ASAP, a lot of it is dependent on the length of the process and requirements to be met - that’s why my estimate is within the next 2 quarters (sooner the better). As an open source company, we’ve basically “launched” since the moment we open sourced the codebase - it’s a constant iteration process for us and every week we release security updates as part of our roadmap. Security certifications and audits are something we’re starting to do in parallel at the moment whilst still being early in our journey (open sourced 3 months ago roughly).
camjw 4y ago
> sounds more like an ad for your project I feel like somehow your response is the opposite of an ad for your project.
JoBrad 4y ago
I took it as establishing credentials. They didn’t compare your project to their’s, and they offered helpful alternatives.

pc86 4y ago

Wow, this comment is more than enough to make sure I never use your product.

ianpurton 4y ago

OK. I'll stop looking now. However if you do require a security review then I would be happy to oblige.

sveme 4y ago

You open-sourced your code - isn't this scrutiny exactly what you would want to achieve? Alternatively, I would expect these reports to be reported via your issues tracker.

dangtony98 4y ago
Yup! We appreciate feedback we can get across all aspects including security but employ a security policy of reporting any security concerns via email - this is pretty standard practice we've seen.
- whylo 4y ago
  > employ a security policy of reporting any security concerns via email You don't have a security.txt, https://infisical.com/docs/security/overview https://infisical.com/docs/security/overview doesn't mention it and it's not on your FAQ, so I don't blame ianpurton for not finding it. You have a 'Report a vulnerability' issue template on GitHub (https://github.com/Infisical/infisical/security/advisories/new https://github.com/Infisical/infisical/security/advisories/n...) but then your readme points to a security policy which says to email: https://github.com/Infisical/infisical/security/policy https://github.com/Infisical/infisical/security/policy
  - dangtony98 4y ago
    There are 3 different locations in the GitHub repo regarding the security policy: a SECURITY.md file containing instructions to report security vulnerabilities to team@infisical.com — this is employed in other open core repos like Strapi, PostHog, Chatwoot; a security policy on the sidebar that links to the SECURITY.md; and a security section in our README that also links to the SECURITY.md. There's also an issue template for reporting vulnerabilities as well as you mentioned. That said, we'll add info to the security page in our docs to contact us regarding vulnerabilities. Thanks!
- 1ba9115454 4y ago
  Standard practice is to do a full security audit before you onboard customers.
  - dangtony98 4y ago
    We're preparing to do a SOC2 with Vanta first followed by a security audit with some firm like Trail of Bits next. We're fortifying the codebase every day and would expect this process to be complete in the next 2 quarters.
    - Implicated 4y ago
      > the next 2 quarters 6 months? I'm not being sarcastic here - I'm not on the security or enterprise side of things, but this seems like a long way off for something like a secrets manager. Just out of curiosity, what would hold you back from doing this _prior_ to launching?
      - vmatsiiako 4y ago
        I completely agree! I must say though, this is not fully dependent on us! SOC2 is a very lengthy process that also depends on auditors. This is one of our main priorities at the moment.
      - dangtony98 4y ago
        Getting certified is unfortunately not an overnight task … SOC2 alone will likely take months and that’s not yet factoring in the security audit as well. As much as we’d like to have it done ASAP, a lot of it is dependent on the length of the process and requirements to be met - that’s why my estimate is within the next 2 quarters (sooner the better). As an open source company, we’ve basically “launched” since the moment we open sourced the codebase - it’s a constant iteration process for us and every week we release security updates as part of our roadmap. Security certifications and audits are something we’re starting to do in parallel at the moment whilst still being early in our journey (open sourced 3 months ago roughly).

camjw 4y ago

> sounds more like an ad for your project I feel like somehow your response is the opposite of an ad for your project.

JoBrad 4y ago

I took it as establishing credentials. They didn’t compare your project to their’s, and they offered helpful alternatives.