DevSecOps Pipeline: Scaling Web Application and API Security

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 are 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

In order to properly build a DevSecOps program 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:

• An API that covers 100% of the product’s features – enabling rapid integration with your existing SDLC and CI/CD workflows
• Integration with the tools that developers use to manage their work on a daily basis, such as a 2-way sync with issue trackers and integration with CI/CD tools
• Detailed instructions on how to fix the vulnerabilities – meaning you can build security into the application at the design stage and continuously reduce the number of vulnerabilities build by build, as you move toward release dates, and following later updates
• Reduced false positives, so that you or your developers don’t waste time validating vulnerabilities
• Developers are constantly learning more and more about how to design and develop more secure applications and APIs – so security becomes an integrated component, not an afterthought 

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.

AppSec Teams’ Time is Released for Focused Work

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

• Investing in the overall improvement in security across your organization
• Performing more thorough assessments on the most critical projects
• Participating in the design phase of new projects
• Introducing security principles into the whole software development life-cycle (SDLC)

What to Do Next

Check out Probely by signing up for our 14-day free trial here. 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 here.