The Economics of ASOC

“Are we paying a fair price for this tool?” is the question every decision-maker asks themselves before making a significant purchase decision.

As one of the nascent categories in the application security space, one of the significant challenges ASOC category is likely to face is the value it creates.

While it is hard to quantify the benefits of a platform that claims to bring visibility into what was unseen before and speed up processes that involve multiple stakeholders, we have attempted to formulate the savings that an ASOC tool can create and came up with a savings calculator.

We have identified three main outcomes of using an ASOC tool and have tried to tie down each economic benefit to these buckets.

1. Faster Triage: Using the automation capabilities of ASOC tools, security teams can create playbooks for certain types of low-hanging vulnerabilities and either get them out of the way or immediately escalate them without manual reviews.

ASOC tools also help security teams gain centralized visibility into their vulnerabilities without having to toggle between different interfaces.

2. Faster Remediation: The biggest obstacles for quick remediation of vulnerabilities by software developers is the lack of knowledge about vulnerabilities and the lack of smooth collaboration with security teams.

ASOC tools can provide knowledge bases or training videos on how to remediate vulnerabilities and speed up the remediation process. To verify the fix, they can also run automated validation scans without requiring any involvement of the security team.

3. Higher number of triaged vulnerabilities: Having a security team large enough to triage all reported vulnerabilities is great. But we know that is not the case most of the time.

ASOC tools can act as a force multiplier for your security teams, allowing them to review a higher number of vulnerabilities.

Each extra vulnerability your security team can triage thanks to an ASOC tool is a reduced risk for you.

Reasoning Behind Our Calculation

As software is at the center of application security, we started with the average lines of code a software developer can write in one year.

Based on the number of developers in an organization, we tried to converge on the lines of code that these developers can write in a given year.

Using an assumption on the average number of security vulnerabilities in 1000 lines of code, we extrapolated the number of vulnerabilities that are likely to arise in the software in one year.

For the sake of simplicity, we left out the potential vulnerabilities in the backlog discovered previously in the existing source code.

We also ignored false negatives assuming that our security testing tools successfully caught all these vulnerabilities and reported 25% false positives.

The more security testing tools we have, the more likely it is to have overlapping vulnerabilities across different tools. That is why we included those possible duplicate vulnerabilities in our calculation.

Once we have all these vulnerabilities discovered by our security testing tools, typically, our security engineers should triage them before they are sent to development teams for remediation.

However, no security team is big enough to review all reported vulnerabilities. They need a filtering mechanism even before they start to triage vulnerabilities. Some just look at critical or high severity vulnerabilities, while others only care about OWASP Top-10 or SANS 25 etc.

From our experience in the field, we know that organizations with a higher maturity level can afford the luxury of spending more time triaging vulnerabilities, whereas smaller companies with resource constraints have less time to decide if the reported vulnerability is real or not.

At the same time, they are also able to triage a higher number of vulnerabilities compared to other organizations at the earlier stages.

To locate your maturity level, you can take a look at the Software Assurance Maturity Model by OWASP which is a framework to analyze and improve the software security posture.

Taking into account the centralization and automation capabilities of ASOC tools, faster triage translates to two things.

First, there is a time saving for security engineers which can easily be converted to USD taking into consideration the average daily rate of a security engineer.

Second, the time saved can be used to triage a higher number of vulnerabilities which reduces the risk that the organization is exposed to. This can also be quantified by taking into consideration the size of the organization for which the annual revenue is mostly a good proxy.

Since the regulatory fines are mostly based on a fraction of the annual revenue, this can be seen as the risk that the organization is facing as a result of the vulnerabilities that arise in the code.

Please bear in mind that the damage of a security breach can be in numerous ways like loss of customers or a deteriorated brand image which might be even more detrimental for the company.

For the sake of simplicity, we did not include these risks and merely focused on the risk exposure from a regulatory fine.

From a remediation perspective, ASOC tools bring visibility into the remediation process and security engineers can promptly take action on vulnerabilities that are past their SLAs or track their metrics to identify bottlenecks in the process.

This leads to a drop in the time a developer spends on remediating a vulnerability with proper guidance coming from the ASOC tool.

The time saved in the remediation process can also be monetized using the average daily rate of a software developer.

You can find our calculator here and if you have questions about the assumptions used in our calculation or would like to know more about the details, we’d love to chat with you to improve our model.