To outsource or not to outsource: that is the question.
At least, that’s one question you may be asking yourself if you’re trying to decide how to optimize your business’s approach to application security testing. While outsourcing AppSec tests to a managed service provider can improve test results, save money, and make life easier for your own staff in many situations, it’s not the right choice for every business.
Plus, in some cases, it may make sense to outsource only some of your tests while keeping others in-house.
This article provides a guide to making both of these decisions – whether to outsource AppSec testing in the first place, and how much of it to outsource if you choose to go that route. It also explains how to go about setting up and implementing managed AppSec testing.
When considering whether to use managed AppSec testing services at all, there are two main factors to weigh.
The first is whether your current AppSec testing strategy is meeting your security goals. If undetected application-level vulnerabilities have led to major breaches, it’s likely that you need more extensive, more consistent, or more frequent AppSec testing than you are managing to perform in-house.
Second, assess how many resources your in-house AppSec testing operations consume. If the time that engineers are spending on tests undercuts their ability to perform other job responsibilities, it’s a sign that outsourced AppSec testing is a good idea.
Again, deciding to use a managed AppSec testing service doesn’t mean that you have to outsource all of your tests. You can choose to keep running some tests in-house.
To make a decision about which tests to outsource, consider:
- How well your engineers know each application: Your team may have more familiarity with some applications than others, and therefore be in a better position to test those applications than others. For instance, maybe your engineers are more skilled in working with certain programming languages and can write better security tests for apps written in those languages than for others. It would make sense in that case to outsource the apps that your developers don’t know as well.
- Software complexity: Some applications are inherently more complex than others and are therefore harder to test thoroughly – especially if your in-house engineers have limited security expertise. It may therefore make more sense to outsource testing for a complex, microservices-based application that depends heavily on third-party modules and libraries (which could introduce vulnerabilities into the codebase), as compared to a simple monolithic application that you develop entirely in-house and that has minimal dependencies.
- How much you can automate tests: Some security tests (like vulnerability detection inside source code) can be easily automated. Others may require a high level of manual intervention. The latter are likely to consume more time and resources and are therefore good candidates for outsourcing.
- Security and privacy considerations: In certain cases, outsourcing AppSec testing may require giving third parties access to sensitive source code or other private data. Although a trusted managed testing provider will be able to keep that data confidential, you may still decide that it’s best to run some tests in-house in order to avoid the exposure of sensitive information.
Bear in mind, too, that there’s no reason why you can’t bring some tests back in-house after you’ve outsourced them, or vice versa. Thus, it’s fine to experiment a bit as you adopt a managed testing service in order to figure out what you want to outsource and what to keep in-house.
Once you have an idea of which tests you want to outsource, you need to find a provider. Factors to weigh on this front include:
- Which types of application tests the service supports: Can it only validate source code, for example, or can it also run dynamic tests against binary applications?
- Which types of applications it supports: Can the testing service support applications written in any language and for any operating system? Or is it geared toward certain types of applications or environments?
- Security and confidentiality: Which guarantees does the testing service make regarding keeping sensitive information private? Make sure you understand which specific practices it uses to protect your source code and data.
- Speed: How quickly does the provider produce test results? Can it integrate with your development pipelines in order to validate code as fast as you develop it, or is there the potential for AppSec tests to slow down your release pipelines?
- Guidance: To what extent does the testing provider help you determine what you should be testing for? Do they expect you to specify which tests to run, or will they collaborate with you in developing tests and identifying blind spots in your current testing strategy?
That last bit is especially important. If you’re choosing to outsource AppSec testing, there’s a decent chance that it’s due in part to limited in-house AppSec expertise. Managed security testing providers who can help fill the expertise gap are worth much more than those who basically just run the tests you tell them to run.
Even once you have a managed AppSec testing program underway, you still have work to do. As we explain in a separate post, it’s critical to track and measure the impact of outsourced tests so that you can validate that they are creating the value you intended. You can also use this data to get buy-in for outsourced testing from business stakeholders.
You should track not just how much outsourced testing improves security outcomes, but also how it enhances engineer productivity (by allowing your team to focus on other work) and reduces costs.
Deciding whether to adopt outsourced security testing is hard enough. Planning an implementation strategy, then validating that strategy once it is underway, requires even more work. But it’s critical to approach these challenges systematically in order to ensure that you maximize the value that outsourced tests bring to your business.
Chris Tozzi has worked as a Linux systems administrator and freelance writer with more than ten years of experience covering the tech industry, especially open source, DevOps, cloud native and security. He also teaches courses on the history and culture of technology at a major university in upstate New York.