Your number one priority in building a new application? Getting it into the hands of potential customers as fast as possible. Understood, but what are the risks of this practice? Your Application Security (AppSec) is an afterthought, and the risk exposure of your company is unknown. Now, I am not here to judge this approach, but rather applaud you to want to address the issue. This article provides you with a method to determine how much time (=$$) is needed to address potential vulnerabilities in your application.

To get a sense of the security posture of the application, one of the first things you could do is a Static Application Security Test (SAST) of the source code. But how do you plan for this? How much time should you set aside for the remediation of the issues found by the SAST tool?

For clarity: an issue does not necessarily mean it is a vulnerability. To get a handle on the number of issues vs vulnerabilities, I would like to refer to a research paper from the Dakota State University. The paper discusses the number of vulnerabilities per 1000 lines of code (KLOC) depending on the Capability Maturity Model (CMM) level of a software development organization. For the sake of this article, let’s assume the CMM level of your software development organization is at its highest level (5). According to the aforementioned paper, this results in 1 vulnerability per KLOC. I will use these results later in my article.

Addressing SAST results

Let’s have a look at what’s involved in addressing the SAST results.

When an issue is reported by the SAST tool, an auditor executes the following activities:

1. Understand the vulnerability being reported. E.g. SQLi, XSS, SSRF.
2. Understand the software construct related to the issue. For example, what did the developer try to do?
3. Understand why the software construct is being reported as a vulnerability.
4. Understand if there are compensating controls in place and if they are sufficient.
5. If the issue is not exploitable: mark it as such, provide the rationale, and suppress the issue.
6. If the issue is exploitable: mark it as a vulnerability and create a ticket to address the vulnerability.

When the issue is a vulnerability, the developer, to whom the ticket was assigned, has to execute the following activities:

1. Open the ticket.
2. Check out the code.
3. Understand the vulnerability being reported. E.g. SQLi, XSS, SSRF.
4. Understand why the software construct is being reported as a vulnerability.
5. Fix the vulnerability.
6. Create a test case to validate the fix.
7. Run a local SAST scan to validate the fix.
8. Put in a pull request.

As you can see addressing the results of a SAST scan requires time, general AppSec knowledge, and knowledge of the application itself. Let’s narrow this down.

The SAST results are reported in four different categories Critical, High, Medium, and Low. Based on my extensive experience working with SAST tools:

According to the CVE Details, of all vulnerabilities, about 10% are Critical (a score of 9-10) According to the CVE Details, of all vulnerabilities, about 20% are High (a score of 7-8.9) Based on my experience, it takes at least four (4) hours to address (auditor + developer) a Critical vulnerability and at least two (2) hours to address a High vulnerability.

Critical and High vulnerabilities are the easiest to discover and exploit, hence per the safe computing initiative from MIT, these should be addressed first.

Now assume one FTE effectively works six hours per day.

Based on these numbers, we can use the following formula to calculate the number of weeks it takes for one FTE to address the initial scan results of your SAST scan:

# of weeks to remediate = # of weeks to remediate Critical + # of weeks to remediate High

# of weeks to remediate Critical = Total LOC / 1000 * 10% * 4 hours to address / 6 hours per day / 5 days per week

# of weeks to remediate High = Total LOC / 1000 * 20% * 2 hours to address / 6 hours per day / 5 days per week

Let us look at an example where the codebase of the application is 1.5 MLOC; this is not counting comments or blank lines.

# of weeks to remediate Critical = 1,500,000 / 1000 * 0.1 * 4 / 6 / 5 => 20 # of weeks to remediate High = 1,500,000 / 1000 * 0.2 * 2 / 6 / 5 => 20

# of weeks to remediate = 20 + 20 => 40

Notes:

• It is assumed the auditor has at least two years of experience with AppSec.
• It is assumed the software engineer has at least two years of experience with secure software development.
• When scanning with SAST for the first time, start small. For example, only look at A1 of the OWASP Top Ten. Once all the Critical and High issues are addressed, add A2 and so forth.
• To reduce the impact of the workload for the software engineer due to fixing software security issues, it should seamlessly fit into their day-to-day activity. I.e. the workflow for fixing a functionality bug should be the same as fixing a software security issue.
• The times provided to remediate a Critical or High vulnerability do not include all the surrounding activities as part of a Vulnerability Management Program. Taking these into account could easily double those times.
• According to the NIST report - The Economic Impacts of Inadequate Infrastructure for Software Testing, the costs of fixing issues later in the SDLC grow exponentially. Therefore, needless to say, you should look for (running SAST) and fix issues early and often.

Are you considering an AppSec Program, including running an initial SAST (baseline) scan, with remediation? Let’s chat about how working with me can reduce time, money, and ultimately your risk exposure. See my contact details below.

Percy Rotteveel - Cell: (650) 421-3631 - eMail percy@rotteveel.ca

Article: https://www.linkedin.com/pulse/price-sast-afterthought-percy-rotteveel