Reporting AppSec risk up to your CISO

For security leaders, building a strong working relationship with your CISO often comes down to your ability to provide clear reports and concise risk summaries. Your reports allow CISOs to perform a vital responsibility of their role: translating highly technical security jargon into actionable recommendations that will reduce risk and improve security maturity across the organization. And in the case of a breach or zero-day event, CISOs may be the bearer of bad news.

Yet the growing complexity, size, and dynamic nature of modern applications are challenging the ability of security teams to gain visibility across their applications and provide meaningful reports on risk to the business, settling instead on focusing on measuring the number of security issues identified and resolved. This reactive approach leaves many visibility gaps and does not help CISOs gauge the progress of their application security program nor does it help identify key areas for improvement.

In order for AppSec teams to properly report prioritized risk up to a CISO, they need a holistic view of their application security landscape, including all the different code-based assets used to build it.  

Increase your overall application security visibility

Visibility is key to making informed decisions around risk and resource allocation. Today, most application security tools center their reports around issues found and resolved, often with built-in, non-holistic prioritization of some sort. While this risk management approach has worked in the past, simple vulnerability scores and issue counts aren’t enough anymore 

It’s important to realize that organizations today can have hundreds of applications and as many development teams, each with their own unique software supply chain. That supply chain is composed of all the tools used to create, build, package, and deploy the application. It’s a complex web of direct and transitive dependencies that can cripple your application if a vulnerability is exploited.

Simply put, proper risk management requires context. Businesses face higher risk from applications that are:

• Actively deployed

• Public facing

• Mission critical

• Contain easily exploitable vulns that give someone control or access to data

• And in the worst case, unknown application (meaning we have zero or only partial visibility into them). Shadow IT is an example of a type of unknown application(s).

While the order or priority of these risk factors may differ from team to team, we can agree that we need access to these types of contextual data to make informed decisions around vulnerability prioritization. And once we have proper risk measurement, the question becomes, “what are we doing to address risk as part of a coordinated program?” instead of simply reacting to every report of a critical issue. 

So when we're talking about visibility, we're talking about two things. First, AppSec teams need a solution that grants them complete visibility into their code base, discovering new assets as they are introduced. Second, the solution needs to contextualize all vulnerabilities discovered within a meaningful risk model that leverages their full asset visibility. CISOs are more effective when AppSec teams delivery broad, contextualized visibility.

How risk is introduced

Understanding the origin of risk helps contextualize and prioritize investment in an AppSec program. An auditor or attacker doesn’t care how an issue got into a production system. If an exploitable issue is available to attackers, then as an AppSec professional, one has to assume somebody is out there trying to take advantage of it. But when you think about managing your AppSec program, how risk is introduced becomes very informative. 

An increase in the number of open issues may be an immediate cause for alarm, but zooming in to understand where trends lie across the following categories paints a clearer picture: 

• Baseline: Baseline issues represent issues identified when code begins being monitored for security issues for the first time. In an ideal world, newly imported code would have no issues, yet we know that’s rarely the case. An increase in baseline issues represents new visibility, evidence of an increase in coverage (more on that below). 

• Preventable: These are issues that developers could have avoided introducing if the business had implemented shift-left tooling and processes in the SDLC. This may include testing in local development, as part of PR workflow, or in the build. But if security gates are not in place or if they are bypassed, risky issues can make their way to production. Significant developer time and energy are then wasted fixing the issues instead of driving more value for the business. The introduction of preventable issues represents a massive opportunity for security teams to invest in tooling and processes where it is needed most.

• Non-preventable: Non-preventable issues arise from newly published vulnerabilities. Your code may not have changed at all, but external factors make the existing code in your stack vulnerable to risk. The announcement of a high risk zero-day vulnerability may reveal dozens or hundreds of new, critical issues that warrant attention.

While none of these categories are any more important than the other from an absolute risk perspective, by categorizing risk into these three buckets, AppSec teams can draw patterns over time, which can be shared upwards with CISOs to help inform behaviors teams should take to strategically improve the AppSec program and ultimately reduce risk.

Measuring your AppSec Program

While visibility is absolutely essential for AppSec teams and risk prioritization, it only tells part of the story. CISOs also want to see information that will help them make strategic decisions about their appsec program. For example, knowing how individual teams are progressing in their goals of security maturity and risk reduction may help a CISO make informed decisions around education and resourcing. 

There are four essential categories security teams should consider when building reports for CISOs and security leaders. This framework helps teams build a holistic picture of their application security program, highlighting areas of success and opportunities for optimization that have clear and actionable next steps.

Exposure

Exposure represents the potential risk to your application surfaces. Included in this view are the open issues that could result in security incidents or breaches. Exposure increases when new issues are introduced into your code, the severity or exploit maturity of vulnerabilities increases, or new vulnerabilities are identified. Exposure is managed or minimized when issues are remediated and assessments occur to determine that the risk is not applicable or acceptable to the business. Exposure can be evaluated for a particular point in time (consider audit use cases) or as a trend over time demonstrating (hopefully) improvement.

Management 

Risk doesn't go away on its own. The most sophisticated and robust scanners can be implemented and tooling can be made available to security and engineering teams, but if action isn't taken on the risk that exists, exposure will grow. Measuring the management of your issues helps to understand how effectively your organization is triaging, evaluating, and remediating the risk that makes it to your applications. 

Understanding which applications see the most consistent and effective activity around fixing or accepting risk can help inform what is going well. This might be a strong relationship with security or an engineering leader enforcing a percentage allocation of sprint time for fixing security issues. Where consistency is lacking or risk remediation is absent, there is a clear opportunity for investment. Different areas of your business may warrant different levels of attention, and you may need to evaluate how they manage risk differently.

Prevention

Prevention represents the success your organization has in stopping issues from making it to your production systems. As noted above, not all issues are preventable. But if the tools you use to secure your SDLC know about a particular vulnerability on a given date, a developer should be able to leverage those tools to identify and remediate the issue before it ever makes it to production. When prevention does not occur, this not only represents an increase in exposure but also a significant waste of developer time.

Coverage

Coverage is one of the most fundamental aspects of security, and your CISO absolutely cares about this. Of all the assets — aka any component, entity, or activity inside the application security environment that requires security controls — that make up your applications, how many of them are being secured and how completely? This may include things like different types of scanning (SCA, SAST, DAST, etc.), the frequency of monitoring, the robustness of controls throughout the SDLC, and more. If you feel great about risk exposure level, your teams' effectiveness in fixing issues, and the success of your prevention efforts but you only have visibility into two-thirds of your applications, are you really in good shape?

Asking the right questions

Leading up to today, Snyk’s reporting has focused on helping organizations identify and prioritize issues based on key metrics such as risk. This tactical approach allows teams to take action quickly to resolve issues that pose the highest threat. With Enterprise Analytics, Snyk customers now also have the strategic support to help measure and grow their AppSec program. 

Cross-group insights

Users have the ability to filter at the Group or Organization level

New with Enterprise Analytics is the ability to view across groups within Snyk. This expanded reporting capability allows users to monitor what’s happening across their entire Snyk implementation, regardless of the Group. By breaking down information by Groups, security leaders can target the teams that need remediation and education efforts most.

Sharing insights with stakeholders

Demonstrating proper risk management is crucial for your investors and business stakeholders. CISOs and security leaders are responsible for reporting on risk KPIs and trends as well as showing how their efforts are addressing existing risk and reducing risk over time.

Thanks to Enterprise Analytics, CISOs can now easily report on risk trends such as exposure, management, prevention, and coverage, and can highlight wins as well as areas of opportunity. For example, when we see a spike in preventable issues, this may be an indication that Snyk best practices have not been fully adopted in certain teams.

Snyk shows a spike in preventable issues in the new reporting feature, Enterprise Analytics.

Here, we see a spike in preventable issues around late November that leveled out by December 3rd. When reporting to the CISO, we can demonstrate how quickly the team was able to:

1. Identify the team who needed additional support adopting Snyk (Financial Org)

2. Provide product training to help the team utilize fix PRs and Snyk automations to reduce preventable vulns, 

3. Ultimately, reduce the spike back to baseline (zero issues) 

Snyk makes it easy to share findings with stakeholders using the Copy URL button on the top-right corner of the app page, or by exporting reports into a formatted PDF or CSV file.

"Adopting Snyk allows Applied Systems to align our security and development goals to deliver more value to our customers.  Snyk accelerates our development process and ensures our engineers have the best information possible to enhance the security of our product portfolio."

— Tanner Randolph, CISO at Applied Systems

Start reporting risk

When reporting risk up to your CISO, you'll need to, 1) have maximum visibility into the security of your applications, 2) understand how and where risks can be introduced, 3) know how to measure your AppSec program's exposure, management, prevention, and coverage, and 4) be able to consolidate that information for executives. To get all that done, you're going to need the right tools.

Enterprise Analytics is the latest in a string of announcements that showcase Snyk’s dedication to providing our customers with world-class visibility and analysis of their application data. Enterprise Analytics is available in beta for any Snyk customer who has the Snyk Enterprise plan. To start using these new analytics capabilities, simply request access from your Snyk representative.

If you’re brand new to Snyk, request a demo with a technical expert to get started.