Vulnerabilities produce enormous reputational and financial risks. That's why 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) is used to search for security defects in application source code. SAST examines the code for many 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 a couple of 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
To estimate the number of vulnerabilities found year by year, it 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 in 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.
Keep in mind that vulnerabilities can exist for years before they become publicly known. Take at least the sensational Log4Shell (CVE-2021-44228), that was 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 expensive than vulnerabilities discovered at the design stage.
Different sources present this graph slightly different. However, the overall statistics are the same: defects found later are more expensive to fix.
Absolute values depend heavily on many factors: 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 software development life cycle. That is, testing on the timeline of the project 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. This means that SAST in a DevSecOps pipeline allows you to follow shift-left testing and detect security defects earlier to fix them cheaper and easier.
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 at the same stage. 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. The 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. Actually, 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 even better — use a SAST solution not only in CI/CD, but also 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, it will be easier, and therefore, cheaper to fix the problem. 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 copied from Stack Overflow or from 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 a number of 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 contain 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. Just like everyone else does, they don't mind copying ready-made code, including code fragments from Stack Overflow.
By the way, there is an interesting story about copying code from Stack Overflow and the consequences. 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 code 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. You can read more about this in the thread on Twitter.
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 code base.
Pay attention, that sometimes vulnerabilities appear only after the integration of external code into the application. That's why you need to perform analysis of the entire application's code, and not only the copied one.
3. Improving security skills of developers
In fact, 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. Is it possible to fix SSRF if you don't understand what it is? 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, as the expertise increases, the team will strive to prevent security defects even before writing the code. 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 and so on. Such blogs can become an additional opportunity for a team to develop new skills.
Conclusion
Let's sum it up. SAST allows to reduce 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 useful 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. 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. 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. If you are building SSDLC, SAST tools should be a mandatory part of the DevSecOps pipeline.
And as usual, I invite you to subscribe to my Twitter, if you don't want to miss new publications.
Top comments (0)