What’s the reason this repo is archived? It looks useful. https://github.com/Escape-Technologies/py-multiauth
Launch HN: Escape (YC W23) – Discover and secure all your APIs
31–40 of 40 posts
Re: Launch HN: Escape (YC W23) – Discover and secure all your APIs
#32I know you're writing for a technical audience and not investors, but if you can't grab my attention without a wall of text, sorry, tldr.
You're not the audience for this post.
Re: Launch HN: Escape (YC W23) – Discover and secure all your APIs
#33What’s the reason this repo is archived? It looks useful. https://github.com/Escape-Technologies/py-multiauth
Hey there, so py-multiauth is a great project that we love, but it didn't get enough attention from the community for us to afford to maintain it outside of our main codebase.
Since then, we have completely revamped it to create py-multiauth v2 that supports basically all form of authentication as you can see in the docs https://docs.escape.tech/authentication/
py-multiauth v2 is not open source for now, but our eng team might be ok to open source it if there is interest from the community
Re: Launch HN: Escape (YC W23) – Discover and secure all your APIs
#34Who watches the watchers? If I understand the product correctly, you're suggesting customers opt into letting an LLM pentest their testing systems, and allowing that LLM to generate and carry out plans of attack. Imagine a recurring revenue business that keeps tokens for user credit cards on file, and then a dev naively gives the CI infrastructure an ability to call out/proxy some calls to production in a privileged…
Hello btown, you are indeed raising legitimate questions here. You are right in the sense that using automated security testing tools in production creates a risk. But there are workarounds: 1) Most of Escape's security scans happen on staging or pre-prod environments, where there is little risk of breaking something critical or finding real customer data. 2) We have designed a specific scan mode for production APIs,…
> It will not attempt the riskiest attack scenarios
What does that mean exactly?
Do you manually assess what is risky for a particular API, or is it up to the system to choose?
If it's up to it, what happens if it thinks that's not risky to delete user data?
Re: Launch HN: Escape (YC W23) – Discover and secure all your APIs
#35Could you clarify the meaning of the term "Developers covered" as mentioned on the billing page?
Re: Launch HN: Escape (YC W23) – Discover and secure all your APIs
#36I know you're writing for a technical audience and not investors, but if you can't grab my attention without a wall of text, sorry, tldr.
The « Launch HN » posts, like this one, follow quite standard community guidelines that includes having a detailed description of how the product works to bring value to technical people from the HN community. Of course, for investors, we would have written things differently, but we are not looking to raise money at the moment. Hope that makes it more clear!
It was the several paragraphs of history and background I didn't get past, instead of just cutting right to the value prop and how it works.
Re: Launch HN: Escape (YC W23) – Discover and secure all your APIs
#37Earlier quoted context omitted.
Hello btown, you are indeed raising legitimate questions here. You are right in the sense that using automated security testing tools in production creates a risk. But there are workarounds: 1) Most of Escape's security scans happen on staging or pre-prod environments, where there is little risk of breaking something critical or finding real customer data. 2) We have designed a specific scan mode for production APIs,…
> It will not attempt the riskiest attack scenarios What does that mean exactly? Do you manually assess what is risky for a particular API, or is it up to the system to choose? If it's up to it, what happens if it thinks that's not risky to delete user data?
We created specific safeguards for production mode; for instance, Escape doesn't launch any DELETE requests in prod mode.
You can also manually configure an allowlist/blocklist of operations for specific use cases.
Re: Launch HN: Escape (YC W23) – Discover and secure all your APIs
#38How does your product compare to Akita? https://www.akitasoftware.com/
Sure, Escape and Akita are quite different:
1) Escape is primarily for Security Engineers, Akita is more for developers
2) Escape discovers API with external scans, Akita discovers API by observing live traffic
3) Escape is a proactive security tool that finds issues before production, Akita is a monitoring tool that detects errors in live traffic
Re: Launch HN: Escape (YC W23) – Discover and secure all your APIs
#39Could you clarify the meaning of the term "Developers covered" as mentioned on the billing page?
Sure, we count Developers who committed to the API repository in the last three months.
Hope that makes it more clear!
Re: Launch HN: Escape (YC W23) – Discover and secure all your APIs
#40Could you clarify the meaning of the term "Developers covered" as mentioned on the billing page?
Sure, we count Developers who committed to the API repository in the last three months. Hope that makes it more clear!
I'm lost. Does the "count" thing also go for REST security scans (that are integrated with Postman or manually import the API schemas), or is it just only if the inventories are integrated with GitHub?