SAST in Secure SDLC: 3 Reasons to Integrate It in a DevSecOps Pipeline

Vulnerabilities produce enormous reputational and financial risks. As a result, many companies are fascinated by security and desire to build a secure development life cycle (SSDLC). So, today we're going to discuss SAST — one of the SSDLC components.

SAST (static application security testing) searches for security defects in application source code. SAST examines the code for potential vulnerabilities — possible SQL injections, XSS, SSRF, data encryption issues, etc. These vulnerabilities are included in OWASP Top 10, CWE Top 25, and other lists.

Before we discuss why to integrate SAST in a DevSecOps pipeline, let me draw your attention to several facts.

The Number of Vulnerabilities Is Growing. The Cost of Fixing Them Is Growing Too

Fact #1: The Number of Vulnerabilities Is Growing Every Year

Estimating the number of vulnerabilities found yearly is enough to look at the CVE (Common Vulnerabilities and Exposures) statistics. The graph below shows the number of vulnerabilities found from 2017 to 2021. The data is provided by National Vulnerability Database (NVD).

Here are 2 facts:

• the number of found vulnerabilities increases every year;
• the difference between the number of vulnerabilities in 2017 and 2021 is more than 30%.

By the way, at the time of writing the article in 2022, more than 5 thousand vulnerabilities have already been found.

Remember that vulnerabilities can exist for years before they become publicly known. Take at least the sensational Log4Shell (CVE-2021-44228) disclosed 8 years after its appearance. Attackers can exploit a hidden vulnerability until it is discovered — as a result, the business is losing money.

What must be done? Use complex approaches and tools that will allow you to detect as many security defects as possible.

Fact #2: Vulnerabilities Found Later Are More Expensive to Fix

Here's what IBM System Science Institute reports about the relative cost of fixing the vulnerability:

Vulnerabilities found after the release are 15 times more expensive than those discovered at the development stage. Moreover, they are 100 times more costly than vulnerabilities found at the design stage.

Different sources present this graph slightly differently. However, the overall statistics are the same: defects found later are more expensive to fix.

Absolute values depend heavily on how critical the vulnerability is, how complex it is to patch vulnerable components, etc. Vulnerabilities, as errors, can cost thousands, hundreds of thousands, or even millions of dollars. Remember the launch of Ariane 5? The failure losses vary from $360,000,000 to $500,000,000. Or the story of the Polygon Plasma Bridge vulnerability with almost $850,000,000 at risk.

What must be done? Use tools and approaches that help to detect security defects as early as possible. Let your team improve their skills.

3 Reasons to Integrate SAST in SSDLC

1. Shift-Left Testing

Shift-left is a practice intended to perform testing early in the software development life cycle. That is, testing on the project's timeline should shift to the left — closer to the beginning.

One of the advantages of static analysis is early defect detection. It's relevant to SAST as well. SAST is a DevSecOps pipeline that allows you to follow shift-left testing and detect security defects earlier to fix them cheaper and more accessible.

Let's consider an example. To estimate the losses, we use the previous graph that shows the relative cost of fixing defects. For a standard unit, we take $100.

So, your team is developing an application that works with XML files. The XML handler is designed as follows:

• the used XML parser processes external entities without restrictions;
• the parser receives the user data (taint data) to the input.

A system designed this way may be subject to an XXE attack. Suppose the developers find out about the problem and fix it simultaneously. However, the losses already amount to at least $100.

Imagine that a security defect was not detected and got into the release.

In a worst-case scenario, hackers find the vulnerability and exploit it. Naturally, thee exploitation brings about losses. However, neither you nor your clients are aware of this.

Sooner or later, you will find out about the vulnerability. The question is — what reputational damage and financial losses you and your clients have already suffered. Moreover, you need to close the vulnerability and update the client software. The graph suggests that the losses amounted to $10,000. This sounds optimistic.

Suppose a company uses a SAST solution that can detect this XXE. If SAST is regularly used in CI/CD, developers can find a security defect earlier. In this case, customers will not get a faulty product. And hackers will not exploit the security defect. As a result, possible losses are significantly reduced. The security flaw costs about $1,600.

However, you can manage the process better — use a SAST solution in CI/CD and locally — on developers' machines. This makes it possible to find the XXE during development in the IDE. Since the developer is in the task's context, fixing the problem will be easier and cheaper. The security flaw costs $650.

It turns out that SAST in a DevSecOps pipeline helped to cut costs by about 15 times: from $10,000 to $650. Shift-left testing in action.

2. Security Defects in External Code

Sometimes developers use ready-made solutions — not only libraries but also code fragments. For example, code fragments are copied from Stack Overflow or GitHub repositories. The question is — how secure is such code? Alas, there are no security guarantees.

The "How Reliable is the Crowdsourced Knowledge of Security Implementation?" research confirms this. The authors analyzed several questions on Stack Overflow and checked the proposed solutions for security. Here's what they found:

• 644 out of 1429 inspected answer posts (45%) contain insecure solutions;
• on average, answer posts containing insecure solutions are more popular and gain more comments and views;
• accepted answers do not necessarily include secure code.

Another research — "If you want, I can store the encrypted password" — discusses freelance developers. The paper suggests that freelancers are less likely to provide secure solutions if they are not explicitly asked about it. Like everyone else, they don't mind copying ready-made code, including code fragments from Stack Overflow.

By the way, there is an exciting story about copying code from Stack Overflow and the consequences. But, of course, we're talking about Razer Synapse and Docker for Windows.

These applications are developed by different companies and seem to be unrelated. However, if we run one of these applications, we can't run another. Why?

Developers of both applications used error codes from Stack Overflow.

There was a problem with getting a global mutex. Due to the error code, it turned out that both independent applications used a common mutex. 

OK, a developer can copy-paste insecure code from Stack Overflow to an application. How can SAST protect the app from vulnerabilities in this case? By analyzing the copied code. SAST solution can analyze it separately or after its integration into the application's codebase.

Pay attention that sometimes vulnerabilities appear only after integrating external code into the application. That's why you need to analyze the entire application's code, not only the copied one.

3. Improving the Security Skills of Developers

If you integrate SAST in your development process, you follow shift-left testing even more precisely. This is achieved by improving developers' skills in the security field.

Earlier, we discussed that SAST shifts the responsibility for the application security towards development. This happens because the developers handle the warnings of SAST solutions.

To fix a security flaw, a developer needs to investigate the problem. For example, is it possible to improve SSRF if you don't understand it? A path traversal? XEE?

The developer analyses a warning from a SAST solution and investigates the essence of the security defect to fix it. The tool documentation helps with this. Thus, the developer becomes more experienced in information security.

But there is one more important thing. The developer now knows weakness' essence. It means that they will be more attentive in such cases. As a result, the probability of having a similar security defect in the future is reduced.

Thus, the team will strive to prevent security defects even before writing the code as the expertise increases. This reduces the cost of software development.

It is worth noting that SAST solution developers often have blogs where they describe best practices of using their tools, writing secure code, etc. Such blogs can become an additional opportunity for a team to develop new skills.

Conclusion

Let's sum it up. SAST allows reducing financial and reputational risks. This is achieved by:

• Shift-left testing. Security defects are detected at an early stage when their cost is minimal;
• Analysis of third-party code. Code copied from Stack Overflow may be insecure. The same is with custom-written code. Therefore, it is helpful to check external code for potential vulnerabilities;
• Team training. To fix the problem found by a SAST tool, a developer needs to investigate it. As a result, the team improves its security skills. In addition, it helps to prevent security defects even before writing the code.

Despite these advantages, you need to remember one fact. SAST is not a panacea. It will not protect you from 100% vulnerabilities; it will not fix all issues. For example, you can't create SSDLC only with the help of SAST.

And yet SAST is another essential step-up that can help reduce reputational and financial risks. So if you are building SSDLC, SAST tools should be a mandatory part of the DevSecOps pipeline.