Natasha Gupta

Hi everyone, and thank you for joining us for our presentation today on Find Fast, Fix Fast: Three Ways to Build Developer-Centric Application Security. My name is Natasha Gupta, and I am a senior product marketing manager at Synopsys for integrated application security. I have worked in the cybersecurity and enterprise networking space for almost 10 years now, and I am looking forward to talking to all of you today about approaches and practices around building a developer-centric application security program.

Today we hear a lot about DevSecOps. We hear about the increasing level of responsibility on developers to take on security work. But it is important that we understand the tactics for doing that successfully, and not just throwing tools at it, but throwing the right approach at it.

In order to understand that, we have to see how modern software development has really changed the game when we talk about the scope of business risk. Modern software development has introduced a couple of game changers in how we think about the vulnerability question. Infrastructure vulnerabilities can potentially span maybe hundreds of assets across an organization's IT estate, but software vulnerabilities can equate to thousands of commits made per day for custom-built code.

When we look at the speed at which software is developed, and at technologies around serverless and microservices and quick cycles of refresh in production, it introduces many opportunities for flaws to make it into production-level code. There are also many different components that can make up code through open source or contracted third-party code, and those pieces do not necessarily have consistent security hygiene or consistent practices for testing and verification of whether there are defects or flaws within that code. That is a potential source of risk being introduced into production-level assets.

At the same time, the scale of the problem is large. When you are thinking about thousands of commits made per day, and in the case of some large enterprises, having oversight when software is committed to production perhaps once every second, that is a lot to track, centralize, and manage. That is why it is increasingly relevant to integrate security successfully into your DevOps program.

When we look at why organizations continue to build security into DevOps, a lot of the time it comes back to building a security experience that actually caters to the developer experience. That is a big challenge for a couple of reasons. While a lot of developers understand that there is an increasing spotlight on them taking on security responsibility, and on them being the group responsible for committing a fix and responsible for that remediation, the challenges that exist with integrating security tooling into their day-to-day work exist for a multitude of reasons.

A lot of times these tools do not communicate directly with the feedback systems that developers are using for ticketing and for their day-to-day work to ascertain their most important work. Developers often have to learn multiple interfaces and multiple new tools that are often not well integrated with their existing pipelines. A lot of times there is a security knowledge gap as well: once I have the information, what exactly do I do with it? What is the best fix for me to commit to fix this particular problem that has been highlighted to me?

Those are often the challenges that exist around building security into DevOps, and in particular the complications introduced for developers, who are a key stakeholder in the process of software vulnerability remediation.

In spite of that, organizations have employed various tools at each stage of the software development life cycle to unveil different types of flaws and relevant security data. These can span different types of AST tools, or application security testing tools. At build time, if you are looking for proprietary code issues or open source code issues, you might be employing a SAST tool, or static analysis tool, or a software composition analysis tool to detect those issues at the build level. If you are looking in simulated production conditions, you may be using a dynamic application security testing tool, or a DAST tool, or perhaps a certain level of pen testing.

However you do it, the key to building an application security program for many vendors across the industry today is employing multiple tools. Often we find organizations are using maybe four to six tools across automated and manual testing. And yet, in spite of that consistent level of security investment, we find that security hygiene is still very inconsistent at the CI level. In a study we conducted with Enterprise Strategy Group, almost a third of organizations we surveyed are still pushing production-level code with known vulnerabilities. Why is that so? Almost half of them are releasing software without any testing or security checks at all.

What this tells us is that invested does not mean tested. While there is a lot of security tooling out there, organizations are often not able to make the most of it. It also tells us that the traditional application security model has not really kept pace with the speed of developer velocity. One reason is that a lot of this tooling is not well integrated with existing pipelines, and because redundant additional testing can require a lot of compute that is sometimes not required, it can often break existing pipelines and congest existing pipelines.

The second reason is that because all of this data is gleaned from multiple sources, from automated AST tools to manual reviews, there is a lot of data for developers to sort through. It can be difficult to escalate a single finding based on its criticality and priority, and for developers to have a central place to understand their most critical work, how to remediate or fix it, and where to find all of the relevant information.

In order to build security into DevOps successfully, it is important to employ three approaches that get to the heart of the issues we have identified with where the traditional application security model is broken, and how you can make the most out of your people, resources, and tooling. They boil down to three principles.

The first is being able to secure code as fast as you write it. What this really means is bringing testing, in the most effective way, into the CI level and being able to glean actionable insight from the get-go. The second is being able to run the right testing at the right time, not going through redundant cycles of unnecessary testing where you do not need to, and understanding the conditions for triggering testing. Finally, to make the first two meaningful, you have to be able to filter all of that AppSec noise and focus on the work which matters most. That comes back to having a single place where you can correlate data and start to understand your highest-priority tasks.

Let's talk about the first principle: how do we secure code as fast as we write it? A very important part of doing this effectively is shifting that testing downstream. One tactic that can be very effective is IDE-based testing. Integrated developer environments, or IDEs, are a popular way to quickly develop code and have centralized visibility of your tools and components. Being able to mesh static analysis and software composition analysis within that environment is a very useful way to see your flaws proactively.

There are several benefits of what an IDE-based solution can do for you. First, once you are able within an IDE to see the immediate results of static testing and software composition analysis, you are able to drill down to the line of code in that context, see exactly where your flaws exist, and tackle that from the get-go. You are then able to develop better practices around secure coding, and importantly drill down on the concept of secure code as quality code.

When you are able to know in real time what your open source dependencies are and what those flaws are, you are able to understand the types of security issues to look for and better practices for developing quality code. This is important for improving your software security program over time and avoiding costly post-production fixes.

Importantly, a good IDE-based solution is going to give you guidance on the best quality fixes and best practices around remediating the flaws you found. This tackles one of the issues discussed earlier, the security knowledge gap with development teams. Once you are able to know those flaws in real time and pinpoint the most effective ways of remediating them, you are able to institute broadly a better knowledge of how to do secure coding and what exactly to look for. That is a really important benefit of how an IDE-based solution can work for you and can start to develop a developer-centric view of application security.

Another important part of securing code as fast as you write it is leveraging interactive application security testing, or IAST, and being able to add runtime application security testing into what you are doing. When you are looking at the difference between looking through your manual reviews and the flaws found through static testing and SCA testing, you are finding known vulnerabilities based on what exactly those solutions are highlighting. When you are looking through penetration testing and dynamic testing, you are looking at unknown vulnerabilities. And when you look at IAST in the middle of that spectrum, it is potentially a very powerful technique for understanding what is truly exploitable and relevant in your application.

Integrating IAST into your DevOps is not just testing for components of an application, but also interrelated components of that application. API security is a very important part of that. A good solution can help you map out, in runtime testing and autonomously in the background, the requests, responses, data flow of APIs, and endpoints that you are working with. This allows you to have a comprehensive map of what your application is working with and the potential vulnerabilities within your APIs.

The other piece is being able to centrally track and identify serverless functions. A good IAST solution can eliminate the additional scanning cycle and autonomously test. This is an important piece of not letting your testing solution get in the way of developer work, and of scaling testing across different cloud-based environments that different teams use for software development. That is one part of securing code as fast as you write it: having a good IAST solution.

Now, going up the capability maturity model, we have already defined a certain level of security testing at the CI level. This allows us to have defined data points around known and unknown vulnerabilities, if you have some level of manual testing and are doing automated testing as well with IAST, IDE-based testing, and whatever tools you currently use around AST. But to get to a point where you are managed and optimized, you have to centrally manage that data and consistently orchestrate that playbook across different pipelines, environments, and teams.

The key to doing that is implementing ASOC, application security orchestration and correlation, in order to introduce a consistent model of accountability, transparency, and efficiency. That is the next step in going from a defined application security program to being able to scale it as a framework across teams and across your development organization for good application security visibility.

What exactly is ASOC? ASOC is a term introduced by Gartner, which identified a growing trend in ingesting application security data across manual and automated tools and correlating that data: removing duplicate results, having a consistent measuring tactic for prioritizing results based on business risk, and orchestrating testing across the software development life cycle across many manual and automated tools.

Importantly, what a good ASOC solution enables you to answer are questions like: When was my software tested? What was fixed? What was found? Where is my greatest area of exposure and exploitability? Where is my most vulnerable software? A good ASOC solution helps take your application security approach to the next level and centralize on creating a very streamlined developer experience with your application security tooling.

To understand what that difference looks like, let's take an average day in the life of a developer. Looking at the state of application security testing that you might already be doing, or that we see across organizations that have maturity around defining AST tooling today, a developer checks in code to a repository and then a test of any of the tools is manually triggered. Individual risk assessments are made per tool, there are many different tools often utilized, and a developer often has to individually ascertain which tools to run. In many organizations we talk to, there may be a dedicated full-time employee running a particular tool.

The results are then taken from that tool and placed in varied places, maybe a Slack message or a manual spreadsheet. All of these results are spread across many different places, and it can be difficult to ascertain a central source of where the most critical truth exists. This spurs many questions for a developer, from what type of testing do I need to run, or whether I even need to run a test, to what exactly do I need to fix and what background and context do I need to fix that?

All of these individual questions can lead to a lot of inefficiency and to a basic, uniform complaint we hear across many organizations: it takes me too much time to do security. What we often find is that too much time to do security is often equated to no security, or limited AppSec being enforced.

Now let's look at the ASOC difference. Once code is checked in, you are able to auto-trigger your testing based on set policies that are codified, and that testing is able to automatically select which tool it requires. Then you are able to deduplicate those results across your manual and automated tooling, prioritize them based on business criticality, and centrally forward the important information to developers directly through the reporting and notification tools they are already using. You are able to trade multiple interfaces for one, and add efficiency to how testing orchestration and prioritization of results works.

There are several tactics for making this work with the ASOC approach. One is being able to orchestrate your testing by leveraging policies as code. This enables you to take the guesswork out of decision making by allowing critical parameters to be codified into a security policy: the criticality of the application, the risk to downtime, whether it handles sensitive PII data, what type of testing is needed, what conditions merit triggering testing, the scope of the code change, whether the change is simply a font change in the UI or something more intensive, what tool to use, and the time frame for testing. All of this can be codified in a YAML script or a Python script and centrally integrated through an API call within your pipeline. That can introduce a lot of efficiency in running security testing in line with development processes.

The second part is leveraging correlation to introduce a uniform assessment of risk, to have an organized view of security data across manual and automated tools, and importantly to centrally give feedback from all of this testing to developers directly. One important aspect of a good correlation tool is introducing visibility within security and development teams into what that feedback looks like at the branch level.

For a lot of development teams, one popular way to implement a security fix, or any fix, is to have a production branch and a test branch. A good correlation solution, and especially a comprehensive ASOC solution, gives visibility into risks, fixes, and security results within a given test branch, and tracks activity between a production branch and a test branch and the feedback between security teams and developer teams. That is an important part of how correlation can mesh the developer experience, the security tools you are using, and centralized visibility into security activities for a given software release.

Ultimately, what do all these practices enable you to do? They enable you to build a sustainable model for scaling your application security program. They enable you to improve the quality of your products by enforcing the scalable notion of secure code as quality code, through securing code as fast as you write it with IDE-based testing and with a good IAST solution.

You are able to reduce the friction you encounter in integrating security because you automate decision making by codifying policy and taking the guesswork out of testing, with practices around enforcing a consistent security playbook across teams, pipelines, and environments. Finally, and perhaps the most important takeaway, all of these practices enable you to make the most of your existing security investment. When we look at investment across people, processes, and technology, having a way to centralize transparency and accountability of all your application security tooling, data, processes, and people, with a correlation solution that can help you visualize and orchestrate effectively and transfer knowledge and insight by shifting it downstream, will help you optimize the most of what you have invested in your security program.

Thank you very much for joining us today. I hope this was helpful to all of you. For more information, please check us out at Synopsys.com and check out our blog for insights on developer-centric security and best practices. Thank you very much for your time.