00:00:13

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 Kodiak. Um, so their ops and DevSecOps has been a hot topic in the recent years. We all know that their ops integration is critical, especially for application security and application security must not add any friction to this process, right? So we are going to look at some of the challenges and then how both intelligent orchestration and Kodiak is able to help you address some of the challenges. So both intelligent orchestration and Kodiaks work behind the scenes and then make sure that you achieve through dev sec ops. Um, so, uh, about me a little bit, my name is Mira Raul. I've been working with synopsis for 14 years now as a senior director for product management, focusing mainly on DevOps solutions.

00:01:29

I have over 25 plus years of experience in different, uh, uh, levels like in software, uh, development. Then I worked as a, uh, senior principal consultant consulting across several fortune 500 companies, helping them achieve a realistic goals for practical DevSecOps. And CICB. So again, if you want to reach me, I'm very active on Twitter and LinkedIn, and then maybe you can also email me at M at synopsis.com. Uh, so let's see, what are some of the challenges that we see, uh, for application security? Um, so we have seen that application development practices continued to evolve, right? We have seen developers build several applications, right? Uh, using different tools, different technologies, different frameworks, but then at the same time, cyber criminals have developed new levels of attack strategies. And then it has intensified in the past several years, right? Making it even more important to scrutinize applications for security vulnerabilities.

00:02:52

So when we talk about that, we always see that, uh, application security is not keeping pace with DevOps, right? So there's, there's a lot of, uh, frameworks. Um, there are a lot of technologies, a lot of new languages that developers want to use. They're literally sprinting to the finish line. And then 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 activities, security activities, whether it is automated or manual. And then developers are saying, we cannot wait, right? You're taking way too much time in order to run the scans, give us the feedback. And then with all of this, what's happening is we have insecure software. So if you follow certain blogs, if you subscribe to certain security, uh, networks and then blogs, you will see that each and every day.

00:03:54

We see lot of, uh, uh, companies releasing patches, lot of companies in the news because of application security vulnerabilities. So what are some of the challenges that we see? The one very one, uh, biggest challenges that I see is traditional application security testing is siloed, right? So we have lot of activities that we want to perform, whether it is in the planning phase or the coding phase build phase, like you see in this diagram, but then each and every activity that we perform are so siloed, right? So in the planning phase, we say, you need to perform security requirements, tech modeling, 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, right? So the threat modeling should feed, uh, 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.

00:05:10

But usually that is not what we see in the industry, right? So there's more code, there's more open source. There is more complexity of the code that is being written, which means when there is more of everything, there's also more of security risk, but then developers want more velocity, right? They want to deploy almost in most of the organizations that we work either every week or maybe every day. Uh, and then that means less time for security teams to perform their activities. Right? So traditional security tools often cause friction. Yeah, because they, they take a lot of time to run. They decrease velocity because when they take long time to run, we need to wait until we get the results. And then they also require time consuming, manual process, either triaging or configuring or changing the way their tools run, which is very on dev ops.

00:06:15

And then because of that, being slower for application security teams is no longer an option, right? So I think those are some of the challenges that we are seeing. And then when we perform this, um, uh, um, uh, research, um, synopsis sponsored, commissioned the research by 4, 5, 1 research, if you years back, we asked, what are some of the challenges that you see when you build in all these tools in your pipelines? Right? So the very top challenge was lack of automated, integrated security testing tools. So every application, every, uh, uh, tool that you bring in your organization, whether it is for static analysis, software, software, composition, analysis, dynamic analysis, interactive analysis, container scanning has its own command line interface each and every pool has its own way of, uh, running in the pipeline or hazards own way of providing the feedback, right? So when, when you have to automate and onboard several tools in your pipeline and each and every one of them has its own, uh, what do you call, uh, dashboards?

00:07:37

It becomes a huge challenge. Yeah, it's easy when we are doing a pilot or a POC for one or two tools, but imagine working with a, uh, with an organization and helping them onboard thousands of applications, right? So this lack of automated and integrated security testing tools becomes a huge challenge. Then the next thing is inconsistent approach to, uh, services, right? So, um, in the beginning there were all these beefy machines that we used to call, uh, which had like lot of Ram, lot of hard disk space, a lot of memory, uh, for us to run the scans. But now when I work with most of these organizations, most of them want fast container, which can run these scans and then disappear. Right. But then again, the challenge is when we want to bring in all of these tools and technologies in our CI CD pipelines, we have to look at all of those.

00:08:44

What is this that the, uh, the technology tool provides? Is it consistent? Can I run it as a container? Do I still need those beefy machines? Can I use virtual machines for this? Right. Can I deploy it in cloud? That is what loss a lot of organizations want now. And then also, how, how are these tools providing me the reports so that I can provide that fast feedback to my developers without slowing security down. Right. So, and then we also want to make sure that the other biggest challenge we saw was security testing, slowing things down because these tools run, uh, for hours and hours. Can I run incremental scan? Can I make sure that I can provide that fast feedback that my developers want? And then when you go talk to the development team itself, some of the challenges we saw was false positives.

00:09:46

Yeah. If you bring in a tool automate without completely onboarding the tool, triaging the results, 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 a developer resistance, right? Because if you give them the report, when they are almost at the end of their SDLC, what uses it for the developers, right? And last but not the least compliance, lot of companies have policies and process in place for lots of those compliance scans, right? Whether it is manual penetration, test, manual code review, or a full blown static analysis with no rules that are, uh, disabled. So there are lot of these requirements that companies have that you need to be able to satisfy. So how do we bring in all of these, uh, tools and technologies, automated activities, manual activities, and still help the DevOps team to maintain their velocity, right?

00:10:57

So that is where you need to look at a model approach for your application security, using tools like intelligent orchestration and codex. And that is what I'm going to focus on next. So in order to bridge that gap, right? So synopsis within synopsis, we saw those challenges working with organizations. And then we came up with a, a patented solution called intelligent orchestration. And then 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, right? So it manages your policy as code and enforces them. It is tool agnostic. Like I said, when you have inconsistent approach from several tools that you have, right? So you may have tools from synopsis. You may have commercial tools, you may have source tools. So the, at the end of the day, when you're building these pipelines, the it has to be tool agnostic, right?

00:12:10

So it doesn't, it shouldn't care whether you're using commercial tools, 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 synopsis tools or commercial tools or open source tools. How did I run them? How did I configure them? What changes did we make? Right? And the only thing they care about is delivering that right message or right information to the right teams. And then we need to ensure that the right tests are run at the right time. So again, we'll talk in great detail about this and then 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. And then also automate the workflow for all manual activities that are compliance, driven within your organization, right?

00:13:14

Anytime there's a major code review, um, major changes, you need to perform a major code review, any time that dynamic testing frying cross-site scripting or sequel injection, we need to do a manual penetration test, all these requirements that you have some way in the, either as a spreadsheet or somewhere in your conference, bring all of those into intelligent orchestration, and it will be able to enforce those policies. And then we, I hope you all subscribe to synopsis blogs. And, uh, you, you saw that in, in past few months back, we acquired codex. So some of the key features of Kodiak's is how it seamlessly fits with intelligent orchestration. So 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 opensource synopsis and commercial tools that are run, not just for application security, but maybe for network testing.

00:14:24

Maybe you did manual activities. You can bring in all of those results. And codex is able to correlate all of that. It's able to prioritize the vulnerabilities, right? 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 Kodiak's, it's able to track remediation across, and then you have a centralized dashboard for all of the risk visibility, right? So you have one place where you can look at all of the results from all of the tools, correlated harmonized, um, uh, prioritized across all the projects in your organization. So now let us dig deep. When I say intelligent orchestration is tool agnostic. What do I mean by that? So, so here we, I'm going to walk you through certain screens. Um, you, we have lots of demos that are recorded.

00:15:30

Most of them are on BrightTALK and other, uh, um, channels. Please take a look at those. So here I'm showing you how intelligent orchestration is tool agnostic and knows what to run and when, right. So 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, black deck dynamic analysis with Seger, which the payload is provided by zap also did image scanning using Aqua and then triggered manual code review and manual penetration test. Right? So based on the risk code, which it looks at, what is the change, uh, 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? So hopefully you have the risk scoring for each and every application within your organization. So this consumes that risk scoring, and on top of that, it uses the chain significance.

00:16:37

What did the developer check-in and then also what are the open one letter abilities, risk management within your, uh, uh, uh, uh, defect tracking that, uh, it consumes, right? And it comes up with this score. And then you can say, if the score is between this and this range around run all of these tools and technologies, and it's able to run that. And like I said, it is completely tool agnostic. So you can also say, I want to use for some projects, open source tools. So here it's saying for the risk score that we have static analysis is enabled with spot bugs. Dynamic software composition is enabled with dependency check, and then other activities are disabled. But then I also still ran image scanning with Aqua, right? So similarly, just like intelligent orchestration is tool agnostic. Code DX also is tool agnostic. It works with all synopsis tools.

00:17:39

Like you see here, I have, uh, a project which is showing, uh, results from black dark and Coverity, but then you also see other tools highlighted, like check textile, dependency, check IES, land JS, Lin PMD, right? So you can bring in commercial tools, open source tools with, uh, uh, both intelligent orchestration and Kodiak. And then we talked about delivering the right results, right? So you always see that developer resistance, uh, false positives, what intelligent orchestration does it is able to look at what are some of the vulnerabilities that the development team truly cares about tools are designed to find more, right? So 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. Right. You want to make sure that you look at just the critical and Heizer high-risk issues and then notify them immediately.

00:18:47

So this is one example of GitHub actions where within the code scanning alerts, you configure, what is it that 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, right? Whatever they are using. If they're using Polaris, it goes into the Polaris dashboard. If they are using Coverity Coverity connect black duck, the results go to black duck hub, but then only the ones that they truly care about will they be notified immediately? Right? So the ones that are critical, the ones that are high, where they have a SLA of either seven days or one week or two weeks to fix those defects. Right? So it delivers the right information to the right team and also avoids the fact overload, right? Because again, if you say we have slack, we have Microsoft teams, we need to push those results or notify them immediately.

00:19:55

Then you can do that again. Exactly. Like you saw within your, uh, um, uh, version control, right? Get hub, get lab, big bucket. Or so here, it's saying that I'm going to push those results. I mean, 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. Right? Same thing. Everything is streamlined, right? So whether you're doing static analysis, software, composition, analysis, 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 come completely consistent based on the tool and the technology that they prefer. Right. And then also like, again, we, if you want your developers to be notified, pause, pause the build, or break the build, depending on how mature your development organization is.

00:21:02

Again, it's the same consistency is applied across for the developers and any other teams to be notified. Right? And then you can do a similar thing even within code DX, right? So along with intelligent orchestration and code DX, you're able to prioritize the vulnerabilities that the development team truly cares about. Right? So that's what you're seeing here. 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. So intelligent orchestration now through extensive API APIs that could be X provides is able to top the code DX, get all of that information and push that information to the development teams. Right. And then we also talked about not slowing down the velocity. How does this happen? Very interesting. Right? Why do I have a dishwasher here?

00:22:09

Have you used, uh, the, the latest Bish washers? They are very smart, right? So you have an upper rack, you have a lower rack. You can finally Pune the dishwasher. How deep do you want to scan? How the temporary, 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, right? So if you have just few plates and spoons and glasses to be washed, you fill the upper rack and then press that button, right? So you will not use the same cycle for every type of washing that you need. Similarly with application security, right? So 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? Right.

00:23:08

Whereas if you're a 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. So the dial that you use for application security should match that you're using for your dishwasher, right? When you want, it should be deep dive. When, when there are not much changes, and then you committed a change to a CSS file, why do you even want to run scan? Right. So you have to run the right tools at the right time and with the right depth. And that is what intelligent orchestration does, right? So 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, coaching significance, what are the residual risk in the defect management that they have, and based on your policy, do I need to run a deep dive scan?

00:24:14

Do I need to run manual activities? Do I need, can I skip the activities and run? Right. So that is what intelligent orchestration does. Now, in this case example, you're seeing that there was the coaching significance was very, very low. The open vulnerability score was very, very low. And then so 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. Right? Whereas in this case, the, the, the coaching significance was high. Open vulnerabilities also is high. So it said I'm going to run everything, static analysis, all of the activities. I'm only showing for automated activities, but you can bring in other activities that you have. And then it's also saying, I am going to run manual code review and manual penetration test, right. Because that's what is needed.

00:25:12

So 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 and same thing with security sign off. Lot of organizations we have seen have the security sign-off right. So if they want to be notified when the score is very bad. So here both intelligent orchestration and Kodiaks work together. So intelligent orchestration asks for DX, Hey, I pushed all the results to you. You consumed all the results from each and every tool that Tran what is the final score? Hey, it's F okay. Then I'm going to pause. Right? So that's what it's saying. We found that there is, uh, uh, the greatest bag. And then it's also able to go back and look at open vulnerabilities. How many critical or high again, you decide, how do you want to configure are open and then pause and notify a risk owner.

00:26:17

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. Right? It is able to look at the open vulnerability score. It's look able to look at the grade and then provide that visibility to the risk owner to say, come and sign off. Right? Uh, and then also any time you need to do any manual activities as per your compliance requirements, maybe you have lot of PCI requirements, GDPR requirements, you bring that into intelligent orchestration and it will be able to enforce those requirements compliance requirements that you have, right? So again, that's exactly what I'm showing here. And then you have one dashboard, right? Could be X 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.

00:27:18

How, how much time did the developers stake 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 business unit level, right? So you have all of the information that you need in Kodiak. So, uh, without spending too much time, because this was only half an hour time slot, if you want to truly achieve DevSecOps, it is with intelligent orchestration and could be X, 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 in into my pipeline, this connected security activities, someone performing automated, someone else maintaining all the manual activities. And then you explored still happening out in the world through all of that away, and then bring in the next generation application security with intelligent orchestration and code DX, where you have a, um, a centralized dashboard.

00:28:38

You have API APIs for everything. You run AST tests without slowing down the pipeline. You have automate, 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. And then last but not the 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 chain significance. And then it gives your team whether it's the dev ops team, whether it's the security team with the development team, the flexibility to adapt the solution to their specific development, workflows and toolchain. Um, so there are a lot of insightful reading available on synopsis blog. Please take a look at that. And like I said, if you have any questions, if you have any, um, uh, uh, uh, any parts, please do share on my, uh, LinkedIn or Twitter or my email, and I hope you are enjoying the conference and hope to see you all in 2020 to have a great conference. Thank you and take care. Bye.