Code security use case

This page provides a strategic introduction to one of our company use cases. Check that link to find the rest of the use cases and learn how we use them as part of our company strategy.

Overall vision

Sourcegraph is THE security partner that CISOs and security teams use to assess, implement, and verify security patches across their code. They utilize Sourcegraph to derive insights around the vulnerability impact area and monitor dependencies. (Many other tools focus on alerting, but Sourcegraph is used to close the loop.)

Why this is important

Understanding how to mitigate vulnerabilities in information systems is an intimidating challenge for development teams — especially when dealing with less-known weaknesses, unknown vulnerabilities that have not yet been exploited, and vulnerabilities whose manifestation in the codebase has yet to be determined. High-severity vulnerabilities now take nearly 250 days to remediate (Source: Security Intelligence) and this statistic is startling since, for critical security updates, every hour that goes by increases risk dramatically.

Existing tooling doesn’t enable teams to be agile and effective in their response to security vulnerabilities:

Finding the vulnerabilities across scattered codebases takes expensive time and resources
Making changes to many repositories requires spreadsheets and manual labor to track and manage pull requests to completion
Internal library authors need to enable and sometimes force upgrades
The process is cumbersome, unclear, and painful to all involved

The recent Log4j vulnerability is still having a massive impact on developers worldwide. It is a prime example of how challenging it is to create a cohesive response across multiple teams in an org. While Log4j was a widely recorded vulnerability with a lot of available remediation tactics, teams all around the world, in multi-million dollar infrastructure organizations, were left feeling lost and scrambling to implement a fix. Most organizations struggled with searching all of their codebase to determine where the vulnerability existed, how it was being used, and what impact it had on the other code. Even after learning that, they were not empowered to patch it in an effective, timely manner.

In April May FY2023, we ran a 2-month exploratory effort to identify the core painpoints of security teams and security leaders. We focused on the software supply chain. Here are the key findings:

Supply chain attacks are increasing, as well as regulatory pressure on emitting a software bill of material (SBOM). It’s likely that emitting an SBOM will rapidly be commoditized, however no player today is providing a complete solution to explore, visualise, and extract actionable insights from the SBOM.
Code security scanners create a low signal to noise/ratio, increasing the load on security and development teams. This leads to alert fatigue, and sometimes to the erosion of trust between security and development teams. Companies are taking this on: for example, semgrep recently launched a SCA scanner to find reachable vulnerable dependencies, highlighting noise reduction is the key benefit. From their announcement:

Let’s be honest: those of us that use a Software Composition Analysis (SCA) tool are already ignoring > 90% of its alerts.
When analyzing the maturity of security teams, there are three main stages:
- The most mature companies have automated processes, where 99% of issues are handed off directly to development teams, who then resolve it under a standard SLA. Internal tooling allows to track dependencies, priority, and SLAs to resolution. Security teams focus on supporting that process, tooling, and on the 1% most critical CVEs (eg.log4j). The next step for those teams is to rationalize tooling (including replacing internal tools by commercially supported tools), optimize triage and automate remediation (fixing simple, widespread issues without involving engineering).
- The bulk of companies have scanners in place, but are struggling to handle the load of alerts. Their next step is to make triaging more efficient, and put in place workflows to more efficiently hand-off issues to engineering.
- The late-adopters don’t have scanners yet. Their next step is to get a scanner.

We developed a vision of how Sourcegraph could position itself in the software supply chain space, and accelerate triage and remediation. See explore, understand & secure the software supply chain (private) and PD 35 WIP - Dependency Graph for code security.

Sourcegraph today is building two building blocks that will be key in achieving that vision:

dependency search
code ownership

As we iterate on these features, we need to keep code security users and the dependency graph vision in mind.

How we solve this today

The following are real, anonymized quotes from customers today on how we’re already helping them with this use case:

“Sourcegraph has also become essential to how the security team can quickly address security risks and root-cause incidents”.
“When a potential security issue comes up, I often have to go into another engineer’s project to quickly understand how the code works to understand the critical functions, where the data is flowing, what sort of controls or checks are happening. With Sourcegraph, I can jump into another engineer’s project and quickly explore and better understand the code faster”
Using Sourcegraph, the team is fixing vulnerabilities in hours (vs. weeks)
Sourcegraph guided users through Log4j vulnerability remediation “I can’t imagine the pain of having to do this without Sourcegraph” more in this blog post

Who benefits

Developer:

Find, fix, and track affected / vulnerable code

Engineering Leader

Access Code Insights and set up Code Monitoring alerts to be notified when risky patterns, secrets, or other known vulnerabilities are introduced into the codebase

Dev Productivity Lead

Increased productivity, lower time to remediation

Features that enable this use case

Additional resources

Log4j search notebook

As part of our log4j mitigation efforts, we used a Search Notebook to demonstrate how to use Sourcegraph to solve this use case. You can see that here.