If you’re part of an application security team, you probably struggle to get through a satisfying amount of work each day. Let’s say you have two people from your team dedicated to security testing and providing guidance on how to fix some vulnerabilities. Your organization has more than 100 web applications and APIs, produced by a group of 200 developers. You’ve probably attempted to offload some work by handing developers some security testing tools and guidance – but the learning curve to get good coverage is long and frustrating. Basically, you have a scaling issue.

I know this because I’ve felt your pain! Before Probely, I managed an application security team at the Internet division of a large telecom operator, so I know the frustration that comes with the territory.

This blog post is written with application security teams in mind, but it may prove useful for anyone who works within AppSec.

The Challenge of Scaling in AppSec Teams

How do you handle security testing without it becoming a bottleneck in the software development lifecycle (SDLC) – if your organization promotes agile development methodologies and releases frequent new versions of the application?

Most security teams I know, in particular, applications security teams, have a ratio of security engineers/developers of 1:100. The truth is that in an agile organization, the traditional methods don’t work. You can do some risk assessment, even if informally, to help you prioritize things. For lower risk applications, you will only perform light testing; while for higher risk apps you will perform in-depth testing. But this risk assessment and set of actions in this context is definitely not the solution; it’s a workaround.

The problem is that most security tools were built with the security professional in mind, which results in a long learning curve for developers to properly use the tools. There is an even longer time investment required for you to guide developers through how to correctly interpret and surface the most important findings, so they can become adept at filtering or deprioritizing certain findings.

So, what’s the answer?

Development Teams and Autonomous Security Testing

Traditional security teams (and even some AppSec teams) are frequently siloed – outside and after the SDLC – and therefore not integrated into the SDLC. This causes two problems:

  1. A painful lack of involvement in security from the web application specification stage onward

  2. Consequently, more insecure applications

Yet, with a DevSecOps approach – where time and effort is invested in security early in the SDLC, less time would be spent rectifying it once development reaches the testing or production stages.

I know from past experience that a major part of the solution is to provide developers with an automated security testing tool with a developer-friendly UI that fosters independence or something they can rapidly integrate with their existing toolkit. This allows you to surface the more complicated security issues automatically, along with more common and expected web application vulnerabilities – and, it dispenses with the need to involve a security expert on every issue. Experienced web application and API security experts can focus their attention on two important aspects instead: mentoring developers, and spending dedicated time tackling more challenging penetration testing.

Security Tools Designed for Developers First

In order to properly build a DevSecOps programme and 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. Tools designed with developers in mind first offer several crucial advantages over others:

AppSec Teams Can Still Have an Overview of the Entire Security Posture

Offloading automatic security testing to developers does not mean you lose all control over your security testing. We provide you with the tools to gain an overview of all your assets, a trend of the overall risk, and signposts to which projects need urgent attention (the ones with unfixed, high-risk vulnerabilities). You can also start scans and check their results, assign vulnerabilities to developers, and re-test them, for example.

"Probely Enterprise screenshot"

AppSec Teams’s Time is Released for Focused Work

If you are able to offload automated security testing to developers, you will have more time for:

What to Do Next

Check out Probely by signing up for our 14-day free trial. Or, if you have specific needs and have a large number of web applications and APIs, you can request a demo of Probely’s Enterprise solution or contact the sales team. You can also learn more about our new features on the blog or check all the features.