Cybersecurity for Your C and C++ Critical Software
Embedded software is at the heart of many applications in our daily lives, like automobiles, phones, and medical devices. We expect these systems to work reliably under all possible conditions to support and assist us. However, their reliability has become a significant concern with the growing number of cyberattacks on embedded systems. To keep users and data safe and secure, designers must identify potential vulnerabilities early and build resilience into these systems.
Now explore how to leverage static code analysis based on formal methods to achieve superior quality for your C and C++ code, how to obtain hard evidence of cybersecurity properties, and how to reduce your fuzz testing efforts.
Learn how to:
Avoid vulnerable patterns (CWE, CERT) and improve their secure coding skills
Obtain a formal proof of robustness – no bugs and vulnerabilities missed
Find the right amount of defensive coding for given assumptions and trust the context
Set, track, and enforce software quality goals
Automate and optimize your verification process
Published: 18 Jul 2022
Welcome, everyone, to the webinar on "Cybersecurity for your C and C++ Critical Software." My name is Martin. I am an application engineer here at MathWorks. My background is, I'm an embedded engineer for more than 15 years, a lot of experience in formal verification. And I'm also a cybersecurity researcher, which makes this for me a very important topic, which is close to my heart. And I have with me Skanda today.
Hello, everyone. I'm Skanda Ramamurthy. I'm also an application engineer for Polyspace in the EMEA region. I sit also in the morning office in Munich. So I have experience of about four to five years in C and C++ critical software development for automotive industries. I welcome you all to this session, where we address cybersecurity for critical software.
All right. Thanks, Skanda. And before we get going, once more, the reminder. If you do have any questions during the course of this webinar, just go ahead and find a chat or a Q&A, whichever you find, and leave your question there. We will have time at the end to answer the questions. If we have something in between which we see, we might also react immediately. So with that, let's get going and let's dive right into the topic-- cybersecurity.
My quick motivation here-- and I don't think we really need to spend a lot of time, but just to once to talk about it. Do we need cybersecurity? And I just assume you have watched the news in the past year. So you will have seen the Log4j incident. You will have heard from the Colonial Pipeline hack, or also recently the attacks on German wind energy providers. And these are just some examples of many, many we could pick from the past years.
So I think we don't need to waste any time to agree that we need cybersecurity. But I think we all need to have one number in mind, and this is the number of at the bottom of the slide. There are estimates that by next year, 2023, the damage due to cybersecurity on embedded systems is going to be $50 billion. And that's just embedded systems. So there's a lot of potential of damage if we don't design our systems in the right way. And today, we want to show you how you can improve the security levels of your software.
I want to start with this. So here on screen, you see a visual depiction of attack vectors of embedded systems. Right here on the left-hand side, you see the preconditions. So the type of access you have to the system-- so for example, you might have an internet-facing system. And then you see paths going through the attack methods, the vulnerability, the target, and eventually the effect a hack could have on such a system.
Let's pick one of the paths here. For example, let's say we have an internet-facing system. One popular attack method here is control hijacking, which leverages a programming error. This is the vulnerability. And then the target actually is the operating system or the firmware. And it could result in a denial of service-- so maybe a crashing software or crashing system. So this is one of many examples. And each of the lines going through this graphics here is actually one attack path, and the darker the lines, the more likely the path is.
And what I have chosen here, it actually crosses one interesting point, which is programming errors. And if you look at the graphics here, you see that it's actually a hub for cybersecurity. Many, many different attack vectors go through the vulnerability constituted by programming errors. And that shall be our topic for today. How can we actually minimize the programming errors? How can we detect vulnerabilities in your software? And even more so, how can we do that in an efficient way?
So what do I mean by efficiency? Let's imagine a triangle here. We actually have three different goals if we talk about secure software. Goal number one is quality. So that means really make it robust to attacks. Goal number two is repeatability, which means I need to be able to also do that on my next project. And goal number 3 is speed. So I need to be able to come up with a secure system quickly, and that is especially-- if a system is under attack, and it might happen that you have missed a vulnerability, you have to create a patch, and that has to happen quickly.
So these are three very important pillars of cybersecurity. Let me quickly give you examples what happens if you don't implement all three of them.
So let's say you have a good quality, and you have a very nice process, so you're able to repeat this engineering at the next project you have. Then you're just lacking speed. So that could-- for example, maybe you're building a satellite. You have higher security, high quality, and everything is traced and documented, but it takes a long time, which is pretty bad in case your satellite gets attacked, because you need to provide the hotfix.
Another example. Let's say you have a really agile culture, and you really know what you're doing, so it's a repeatable process. But you're not sure about whether you have seen all the vulnerabilities in your software. Here, a very trivial example, let's say you have a hardcoded password. It's quick, you can repeat it, but it's unreliable. So that is lacking quality.
Example number three. So let's say you have quality, you are quick, but you actually haven't really documented stuff. That sort of is like snake oil, if you know what I mean. So that is something you have built, but you can't really explain and document how. So that will be an issue not only for an assessment-- from, let's say, tweleve form or one other authority. But also, it makes it very, very difficult to update your system if you have an attack. Yes, you're quick, and yes, you have the quality, but you don't know what you did in the past. There's little documentation and traceability.
So for that reason, we want all three of them. We need quality, we need speed, and we need reliability if we talk about secure software. And we want to show you how today-- specifically, if we talk about speed, we will show how you can actually reduce the manual work steps, how you can minimize the number of design iterations to get to a good quality, and, of course, how all of this can become incremental.
Talking about quality, we will show you how you actually can track and quantify quality, but also how you can actually be sure that you have not missed vulnerabilities-- really be sure. And as a third point, of course, how we can educate developers to come up with better quality over time?
And for the third pillar, for repeatability, we will show you how you can actually implement consistent security scans, how you can re-use the workflow also in new products, and how you can build some knowledge and skills also into the organization, not just for the individual developer.
So that is what we want to do today. And here's the outline. I'm going to start and talk about static application security testing, which is the focus today. But then we will also show you how you can apply this technology from the beginning to get a good code quality. Then we will show you how you can use it to actually not miss vulnerabilities. And then in the end, we will come to a complete workflow, how we can automate, how we can collaborate in a team, and how everything comes together.
Right. So let's start with number one, static application security testing. And don't worry. I'm going to explain you what it is. But I want to start with an example right away.
So here on screen, there's a piece of code. And I admit, it's a really bad piece of code. I hope you wouldn't write something like that. But let's do a little exercise. Look at the code. Think for yourself, where could be a vulnerability? Can you find it? I'm going to give you a little hint. Maybe look at this position here in the source code. There's a division. And maybe you now know what I'm going for. So let's say this is a division, and the divisor becomes 0. Then what happens? Division by 0, and the problem crashes. This is the simple example of a security issue, because this is, in essence, a vulnerability. It's a denial of service.
So looking at this code, there are many possibilities that could go wrong. For example, the loop may not terminate. That's also a denial of service issue.
So how can we procede here? And actually, now let's put the solution on screen. Where's the bug? Actually, there is none. As bad the code looks like, this is perfectly fine. There are no defects in this code. And I can say that with very high confidence. I even could tell you this is a guarantee. 100% guaranteed. I've considered everything.
So now let's talk about how that works. And this is, of course, now the name of the section we are talking about-- a SAST tool, a Static Application Security Testing tool. So let's see how the tool actually can provide such feedback.
First of all, what is it? So if we talk about SAST, this is a white-box approach to finding vulnerabilities, which means you have to provide your source code to the tool. It will actually read the source code and analyze it, but it will not execute it. It's really an analysis, as in using math, using a model of the processor, of the counterflow, and everything. And then out of this analysis there comes a list of bugs in your software. Or, if you have perfect software, then there is an empty list. But usually there are some open attack surfaces. Good thing about SAST-- it's really rigorous, and it's fully automatable. And that is what we'll be showing you for the remainder of the session.
The tool we're talking about is Polyspace. This is a static code analysis tool which has the appropriate checks for security, and therefore it's a SAST tool.
Maybe a few words on our background. Polyspace exists since about 1999. We are very closely related to the Ariane overflow accident. So if you do not know it, Ariane maiden flight, it suddenly exploded, and nobody knew why. And that was the growth of Polyspace, because Polyspace has these capabilities to analyze source code. It was back then used to actually spot the defect. And so this is where we're coming from. We have this long pedigree of analyzing software and to make sure there are no defects, or to spot defects.
Now the next thing is, that looks pretty good. But what can we do with it? So what are the capabilities of SAST? And here, I we be talking about an advanced type of SAST. Specifically, what we want to do for security, we have the CIA triad, what's at the top right of the screen. We want to show confidentiality, integrity, and availability. And if you have the right tool, you can do that.
And broadly, there are two use cases for a SAST tool. Use case one is, we are just talking about coding standards, best practices-- for example, CERT or CWE. There are some tools on the market which do that.
But this is only one half of the story. We certainly need to cover this, but I want to put also focus on the other half. It's a robustness analysis, which is very important for security. And here, the idea is for such a tool to consider each and every possible input, to consider the specific target processor, everything that could happen, and then tell you, is it possible that something that happens or not? Is there a vulnerability or not?
And this sort of tool, if it's an advanced SAST tool, it can even give you a proof-- and that is what I had on the screen before-- can give you a 100% proof that there are no defects in the program, if you have not made any. And if you have a vulnerability, it will of course point to it and tell you, you should fix it. There is a way to exploit it. So that's what we're talking about-- advanced SAST tools. We will talk about both of these sides-- coding standards and early checking, but also on the left-hand side, the robustness analysis and the proof capabilities.
And all of that, as I said initially, we will tie it to the triangle to show you how you can use it to get a better quality, to be quicker, and to make a repeatable process.
And of course, now the question is, how? And that's what Skanda will now start. We have just talked about what SAST is, and now we dive right into the next section. How can we use SAST and get our software right from the beginning, as soon as we write code?
Thank you, Martin. So we now have a good overview on how SAST analysis works in general. So we understand that SAST analysis could be a powerful way to address software vulnerabilities in the secure workflow. But our next big question is, when and where can we use SAST analysis to ensure the security in the DevSecOps workflow?
So what we have in the history of software development and tracking of security only at the end of software development lifecycle, perhaps by a dedicated security team. But this approach is no more valid, and it's outdated, because the software is getting increasingly complex and there are more and more security threats. So that's the reason why we also have a DevSecOps process imposing a lot to integrate security process in all the phases of development lifecycle. So that's what we are actually talking in this section-- getting it right from the beginning.
So developers and test authors are the first-hand contributors for the software development. And if they could get the feedback while they are developing about the software vulnerabilities, and if they could fix it right then, it would be cost effective and also speed up the process of software deliveries.
So let us try to take a look at the traditional workflow, where the developer develops the software and the source code is then submitted to the code repository. And then build automation servers will trigger analysis on the submitted code, and based on the results, if there are any security issues, it will be assigned back to the developer.
There are a lot of disadvantages with this process. So one thing is, it takes longer time for getting the feedback to the developer, and there is a trade between speed and consistency. So for one to have highly secure software, consistency is the key. And here, being more consistent is just delaying the process of software submission.
So what advantage we can have with early checks is that developers could use a SAST analysis plugin on the IDE and develop the software, and also run SAST analysis locally-- as in when they are developing-- to get the analysis results, which serves as an immediate feedback with a review and possibility to fix them before even submitting the code. So then the code that is submitted now is cleaner, more robust, and secure. And the test results are most probably cleaner than before, which could be used to get the compliance report very early.
So let's try to take a look at how Polyspace as you code plugin works on Eclipse IDE. So here, I have a demo project on the Project Explorer. You can see here's this project with all the source files and header files. So let us try to just focus on this one line here, line number 14, which is using secure_print function from the library.
So let us see what Polyspace has to say about it. So here on the Configuration section, developers can actually configure what defects or coding rules needs to be checked on the source file that is being developed. So here are some defects and coding rules, like MISRA and CERT C. So on the Security section, we can enable low, medium, and higher priority security defects here. And also, these configurations could be stored in the XML format.
So then it is as simple as just right-clicking and running the Polyspace as you code plugin, which runs the SAST analysis locally on the IDE. Here we see the status and also a list of security defects for this source file. So let us just select the defect for line number 14, which gives a brief description here, which says, "use of dangerous standard function." To know more about it, we can go to the contextual help, which describes in detail with some examples for the developers to educate themselves about the function that they are using.
So here, the risk of this specific function is that it can cause buffer overflows. So on the right side of this column is the alternative function suggestions from Polyspace documentation. So here, snprintf is also providing the same function, but it's more secure.
So let us just try to switch the older version of this function with the suggestion and try to run the Polyspace plugin again. So as expected, this line is now free from security defects. So this is how the developer can navigate through all the list and try to resolve it one after the other, even before submitting it into the code repository.
So what we have seen so far is how developers could use immediate feedback to review and fix the security defect. But also, the plugin will enforce the developers to adhere to secure design principles.
Here I have two examples. On the left is the zero trust approach, which is a security architecture which believes in having untrusted state for all sorts of communication within the software. Policies here could be configured to support this principle. And on this example here, all the file accesses are blacklisted from policies, and it throws the red flag for any part of the code that is trying to access this file. So this needs to be reviewed manually and approved manually only after making sure this specific access is secure enough.
And on the right side is input/output sanitizing principle, which lets the developer to perform taint analysis for the input and output of the functions to make sure it is well secured. On this example, the input document num could be having a very big value or a negative value, which is used for dereferencing here. This could crash the sensitive memory contents. And these are the programming errors which Martin was speaking about before which could be exploited by hackers.
And also what I have here are two infamous examples which, unfortunately, are the victims of security vulnerabilities. On the left side is the Jeep hack, where two friendly hackers managed to get into the CAN network of the car and manage to almost control everything on every feature of the car. So all of these, because they were just using poorly-coded random generators. And on the right side, what we have is Heartbleed issue from the OpenSSL library. So this was caused because they just chose wrong variable for length during memory copy. So in essence, these two issues could have been found with Polyspace as you code SAST analysis plugin on the IDE while the developers were developing it. But unfortunately, they got slipped into the production code.
And just to summarize, it is always difficult to find all the security vulnerabilities in the software. And even after finding them, it is not so easy to debug and fix them. So that's why DevSecOps process strongly recommends getting everything right from the beginning, before any dependencies are added into that.
Well, so now we know how we could use SAST analysis on the plugin to have everything fixed very early in the development lifecycle. So what we have covered so far is how we can minimize the design iterations, where developers try to run the analysis locally and then it also provides some contextual help which will educate the developers and develop a good habit of generating more cleaner and secure code. Also, it removes the disadvantage we had with the trade-off between speed and consistency. Developers could consistently use this plugin-- as in when they develop-- so that most of the issues are resolved there.
But that being said, I'll pass it on to Martin again to throw some more light on how to use SAST analysis in the workflow.
What Skanda has shown is the early feedback. And that is related to all of the coding guidelines we have seen through CWE patterns, and even to some numerical issues, crypto issues, and so on. But one thing we're still missing-- we really want to be sure that we don't have vulnerabilities. As we know, good quality code is not necessarily perfect. And now comes the second step we want to actually prove that it's perfect.
And I want to come back to the example we had initially here. I've given you this piece of code, and I have actually claimed that I'm 100% sure that this piece of code is free from any vulnerability. How could I be so sure? And I want to spend a few minutes explaining how Polyspace is actually doing that-- how it can provide this sort of certainty.
Right. So let's start with an example which will highlight why a simple testing approach-- or, let's say, a simple SAST tool is actually not enough. So here you see a figure which shows the program in a maybe uncommon way. But just imagine the x-axis here is time, and the y-axis here, this is the state space of the program. So these are all the different locations and variable values which you could have. And let's pick one of these lines-- maybe the green one here. This is one specific way to run the program. So let's say one input, and then the program goes through time and space like this.
And now you see we also have a forbidden zone on top, bottom, and some things in the middle. And for example, the forbidden zone could be, we have a buffer out of bounds write access, which would be memory corruption, which could be remote code execution, all sorts of scary things. So we would want to know, is it possible that any of my trajectories, any execution that I do, can it reach a forbidden zone?
So one way to do that, I can just throw a lot of test cases. So I could do coverage testing. I could do fuzz testing with coverage guidance. And I will come to fuzz testing later. But all of these activities, they have one problem. You cannot really be sure that you have written the test case or generated test case which triggers a run that goes into the forbidden zone. So you can never really be sure.
If your answer is, I'm just running all of the test cases, then this is going to be very difficult, because we have exponentially many execution runs here. So that means you usually could test for hundreds, thousands of years in a normal size software-- unless you have a very specific software which has no flow control depending on the input variables, but usually never happens. So for that reason, testing is not a good idea. It just takes too long.
And this is perhaps best said by Edsger Dijkstra, one of the famous computer science pioneers, in one of his lectures. He has actually shown that. And famous quote here. "Program testing can be used to show the presence of bugs, but never to show the absence." You can test and hit a bug and see it, but you cannot show that you have tested enough. And I will show even why coverage is not enough later on.
So now, this is the bad situation. And now let's talk how a SAST tool can be better. Let's take the same state space here and apply a little bit of simplification. And I show you a very simple way to do that. Keep in mind, Polyspace is doing much more complicated ways than this.
So let's say we are not following the individual trajectories anymore, but we are applying an abstraction. So let's say all we're interested now are the ranges of the variables in the program-- not exactly in which one becomes which number or which value, but just the range of values. And so in the figure, it could be like this. It's like a hull, something I put on top of all of the trajectories. And all of the trajectories are contained in that abstraction.
And let's look at a specific example here. Let's say this is my code. And now everything I want to know about this code, let me express it in ranges. Let's say the input is a range between 1 and 11. I can deduce a lot of stuff now. So I can deduce, for example, that the loop runs between 1 and 2 times. Another range, I can deduce that the result of the modulo operation there is always between 0 and 1. I can deduce even what the output parameters is.
And if I do that in the right way, if I have the abstraction to include all the trajectories. Then I have a safe abstraction, a sound one. That's the word "sound" there in the title. And that means I have exactly the guarantee I wanted. I can be sure that if this abstraction doesn't find a vulnerability in my program, there is no vulnerability, no matter what I do. And that is the same as 100% test coverage-- even better, as I will show later on.
Another good thing-- this is now no longer exponential complexity. It's polynomial, which means, yes, this is feasible. It doesn't take hundreds of thousands of years. And as I just said, it has no false negatives if you do it in the right way. So that means you can even prove the absence of defects. And that is, if you don't touch the forbidden zones with the abstraction, it's fine. By mathematical proof, no defects, no vulnerabilities.
Now, let me give you an example how it looks like if there's a vulnerability. Again, let's look at this picture, and let's assume there is an orange triangle up here. So there is a way that our abstraction touches the forbidden zone. So for example, there is a way to trigger a test case which actually, for example, runs into a buffer overflow. If you give a program to Polyspace, and it figures out there is some overlap, it will warn you.
Here's an example. So one of these orange parts here is a pointer which is illegally dereferenced. You get a full explanation here, and it even tells you exactly how big the buffer is and how much off the pointer is. There is a nice event phrase which tells you exactly how you got there. And if you click through there, you will actually find, this is the location in the code, and this is where you could touch the forbidden zone.
So, taking this all together, Polyspace can either prove the absence of vulnerabilities, because it uses sound math, or it can show you that there is a vulnerability and explain you how with a nice backtrace. So this is really what the sound SAST brings to you.
Now let me briefly dive into another topic, because I know that some of you should be looking at fuzz testing. So for those of you who don't know it, allow me to quickly introduce fuzz testing. So if you're talking about fuzz testing, we will actually take the program and we'll just send a lot of inputs to the program until it actually crashes.
So the idea is that you find vulnerabilities which are remaining-- like, again, the buffer overflow. We just try to find the input which does that. How do we select the inputs? Well, it could be random. It could be brute force. It could be even some advanced stuff like coverage-guided algorithms. And there are very nice fuzzers-- for example, fuzzing law. These kind of tools are clever. So they will try to generate test cases to maximize the coverage, to maximize the reaching the corners of the state space. But in essence, it's testing. So we have the problem of exponential complexity, which means you can never test enough.
When do you use fuzz testing? Well, of course, it's in the standards. If you look at the ISO 444 or the IEC standard, they all mention fuzz testing. And it's, in essence, a complement to requirements-based testing. I just think of requirements-based testing as testing what you expect to work in the design specification, and fuzzing does the opposite. It tries to find corner cases, stuff that has never been specified. And that is, in essence, what fuzzing tries to do-- try to crash your program with a lot of test cases.
How does it now relate to a SAST tool-- specifically, to a sound SAST tool, as I've just shown you? Well, let's start with fuzzing again. Here, left-hand side, fuzzer. And let's just imagine how a fuzzer finds defects over time. And if you get the chance to play with a fuzzer, just do it. You will see exactly this. There's, again, the time axis. And over time, the fuzzer will report more and more bugs. But these are not all of the bugs in the program, again, because we simply cannot cover everything. So there will be a difference between the actual number of bugs or vulnerabilities and what the fuzzer can find. So this is the coverage gap. If you test for an infinitely long amount of time in a clever way, you might be able to narrow this thing down to zero. But that's just theory, and in practice, it's just not possible.
So for that reason, you will only have a partial coverage. And usually, this is partial branch coverage even. So this is not even full-length CDC or value coverage. And on top of that, you need to write the test cases and select a test corpus-- so at least the initial few inputs for the fuzzer to play with.
So in essence, this means you might miss some bugs. And here you see an example. The green parts here have been exercised by the fuzzer. So you see-- this is a counter, actually. About 6,000 times I have reached all of these locations, but I didn't once to manage to go into the if condition. All of this is not covered, which means if there is a vulnerability in here, I haven't found it yet.
On the other side, there's SAST. And this is now really doing the opposite approach. If you start it, it is assuming that everything is broken. It comes from the safe side and just is very pessimistic, and says, let's assume every operation is bad, until I have proof that the operation is actually good and nothing bad happens. And therefore, over time, the number of reported defects in a SAST tool will drop. And if it becomes stationary, it is the end of analysis normally.
But also, since it can prove more and more to be OK, there's also a number of no bugs being rising over time, which means this is the locations where it knows nothing bad will ever happen. And here, interestingly, if you again look at the number of actual bugs or vulnerabilities in the program, SAST will never-- if it's a sound SAST tool, like the one I've shown before, it will never go below that line, which means never will it miss a bug. And that's really the big difference.
We have an exhaustive coverage here. And more so, we have very good coverage. Like even here, some subtle change in the variable-- we mentioned the division by 0. If it's a 0.000001 or something, it's the same comfort flow, but nothing bad will happen. But if it's a 0.0, something bad can happen. So sound SAST will find that. And this is actually an even deeper form of coverage. This is like MCDC, branch coverage, everything combined, including value coverage.
Also, of course, if you run a fuzzer, you might need hardware you have to play with-- for example, in ECU. If you have a sound SAS tool, it can emulate all of that. So it will not miss any bugs.
Now, how should you use those tools? Here's my recommendation from my experience as a cybersecurity researcher. Use SAST early. So that means, as soon as you commit code, you should analyze the code. And Skanda will show us how in the next few minutes. And that will actually show you where you have to spend more time to do defensive coding, for example. And it will also tell you where your software is already perfect, because we can have this proof.
On the other hand, you should use the fuzzer rather late, for several reasons. One of them is, of course, you have to write test cases and everything. And you will not have that in the beginning. Maybe you don't even have the target ready in the beginning, the ECU. And also, SAST really doesn't tell you what you should do. It just-- sorry, the fuzzer really doesn't tell you what you should do to fix the bug. It just uncovers the bug. And actually, it's too late at this stage.
So it makes more sense if you run the SAST tool early on to get a good code quality, and then run the fuzzer later when you have the target and everything ready and the software has a good quality. And for example, you could also use the fuzzer to exercise those findings of the SAST tool which you did not manage to review. There are some false positives on some conditions, and that is something you might want to review or try to reach with the fuzzer.
Also, very nice example on the bottom right of the screen. I can't resist. I have to explain it. So this is from an open source software where the developer has left a comment in plain text, as you see. Some property which is not so trivial to prove, it seems to render assert never files. That's what he says. And here's our sound SAST analysis tool coloring this property in green, which means, yes, the hunch of the developer has been correct. This property is true. The code is secure. Whereas, imagine that if the developers are wrong-- and this one would be, again, one of the orange findings-- then there is actually one input to trigger the assertion, which is a denial of service, program crashes, security issue.
So that, in a nutshell, is how you should use it. Use the SAST tool early. Use the fuzzer late. Don't do the other way around, because you will become very unhappy with that decision. Too many bugs, no way to fix, and you don't know how much more coverage you have to make.
All right. Coming back to the triangle. So now, knowing what a sound SAST tool this, which part of the triangle have we covered? Yes, we now miss no vulnerabilities. We can be sure, by math, that we have covered everything, that we have done enough coding. The speed, of course, is increased because I can start right away. I have less design iterations because SAST tool early figure out the defects, and not as late as a fuzzer. And of course, you save yourself a lot of work writing test cases and so on.
OK. So now we come back to the outline here. We have talked how you could start using the SAST tool-- as I said, early, or you can use it to prove the absence of vulnerabilities. Now the question is, how do we put all of that together? How do we automate? How do we become DevSecOps, as Skandar has said? And he will now tell us how we do that.
Thank you, Martin. So so far what we have seen is what actually SAST analysis is, and where we can use and what makes more sense in a workflow while using the SAST analysis. So we know that SAST analysis belongs to early phase of the software development lifecycle, and SAST testing is the latest stage. And what we have also seen is how we can already start using SAST analysis while developing the software. So now in this section, let us see how we can bring all of these bits and pieces together with automation, and how we can bring the entire team to collaborate and feel the sense of shared responsibility towards ensuring higher levels of security.
So let us try to take a look at how an agile team can establish a more mature issue detection process. So integrating the security processes into DevSecOps workflow and automating, it's not one big step. It needs to be performed in an iterative manner. And here, scaled agile also mentions about different levels to implement this sort of automation.
So level 0 is where no analysis is performed. Level 1 is where analysis is performed once per every release. This could be manual. And level 2 is a next step to level 1, where analysis is performed multiple times for release, and all the critical issues are added to the backlog. And this level could also be manual.
But level 3 is the phase where entire workflow needs to be fully automated, and frequent analysis is made on the software so that all the critical issues are resolved here. And also, coupled to it we could have an interactive dashboard-- as we are seeing here on the screen-- which would let the developers, quality engineers, software managers, and team leaders to collaborate on and work towards achieving higher level of robustness and back the quality.
So level 4 is a stage where the software is already quite stable and secure, and at this stage, any new issues that are incoming should be rejected by the build. For example, here CI pipeline could implement quality gates which would reject the software submitted by the developers if it does not just reach certain objectives. And then IDE plugins, as I said earlier, could be used by developers to resolve most of the security defects while they are developing.
So a fundamental DevSecOps workflow with Polyspace SAST would look something like this. So we have seen how developers could use the quick SAST on the IDE to get the direct feedback, review, and fix the issues. So doing that will result in lesser rejects in the code review while doing the code check-ins. And the code merges then will trigger more sound SAST analysis, as Martin described. This is where sound SAST analysis is performed with extensive analysis with sound mathematical proof. So this step is to only find the remaining issues which are not already found with quick SAST.
So let us try to take a look what happens on the CITD pipeline here with quality gate implemented. So the developer submits the software, and it would be checked out, configured, and analysis is made. Here, we see that the quality gate is failed because some of the quality objectives is not met with the software that is developed by the developer. And here is a link, which is sent as a notification for the developer who could access the web-based user interface, which lists out all the issues that fail the quality gate. Developer could review all these defects with contextual help-- what we have seen before. And also, there is a nice event phrase which developers could use to debug and resolve these issues.
So now what we have is the sound SAST analysis, which could be published into SAST results server, which comes with the web-based user interface. And we have seen how notifications would be sent to developers for reviewing it on the web-based user interface. So now, the automation part includes developers also to enhance the security by involving in the process.
Same way, the same notification could also be sent to quality engineers and team leaders, who could again get access into the same web-based user interface to progress and also track on the quality objectives.
Let us take a look at how Polyspace access web-based user interface would look like. So the Project Explorer will list out all the analysis results uploaded, and the project details here just throw some more light on the project itself. So the trend graph here gives a nice pictorial representation of the number of defects and violations over time, over the course of the project. It could be also configured to get the difference in defects over different milestones or releases.
So here, what we are seeing are some more filters, like new unassigned issues with the new code submit. So here are the list of new issues. It could be set with the status, severity, and assigned to developer back to fix. And while assigning to a developer, it could be also linked to bug tracking tools like Jira. And this would also reflect on the developer's account to fix this defect.
So now we have also quality objectives, which could be set as milestones at different phases of the software. And here on the configuration section, each of these classes of defects and violations could be configured to specific quality objectives. And this would help to progress through the quality in the project over time.
Last but not least, here what we have is a comparison between the current SAST analysis and any of the previous search results. So it would give an overview on how many defects have been resolved, how many defects have been introduced newly, and how many of them are unresolved, as we see here.
Now we have direct feedback. We have flow and automation with developers and all other team members. And we also have an opportunity for everyone to learn about what's happening with the entire project by collaborating on the dashboard.
So what we have seen until now is only a basic DevSecOps workflow. But we need not stop there, because we might have to use a lot of other things when it comes to DevSecOps workflow. Polyspace provides APIs and deep integration possibilities to many, many advanced use cases. So for example, you may have to use cloud-based architectures for scaling the resources well, and maybe to access them remotely and more securely from any location. So Polyspace analysis could be just offloaded from your client machines onto more powerful cloud-based machines, which is possible with AWS, for example, Azure, or Docker, et cetera. And also, it is possible to assign the defects from Polyspace into bug-tracking tools like Jira or Redmine. And there are many, many other possibilities which we can see here on this slide.
So coming back to the triangle that we had. So now with the automation and team collaboration, what we covered is how we can quantify and track the quality with the web-based user interface, and then we also have seen how we can reuse the automated security workflows over and over again for multiple iterations, and how we can gain knowledge on the project itself and its robustness level. And then incremental workflow obviously will improve the speed of software deliveries.
So now we almost covered all the points here for the software security. And now it's time to look back at the complete summary of what we have seen so far. So I would like to hand it back to Martin to summarize everything that we have seen, and to add more points.
We are reaching the end of the webinar. So if you do have any questions, put it in the Q&A or chat. Meanwhile, I'm going to summarize what we have seen, and also explain you a view of the options you might have to try out the tools.
OK. So we looked at this triangle, and Skanda just completed all of the green checks. Now we have talked about how you have good quality and how you can make it repeatable, and of course also how you can be quick doing so. And just to remind us of what we have seen, we had dashboards up here to take the quality. We had sound static analysis to really miss no vulnerabilities. We had IDE plugins, which can educate the developers. And of course, we also talked about CIA and pipelines, and how you can actually run those things also on AWS.
And for the speed, of course-- this is just one aspect, to be quick. But we have also shown you how to find things early, and that means it also reduces the cost, as you might know. Last but not least, integrations. So everything has to be really flowing well if you want to make it scale for a team. So that also goes into the category of speed-- deep integrations with other tools.
So this together is an example of how you can set up a workflow around the SAST tool, which brings you really good code quality and which allows you to reason on the security properties-- confidentiality, integrity, availability-- and even how to be sure that you haven't missed anything.
So how can you get started? Well, first of all, I would like to point you to a whitepaper. If you're interested in how effective a SAST tool is in discovering CVEs, we have actually analyzed more than 60 CVEs which are documented publicly and put them through the SAST tool, and it turns out that it can find quite a lot. teaser it's more than 80%.
But you have to use the tool right. So what I'm saying here is, it's not enough to just have a SAST tool. You have, of course, also to use it in the right way. It's not only the process. It's also how you work with the results, how you actually set up the tool. These kind of things, they're really important, but if you do them right, you get a real good view on your software, a real high confidence that you haven't missed anything.
Speaking of which, since it's important to use the tools in the right way, there are more webinars on Polyspace. They are online. They're recorded. Just go to mathworks.com. Follow the link here on the slides. And then you will have a free webinar, which you can just play for yourself and then take notes and learn the things you should be doing. Of course, there's also training, and there is a static analysis blog which gives further insights. But that's probably something which Ralf might want to tell you now-- how you could continue if you wanted to try the tools.
Thanks a lot, Martin. Yeah, there is a link on this page here you can visit, and you can easily request a free trial license if you want. You can also reach out to me, and I am happy to help you to get a trial license if you want to start using Polyspace. So don't hesitate to reach out to me.
Thanks from my side.
Yeah, also from my side. Thank you very much for joining us today, and we look forward to seeing you in one of our upcoming events. Thanks a lot, and have a great day. Bye bye.