Hi HN! I'm Pierre, the co-founder of Sqreen (
https://www.sqreen.com/).
Sqreen is an application security platform made for both engineering and security teams. We use dynamic instrumentation libraries that monitor web applications internals to detect security anomalies and block triggered vulnerabilities at runtime. Pretty much what an Application Performance Management tool (like New Relic) is doing, but for security.
Before founding Sqreen, I led the Red Team (Offensive Security team) at Apple. I was brought on in 2006, so we're talking iMacs and iTunes at the time. The focus was initially on breaking DRM implementations (FairPlay). Over time, I had a team of 4-5 people, and had to cover most of Apple's portfolio. We needed to provide security assessments to hundreds of developers at Apple in ways that they could trust and find useful. We faced two major issues time and time again: scale (single digit team serving hundreds), and usefulness (how could we make security something that devs felt was actionable and relevant for them?). So why were these obstacles so hard to overcome?
First, security culture is broken. My team and I had to act in secrecy for years - like most security teams in companies. Our job was to break things (and we did a pretty good job there!), but we were mainly blockers instead of enablers. As is the norm, the way things were set up, our job was to say "no" - for the sake of product security—not to work collaboratively with developers on improving security together.
Second, most of the tools the industry is using today were invented in the 90's and haven't changed much since. Legacy security solutions rely on lists of known signatures of attacks that can't keep up and that generate a high number of false positives. They slow down releases and are nearly impossible to properly maintain for security teams.
The function of security within companies today is where Ops was 15 years ago, before the DevOps "revolution".
Security as a function has yet to make the leap that Ops has. For small and mid-sized teams, security is either not present, or is bottlenecked by a one or two person team. For large companies, their security teams are flooded by irrelevant security alerts. And there aren't enough security professionals to improve the situation by just increasing headcount.
We saw a need for a self-service solution that brings security and developers closer together, so that security can better scale and become more useful for developers. My co-founder JB and I started Sqreen to build that solution.
Sqreen's microagent is a lightweight library that can be added in just a few commands to any web application, API, or microservice. We support Ruby, Node, PHP, Go, Java and Python.
Our microagents use dynamic instrumentation [1] to automatically monitor sensitive app routines (Database calls, I/O processing, rendering of pages and more) and they use the execution context of the app to identify how the request is being processed and detect if it's triggering a vulnerability. The attack can be blocked at runtime (stopping the execution) and stack traces are provided on a dashboard. We embed a sandboxed VM inside the applications, so the CPU footprint is limited and we can't mess up with the app.
Sqreen is built as a platform and security modules like Runtime Application Self-Protection (RASP), in-app WAF, or account takeover can be turned on or off.
We protect over 600 companies in production today. We've blocked SQL injections just hours after being deployed, we've identified massive account takeover tentatives, we're helping engineering teams with no security resources kickstart their security efforts, and we're helping security teams scale their security efforts without slowing down developers.
We would love to hear your feedback about Sqreen, as well as answer any questions you might have!
[1] - https://blog.sqreen.com/building-a-dynamic-instrumentation-a...
The main concern I've heard from senior security experts that have advised us is about __your__ access. By embedding Sqreen to intercept all web server traffic at the gateway (e.g. WSGI in Python), your solution adds a worry about an attack vector -- if Sqreen itself is compromised, everything about our website is compromised. Or, any general server errors at Sqreen will bring down the entire web application, possibly without warning (web app won't be able to trigger 500s), with no way to remedy except removing Sqreen and re-deploying. That actually happened for us for 12+ hours during the one month we tried out Sqreen.
I think the problem you're addressing is definitely a very real and huge problem. Would love to hear your response to the above.