The CVE data is our DTO object for our CVE class. I’ll just expand this one out as well. Now this class definition we can see contains multiple fields and method definitions. But what’s more interesting here is that from our decomposition, we’ve determined that the CVE class is referencing the vulnerability CVE table.
Take a look at this table. This table contains many column definitions. You can see that the CVE class has many method definitions that reference columns in this particular table. This is well and good for a business analyst who may want to manually click through your decomposition to determine impacts. One question is, how would we do this same walkthrough that I’ve presented here in a cypher query? I have a query pre-prepared for that and I will walk you through this shortly.
Here’s a simple cypher query that basically retrieves the same information, I’m currently saying match all of the paths starting with a given column, out to a depth of five. Now, this column should start with… Should have a name of vulnerability CVE ID and return all of the paths from this query. The result very quickly as you can see, it’s traversed all of the relationships, it’s given me the same information.
The vulnerabilities CVE column has a reference link all the way back to the Crosscode core services JAR that we’ve walked through earlier. Not only this, that the vulnerability CVE column has a reference, link all the way back to its originating database. This type of information, being able to query relationships like this is great for impact analysis, if you want to determine what impacted change to a method will have. Crosscode is able to support this through the use of Neo4j in graph-based databases. One other query I’d like to demonstrate is the one on the previous slide, which brought up the APOC procedures plugin.
This is a relatively simple query. When we take a look at it, what it’s doing here is taking all of the nodes out to objective two from the given job, as we’ve seen before. Collecting them and converting them to a JSON tree. Being able to convert all of the paths to a JSON tree allows you to do comparisons to a JSON structure format. It also allows you to send this information via an API if required. The APOC procedures plugin was very useful for our use case. I have one last query that I’ll go into more detail about, but has version two of Crosscode. Our software now decomposes ServiceNow instances. This is just a basic query to find the incident scripts in a ServiceNow instance. I will let John talk to you more about what this query is actually representing.
So what this allows them to do is to impact analysis on modifications. Especially with the APEC tree traversal, I think we’ll be able to do comparisons between baseline code versus their modifications so they can figure out where they’re modifying things. This is just a powerful start. Thank you, Rob. – [Rob] It should be noted that of the ServiceNow instance itself, there is really a few nodes, just to illustrate a point. The ServiceNow instance, we decomposed, is roughly comprised of 115,000 of the given nodes in this example database. Probably there’s a similar amount of relationship types, with little to no performance impact of the traversals you’ve seen in these queries. I will give it back to Jon to fill out the rest of the presentation.
That concludes the demo of our software. We have a page of references. I highly encourage you to take a look at these. Rob, did you have any comments about… I think, especially the second one, but can you talk about these references? – [Rob] Sure, the second one in particular, more applies to Cross codes use case than graph-based databases themselves. This was a white paper written for a conference detailing the benefits and drawbacks of using a graph-based database for software artifact decomposition. Which is exactly what we’re doing.