pierrebetouin
Joined 10 years ago
Joined 10 years ago
If we detect that a vulnerability is being triggered we will virtually patch it and send remediation details to developers. We wrote a blog post [1] that explains how we detect these vulnerabilities.
[1] - https://blog.sqreen.com/block-sql-injections-not-customers/
Re attack vectors: agreed that more code leads to more attack surface, but that's the same rationale with frameworks, other agents (APM, error/log monitoring, etc.) and often less transparent, when running on pre-packaged containers, or even on an appliance (code running on Firewalls / web app firewalls solution can usually not be audited). Our agents are not (yet) open source but are audited regularly by our users.
Sorry to hear about the bug you've hit when you tried Sqreen. Would love to know more directly (PM?) so we can debug it and provide a better experience there. The agents are using a v8 virtual machine to avoid problems of that type (we can’t mess up with the original app logic), so it acts as a sandbox there.
Today Sqreen is inbound-driven and the marketing/sales process is focused on the positive of how to make security better and more transparent, rather than attempting to stoke fear or play up the negative side.
We never had to build any dubious ROI calculation. Tech audience usually understands the need for security and we present a technical solution that is transparent and easy to use and deploy.
We've experimented a lot - especially during our batch at YCombinator last year. We quickly noticed that most of our former processes were broken and we had to change almost everything, in just a few months.