Scaling Application Security: The issues that Appsec teams face

This post concerns application security teams, so it’s written assuming you are part of one. However, I believe it could help you understand application security a bit more even if you are not.

If you are part of an application security team, you probably struggle with the amount of work on your shoulders every day. Let’s say you have a small team of 5 people to test all web applications produced by a group of 200 developers, and you still need to provide guidance on how to fix some vulnerabilities. You try to offload some work by handing developers with security testing tools, but the learning curve is long - causing frustration. Basically, you have a scaling issue!

I know this because I’ve felt your pain! Before starting my own security start-up (Probely), I was running an application security team at the Internet division of a large telecom operator, so I know the frustration that comes with this.

Most security teams I know, in particular, applications security teams, have a ratio of security engineers/developers of at least 1:40. So, how do you handle security testing without being a bottleneck, if your organization promotes agile development methodologies and releases new versions of the applications frequently?

The truth is that in an agile organization, the traditional methods won’t work. You can do some risk assessment, even if informally, to help you prioritize things. For lower-risk applications, you will only perform lighter testing, while for higher risk apps you will perform in-depth testing. But risk assessment in this context is definitely not the solution, it’s a workaround.

I know from past experience that the solution is a set of different things, but a major step forward is to provide developers with tools that enable them to be more independent when it comes to security testing. Low hanging fruits and other more complicated vulnerabilities should be found automatically, without the need to involve a security expert.

The problem is that most security tools were built having the security professional in mind, which results in a long learning curve for a developer to properly use the tool. And there is an even longer learning curve for the correct interpretation of the findings, i.e. filtering out irrelevant stuff.

In order to properly shift (some) security testing to developers, we need to have security tools that were designed from the beginning to be used by developers. This is why we created Probely in the first place.

We built the tool we wished we had back then.

Having an API that covers 100% of the product’s features and including detailed instructions on how to fix the vulnerabilities are just two simple examples of features that a security tool designed for developers, like Probely, must have.

But we also have your back too. Offloading automatic security testing to developers does not mean losing control over security testing. We provide a view of all your assets, a trend of the overall risk and which projects need attention (the ones with unfixed high-risk vulnerabilities). You can also start scans and check their results, assign vulnerabilities to developers, re-test them, etc.

If you are able to offload automated security testing to developers, you will have more time to talk to developers, to perform more thorough assessments on the most critical projects, to participate in the design phase of new projects and to truly introduce security into the whole software development life-cycle (SDLC).

You can check out Probely by signing up here, or you can learn more about some of our new features through our blog!