Cybersecurity for your C and C++ Embedded Software with Advanced Static Code Analysis

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 with me is 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 Ismaning office in Munich. So I have experience of about four to five years in C and C++ critical software development for automotive industries. So 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, a reminder, if you do have any questions during the course of this webinar, just go ahead and find the chat or 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 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 year.

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 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 onscreen, 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, a 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 this. And the one I have chosen here, it actually crosses one interesting point, which is programming errors. And if you look at the graphics there, 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 will 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 a text. Goal number two is repeatability, which means I need to be able to also do that on my next project.

And goal number three 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 the vulnerability, you have to create a patch. And that has to happen quickly. So these are three very important pillars of cybersecurity. And let me quickly give you examples of 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. You are able to repeat this engineering at the next project you have. Then you're just lacking speed. So that could, for example, be you're building a satellite. You have high security, high quality. 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 hard-coded 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 is like snake oil, if you know what I mean. So that is something you have just 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, TÜV 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 a 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 projects, and how you can build some knowledge and skills also into 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 applications 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 to 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 on the source code. There's a division. Maybe you now know what I'm going for. So let's say this is a division. And the dividend becomes-- sorry, the divisor becomes zero. Then what happens to division by 0? And the program crashes. This is a simple example of a security issue because this is, in essence, a vulnerability, is the 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 proceed here? And actually now, let's put the solution on screen. Where's the bug? Actually, that is not-- as bad as 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 will 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 SAST tool, the Static Application Security Testing tool. So let's see how the tool actually can provide us 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 a perfect software, that means it an empty list. But usually, there are some open attacks surfaces. Good thing about SAST, it's really rigorous. And it's fully automatable. And that is what we will show you for the remainder of the session.

The term 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 in our background-- Polyspace exists since about 1999. We are very closely related to the Ariane overflow accident. So if you don't know it, Ariane maiden flight, it suddenly exploded. And nobody knew why. And that was the birth 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 will 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, 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 were just talking about coding standards best practices-- for example, CERT C, 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 robustness analysis, which is very important for security. And so the idea is, for such a tool, to consider each and every possible approach, to consider the specific target processor, everything that could happen. And that would 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. It gives you 100% proof that there are no defects in the program if you have not made-- if you have not made any. And if you have a vulnerability, it will, of course, point to it, and tell you how 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 sites, building standards, 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?

OK, 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 secured workflow. But our next big question is when and where can we use SAST analysis to ensure the security in the DevSecOps workflow?

So developers and testers are the firsthand 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 speeds 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 result, if there are any security issues, it would be assigned back to the developer. But 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-off 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 plug-in on the IDE and develop the software, and also run such analysis locally, as in when they are developing, to get the analysis results, which serves as an immediate feedback with reviews and the possibility to fix them, before even submitting the code.

So then, the code that is submitted now is more cleaner, more robust, and secure. And the test results are most probably greener than before, which could be used to get the compliance report very early. So let us try to take a look at how Polyspace, as your code slash plugin, works on Eclipse IDE. So here, I have a demo project on the Project Explorer. The code, you can see, is 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 classes of 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 your 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're 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 defects. But also, the plugin will enforce the developers to adhere to secure design principles. Here, I have two examples. On the left is Zero Trust approach, which is a security architecture which believes in having unprotected state for all sorts of communication within the software.

Polyspace here could be configured to support this principle. And on this example here, all the file accesses are blacklisted from Polyspace. 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 de-referencing 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.

Right, 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 managed to almost control everything, or 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 the Heartbleed issue from the OpenSSL library. So this was caused because they just chose the wrong variable for length during memory copy. So in essence, these two issues could have been found with Polyspace as your code SAST analysis plug-in on the IDE while the developers were developing it. But unfortunately, they got slipped into the production code. So, right, just to summarize-- so 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 approaches strongly recommends getting everything right from the beginning, before any dependencies are added into that. So, well-- so now we know how we could use SAST analysis on the plug-in 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.

So also, it removes the disadvantage we had with the trade-off between speed and consistency. Developers could consistently used this plug-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.

Thanks, Skanda. OK, quick summary also for my side. What Skanda has shown is the early feedback. And that is related to all of the current guidelines we have seen through CWE patterns, and even through 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, a 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, actually, a simple testing approach, or let's say, a SAST test 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 those lines, maybe the green one here.

This is one specific way to run the program. So let's say one input, and then a 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 could 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 the 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 a 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 of thousands of years in a normal-sized 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, in a famous quote here, "program testing can be used to show the presence of bugs, but never to show their absence." You can test and hit a bug and see it. But it cannot show that you have tested enough. And I will show you 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'll 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 are interested in 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.

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 here 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 want. 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 100,000s of years. And as I've 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 de-referenced. You get a full explanation here. And that even tells you exactly how big the buffer is, and how much off the pointer is. It has a nice event trace, which tells you exactly how you got there. And if you click through there, you will actually find, this is the location record. 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 how with a nice back-trace. 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, American Fuzzy Lop fuzzer. 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 ISO21434 or the IEC standard, they all mention fuzz testing. And it's, in essence, a complementary requirements-based testing. I just think of requirements-based testing as testing what you expect to work in the design, like 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 depress your program with a lot of test cases. How does it now relate to 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 of this, we cannot cover everything. So there will be a difference between the actual number of bugs and 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. 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 MC/DC or value coverage. And on top of that, you need to write the test cases and select a test corpus for 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 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 started, it is assuming that everything is broken.

Bugs come 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 the SAST tool will drop. And if it comes stationary, this 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 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, 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 value coverage. Like even here, some subtle change in the variable-- imagine the division by 0. If it's a 0.00001 or something, it's the same comfort level. 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 is like MC/DC 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, an ECU. If you have a Sound SAST tool, it can emulate all of that. So it will not miss any bugs. Now, how should we 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 also, it will also tell you why 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 issue ECU.

And also, SAST really doesn't tell you what you should do, or 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 read to the fuzzer. Also, a 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 true. And so it never fails. 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 developer were 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-- to 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 is, which part of the triangle has been covered? Yes, we know there's 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 will 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 earlier, how 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?

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 more mature issue detection process. So integrating the security processes into DevSecOps workflow and automating it, 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 per release. And all the critical issues are added to the backlog. And this level could also be manual.

But level 3 is a phase where the 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 practicality.

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 research 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 CI/CD 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 has failed because some of the quality objectives is not met with the software that is developed by the developer. And here is the link which is sent as a notification for the developer who could access a web-based user interface, which lists out all the issues that failed the quality gate. Developer could review all these defects with contextual help, what we have seen before. And also, there is a nice event trace, which developers could use to debug and resolve these issues.

Right, so now what we have is Sound SAST analysis, which could be published into SAST Results Server, which comes with a 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. So let us take a look at how Polyspace-accessed 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 and unassigned issues with the new submits-- I mean new code submits. So here are the list of new issues.

It could be set with the state of severity, and assigned to developer, back to fix. And while assigning to a developer, it could be also linked to bug tracking to tool. Now, we have data feedback. We have fluent 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 it 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 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.

All right, thanks, Skanda. 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 am going to summarize what we have seen, and also explain to you a few of the options you might have to try out the tools. OK, so we looked at this triangle. And Skanda has just completed all of the green checks. We have talked about how you have good quality. 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, so we have dashboards up here to track the quality. We had the Sound SAST analysis to really miss no vulnerabilities. We had IDE plug-ins, which can educate the developers. And of course, we also talked about CI 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, right? 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, reliability, 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 white paper, if you're interested in how effective the SAST tool is, and 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. its a 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 results, how you actually set up the tool, these kinds of things that are really important. But if you do them right, you get a real good view on yourself, and 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 are recorded. Just go to methods.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.