Our strategy is work in progress, but we will focus heavily on running customer discovery in May.
We are in customer discovery phase, and will define a success metric later on. Our main business goals are:
- Close deals faster (with focused, quicker new business lands), and a reduced average sales cycle
- Attach to a compelling event
- Fill a meaningful gap in the current security tool landscape
- Create incremental and meaningful value for our customers
- Provide a new buyer to land with in target accounts
We are currently running customer discovery to identify critical code security needs of our customers that Sourcegraph is uniquely positioned to solve.
- Read our Customer research plan and interview guide (private)
- View insights collected from interviews (private)
- We are looking for insights! If there’s someone we should be talking to, submit them here
- Meanwhile, we keep track of assumptions here
Our first meaningful insight is about gaps in software supply chain, in particular how security users can answer the following problem statement:
“If you learn that a code pattern in library x version y is vulnerable, how do you determine if you’re actually exposed to it? How do you trace it down to the actual line of code?” Note that here, being exposed to a code pattern means actually calling it and not just importing a dependency.
We are currently validating that need with customers, and iterating on the problem. You can read more in the problem brief.
We are currently exploring and validating the following Jobs To Be Done:
- As a security engineer, determine if the codebase uses a given open source dependency reported in a CVE either as a direct or transitive dependency. Identify if the codebase actually calls a vulnerable function, not just imports a dependency.
- Determine what repositories use it, and trace down the line of code.
- Determine what application/service is impacted by that code, and if it is running in production.
- List out the most used functions from this package.
- As a security engineer, determine the optimal sequence of build/publish/deploy required to remedy the dependency safely in the shortest amount of time, even when the dependency is very deep in the graph.
- Be able to query a dependency graph of what is running. From a customer:
“Ultimately, we want to know: If Log4Shell happened again, what is the optimal sequence of build/publish/deploy actions to perform to universally upgrade safely in the shortest period of time? Since log4j is included (very) indirectly for us, that involves a series of intermediate library publishes to do safely”
- Then takes steps so that it gets fixed:
- Determine who owns this application/service/repository
- Flag it to the owning team and/or automate a fix.
- Keep a traceable record of the fix
- Lastly, as a security engineer lead, produce an SBOM to send to customers or auditors for compliance purposes.
We are also looking at adjacent Jobs To Be Done:
We are currently analyzing our competitive positioning as well as identifying potential partners in this document (private).
The software supply chain is currently top-of-mind for many customers and industry leaders. Attacks have been increasing:
Attacks on the software supply chain surged 650% in a year, according to a late 2021 eport by Sonatype that tracked 12,000 software supply chain attacks over the past year, compared to just 929 in 2019-2020.
and there was an executive order on securing the software supply chain. Recently, “White House officials, The Linux Foundation, OpenSSF and CISOs from 37 private sector companies announced a 10-point open source and software supply chain mobilisation plan and $150 million of funding over two year” (article)