Meera Rao

Hello everyone. Good morning, good afternoon, good evening. Hope you all are enjoying the conference.

Today, I'm going to talk to all of you about cracking the code of DevSecOps with Intelligent Orchestration and CodeDX.

DevOps and DevSecOps have been a hot topic in recent years. DevOps integration is critical, especially for application security, and application security must not add any friction to this process. We are going to look at some of the challenges, and then how both Intelligent Orchestration and CodeDX are able to help you address some of the challenges. Both Intelligent Orchestration and CodeDX work behind the scenes and make sure that you achieve true DevSecOps.

About me a little bit. My name is Meera Rao. I've been working with Synopsys for 14 years now as a senior director for product management, focusing mainly on DevOps solutions. I have over 25-plus years of experience at different levels, like in software development. Then I worked as a senior principal consultant, consulting across several Fortune 500 companies, helping them achieve realistic goals for practical DevSecOps and CI/CD.

Again, if you want to reach me, I'm very active on Twitter and LinkedIn, and then maybe you can also email me at mmeera@synopsys.com.

Let's see what are some of the challenges that we see for application security. We have seen that application development practices continue to evolve. We have seen developers build several applications using different tools, different technologies, different frameworks. But then, at the same time, cybercriminals have developed new levels of attack strategies, and it has intensified in the past several years, making it even more important to scrutinize applications for security vulnerabilities.

When we talk about that, we always see that application security is not keeping pace with DevOps. There are a lot of frameworks, technologies, and new languages that developers want to use. They are literally sprinting to the finish line. Application security teams are saying, "Hey, no. Not so fast. Please wait. We want to make sure that you have run through the multitude of security activities, whether it is automated or manual." Developers are saying, "We cannot wait. You're taking way too much time in order to run the scans. Give us the feedback." With all of this, what's happening is we have insecure software. If you follow certain blogs, if you subscribe to certain security networks and blogs, you will see that each and every day we see a lot of companies releasing patches, a lot of companies in the news because of application security vulnerabilities.

What are some of the challenges that we see? The one very biggest challenge that I see is traditional application security testing is siloed. We have a lot of activities that we want to perform, whether it is in the planning phase, the coding phase, or build phase, like you see in this diagram. But then each and every activity that we perform is so siloed. In the planning phase, we say you need to perform security requirements, threat modeling, and architecture risk analysis. But when we do the threat modeling or when we do the risk analysis, those should feed the further activities that happen in your SDLC. The threat modeling should feed the code review that happens, whether it is automated or manual. The risk analysis that we do should be able to feed the dynamic testing or the manual penetration testing that happens. But usually that is not what we see in the industry.

There is more code, there is more open source, and there is more complexity of the code that is being written, which means when there is more of everything, there is also more security risk. But then developers want more velocity. In most of the organizations that we work with, they want to deploy either every week or maybe every day, and that means less time for security teams to perform their activities. Traditional security tools often cause friction because they take a lot of time to run. They decrease the velocity because when they take a long time to run, we need to wait until we get the results. They also require time-consuming manual processes, either triaging or configuring or changing the way the tools run, which is very un-DevOps. Because of that, being slower for application security teams is no longer an option.

Those are some of the challenges that we are seeing. When we performed this research, Synopsys sponsored commissioned research by 451 Research a few years back. We asked: what are some of the challenges that you see when you build in all these tools in your pipelines? The very top challenge was lack of automated, integrated security testing tools. Every application, every tool that you bring in your organization, whether it is for static analysis, software composition analysis, dynamic analysis, interactive analysis, or container scanning, has its own command-line interface. Each and every tool has its own way of running in the pipeline or has its own way of providing the feedback.

When you have to automate and onboard several tools in your pipeline, and each and every one of them has its own dashboards, it becomes a huge challenge. It is easy when we are doing a pilot or a POC for one or two tools, but imagine working with an organization and helping them onboard thousands of applications. This lack of automated and integrated security testing tools becomes a huge challenge.

The next thing is an inconsistent approach to services. In the beginning, there were all these beefy machines, as we used to call them, which had a lot of RAM, a lot of hard disk space, and a lot of memory for us to run the scans. But now, when I work with most of these organizations, most of them want fast containers which can run these scans and then disappear. Again, the challenge is, when we want to bring all of these tools and technologies into our CI/CD pipelines, we have to look at all of those. What does this technology tool provide? Is it consistent? Can I run it as a container? Do I still need those beefy machines? Can I use virtual machines for this? Can I deploy it in cloud? That is what a lot of organizations want now. Also, how are these tools providing me the reports so that I can provide that fast feedback to my developers without slowing security down?

We also want to make sure that the other biggest challenge we saw was security testing slowing things down because these tools run for hours and hours. Can I run incremental scan? Can I make sure that I can provide that fast feedback that my developers want? When you go talk to the development team itself, some of the challenges we saw were false positives. If you bring in a tool and automate without completely onboarding the tool, triaging the results, and making sure that you notify them of the vulnerabilities that they truly care about, then you will have this challenge about false positives as well as developer resistance. Because if you give them the report when they are almost at the end of their SDLC, what use is it for the developers?

Last but not least, compliance. A lot of companies have policies and processes in place for a lot of those compliance scans, whether it is manual penetration test, manual code review, or a full-blown static analysis with no rules disabled. There are a lot of these requirements that companies have that you need to be able to satisfy. How do we bring in all of these tools and technologies, automated activities, manual activities, and still help the DevOps team to maintain their velocity? That is where you need to look at a modern approach for your application security using tools like Intelligent Orchestration and CodeDX, and that is what I'm going to focus on next.

In order to bridge that gap, within Synopsys we saw those challenges working with organizations, and then we came up with a patented solution called Intelligent Orchestration. Some of the key features of that are what you're going to see here. Manage everything, every policy, every process, every requirement that you have as code. It manages your policy as code and enforces them. It is tool-agnostic. Like I said, when you have inconsistent approaches from several tools that you have, you may have tools from Synopsys, you may have commercial tools, you may have open source tools. At the end of the day, when you're building these pipelines, it has to be tool-agnostic. It shouldn't care whether you're using commercial tools or open source tools, because at the end of the day, the developers need to know whether they wrote secure software or whether there are certain vulnerabilities that they need to fix. They shouldn't care whether I ran Synopsys tools or commercial tools or open source tools, how did I run them, how did I configure them, what changes did we make. The only thing they care about is delivering that right message or right information to the right teams.

We need to ensure that the right tests are run at the right time. We'll talk in great detail about this, and make sure that we manage issue prioritization and filtering, not pushing all the defects to the developers, but just the ones that they truly care about. Also automate the workflow for all manual activities that are compliance-driven within your organization. Any time there are major changes, you need to perform a major code review. Any time the dynamic testing finds cross-site scripting or SQL injection, we need to do a manual penetration test. All these requirements that you have somewhere, either as a spreadsheet or somewhere in your Confluence, bring all of those into Intelligent Orchestration, and it will be able to enforce those policies.

I hope you all subscribe to Synopsys blogs and you saw that, a few months back, we acquired CodeDX. Some of the key features of CodeDX are how it seamlessly fits with Intelligent Orchestration. It's able to automatically execute some of the application security tools that you use. It's able to correlate and combine issues from across open source, Synopsys, and commercial tools that are run, not just for application security, but maybe for network testing, maybe you did manual activities. You can bring in all of those results, and CodeDX is able to correlate all of that. It's able to prioritize the vulnerabilities. Just like Intelligent Orchestration is able to let the developers know what are some of the critical vulnerabilities that were found, you can also prioritize that within CodeDX. It's able to track remediation across, and then you have a centralized dashboard for all of the risk visibility. You have one place where you can look at all of the results from all of the tools, correlated, harmonized, prioritized across all the projects in your organization.

Now let us dig deep. When I say Intelligent Orchestration is tool-agnostic, what do I mean by that? Here, I'm going to walk you through certain screens. We have a lot of demos that are recorded. Most of them are on BrightTALK and other channels. Please take a look at those.

Here I'm showing you how Intelligent Orchestration is tool-agnostic and knows what to run and when. If you're seeing here all the way at the bottom, it's saying, "I ran static analysis with Coverity, software composition analysis with Black Duck, dynamic analysis with Seeker, which the payload is provided by OWASP ZAP, also did image scanning using Aqua, and then triggered manual code review and manual penetration test." Based on the risk score, which looks at what is the change significance that the developer checked in, what are some of the open vulnerabilities out there, what is the business criticality of the application, what is the data classification. Hopefully you have risk scoring for each and every application within your organization. This consumes that risk scoring, and on top of that it uses the change significance: what did the developer check in? Also, what are the open vulnerabilities in your defect tracking that it consumes? It comes up with this score, and then you can say, "If the score is between this and this range, run all of these tools and technologies," and it's able to run that.

Like I said, it is completely tool-agnostic. You can also say, "I want to use, for some projects, open source tools." Here it's saying for the risk score that we have, static analysis is enabled with SpotBugs, software composition is enabled with OWASP Dependency Check, and then other activities are disabled. But then I also still ran image scanning with Aqua. Similarly, just like Intelligent Orchestration is tool-agnostic, CodeDX also is tool-agnostic. It works with all Synopsys tools like you see here. I have a project which is showing results from Black Duck and Coverity, but then you also see other tools highlighted like Checkstyle, Dependency Check, ESLint, JSLint, and PMD. You can bring in commercial tools and open source tools with both Intelligent Orchestration and CodeDX.

We talked about delivering the right results. You always see the developer resistance, false positives. What Intelligent Orchestration does is look at what are some of the vulnerabilities that the development team truly cares about. Tools are designed to find more. If you run a scan with a static analysis tool, it will find thousands of issues. Do you want to push all those thousands of issues to your developers? No. You want to make sure that you look at just the critical and high-risk issues and notify them immediately. This is one example of GitHub Actions where, within the code scanning alerts, you configure what you want to notify the developers, and then Intelligent Orchestration will just showcase those results to the developers.

Everything else will still go into their enterprise dashboard, whatever they are using. If they're using Polaris, it goes into the Polaris dashboard. If they are using Coverity, Coverity Connect, or Black Duck, the results go to Black Duck Hub. But only the ones that they truly care about will they be notified immediately. The ones that are critical, the ones that are high, where they have an SLA of either seven days, one week, or two weeks to fix those defects. It delivers the right information to the right team and also avoids defect overload. If you say, "We have Slack, we have Microsoft Teams, we need to push those results or notify them immediately," then you can do that exactly like you saw within your version control: GitHub, GitLab, Bitbucket. Here it's saying that I'm going to push those results, notify the team in their Slack channel that they want to be notified as soon as I find those vulnerabilities that they truly care about.

Same thing. Everything is streamlined. Whether you are doing static analysis, software composition analysis, or dynamic analysis, they get notified one way all the time, no matter what tool they use, no matter what technology they use to be notified. It's always completely consistent based on the tool and the technology that they prefer. Also, if you want your developers to be notified, pause the build or break the build, depending on how mature your development organization is. Again, the same consistency is applied across for the developers and any other teams to be notified.

You can do a similar thing even within CodeDX. Along with Intelligent Orchestration and CodeDX, you are able to prioritize the vulnerabilities that the development team truly cares about. You can prioritize it based on tools. You can also prioritize it based on the severity type. Any time there's a high or a critical, we need to be able to notify the development team. Intelligent Orchestration, through extensive APIs that CodeDX provides, is able to talk to CodeDX, get all of that information, and push that information to the development teams.

We also talked about not slowing down the velocity. How does this happen? Very interesting. Why do I have a dishwasher here? Have you used the latest dishwashers? They are very smart. You have an upper rack, you have a lower rack. You can finely tune the dishwasher. How deep do you want to scan? What should be the temperature? Do you want it to run only the top rack? Do you want to run it only the bottom rack? Deep dish cleaning. There are so many controls available. If you have just a few plates and spoons and glasses to be washed, you fill the upper rack and then press that button. You will not use the same cycle for every type of washing that you need.

Similarly, with application security. If your developer checked in just some configuration file or a JavaScript file where you haven't made much changes, why would you run all the scans? Whereas if your developer made some major changes for authentication, authorization, cryptography, you want to make sure that on top of all the scans that ran, you also want to run some manual activities. The dial that you use for application security should match that you're using for your dishwasher. When you want, it should be deep dive. When there are not much changes and then you committed a change to a CSS file, why do you even want to run a scan? You have to run the right tools at the right time and with the right depth, and that is what Intelligent Orchestration does.

It is behind the scenes, looking at all of these: all the policies that you have, what did the developer check in, how deep is that change, code change significance, what are the residual risks in the defect management that they have. Based on your policy, do I need to run a deep-dive scan? Do I need to run manual activities? Can I skip the activities and run? That is what Intelligent Orchestration does.

In this case example, you're seeing that the code change significance was very low. The open vulnerability score was very low. Intelligent Orchestration said the score is 17.75: I'm going to skip all the activities and breeze through the next stage that the developer has in the pipeline. Whereas in this case, the code change significance was high. Open vulnerabilities also are high. It said, "I'm going to run everything: static analysis, all of the activities." I'm only showing four automated activities, but you can bring in other activities that you have, and then it's also saying, "I'm going to run manual code review and manual penetration test," because that's what is needed. It triggers that. What do I mean by trigger? Whatever policy you have, send notification to someone, create a Jira ticket. For those manual activities, it is able to perform all of those.

Same thing with security sign-off. A lot of organizations we have seen have the security sign-off. They want to be notified when the score is very bad. Here, both Intelligent Orchestration and CodeDX work together. Intelligent Orchestration asks CodeDX, "Hey, I pushed all the results to you. You consumed all the results from each and every tool that ran. What is the final score? Hey, it's F. Okay, then I'm going to pause." We found that the grade is bad, and then it's also able to go back and look at open vulnerabilities: how many critical or high, again, you decide how you want to configure, are open. Then pause and notify a risk owner. Every organization has a risk owner. You want them to come back and sign before the code goes to the next stage in the pipeline. That's what it does here. It is able to look at the open vulnerability score, look at the grade, and provide that visibility to the risk owner to say, "Come and sign off."

Also, any time you need to do any manual activities as per your compliance requirements, maybe you have a lot of PCI requirements, GDPR requirements. You bring that into Intelligent Orchestration, and it will be able to enforce those compliance requirements that you have.

You have one dashboard, CodeDX, where you can look at the risk score of an application. You can look at the open findings. You can look at the remediation timeline, how much time the developers took to remediate. You can look at every application in one centralized dashboard, all the automated activities that you did, all the manual activities that you did. You can have risk visibility at a project level versus a business unit level. You have all of the information that you need in CodeDX.

Without spending too much time because this was only a half-hour time slot: if you want to truly achieve DevSecOps, it is with Intelligent Orchestration and CodeDX. Your outdated AppSec, where you have too many findings; my scanning slows down my development; I don't have a risk model that I can bring into my pipeline; disconnected security activities; someone performing automated, someone else maintaining all the manual activities; and then your exploit still happening out in the world. Throw all of that away, and bring in the next-generation application security with Intelligent Orchestration and CodeDX, where you have a centralized dashboard. You have APIs for everything. You run AST tests without slowing down the pipeline. You can automate the initiation and management of out-of-band activities, and you are actually reducing the burden on developers by automating as much as possible and only surfacing the most important issues back to your developers for remediation.

Last but not least, you're ensuring that the right tests are run, the right analysis is run at the right time based on your application and company's policies, based on the risk profiles of your applications, based on the code change significance. It gives your team, whether it's the DevOps team, the security team, or the development team, the flexibility to adapt the solution to their specific development workflows and toolchain.

There are a lot of insightful reading materials available on the Synopsys blog. Please take a look at that. Like I said, if you have any questions, if you have any thoughts, please do share on my LinkedIn or Twitter or my email. I hope you are enjoying the conference and hope to see you all in 2022. Have a great conference. Thank you, and take care. Bye.