4 ms·

Once upon a time Joern worked with neo4j, which is a tool that I use very often at work for building attack graphs (via Bloodhound). Last time I sat down and re

by px43 5y ago

Once upon a time Joern worked with neo4j, which is a tool that I use very often at work for building attack graphs (via Bloodhound). Last time I sat down and really tried working with Joern, they had moved to some weird custom graph database which kind of killed my motivation to work with it. It seems to have made a lot of progress since then, so I'll try to find some time to get back into it, but I'm really curious if anyone on this thread has any insight to why they made that switch. I have this grand vision of the entire global software supply chain being loaded into a massive distributed database as a CPG style graph, such that with any new software update, anyone can immediately determine any modifications in security properties. People could say that they want to use certain software stack, for a certain use case, in a certain environment, and craft a query that directly informs them of every possible attack path in the proposed system. The great thing about systems like these is that as new bug classes are discovered, you can almost immediately identify every place where that bug class might have a security impact. It could be like a giant Wikipedia where security professionals (and enthusiasts) are contributing new bug classes, finding interesting attack paths, and adding new software components to the graph. Obviously lots of hard problems to solve between here and there, but it could be fun :-)

deleted 5y ago
[deleted]
woodruffw 5y ago
> It seems to have made a lot of progress since then, so I'll try to find some time to get back into it, but I'm really curious if anyone on this thread has any insight to why they made that switch. I've never worked on Joern, but I work on closely related research projects (including a multirepresentational CPG). My wild guess is that they ran into performance issues with traditional DBs: we've had lots of problems getting our backing DB to emit reasonable query plans on our (extremely interconnected) CPG. Our particular use case allows us to "power through" a lot of performance issues, but that might not be acceptable for any given Joern instance. > I have this grand vision of the entire global software supply chain being loaded into a massive distributed database as a CPG style graph, such that with any new software update, anyone can immediately determine any modifications in security properties. You and me both!
pizza 5y ago
Would be awesome if CPG graphs could get plugged into e.g. https://statebox.org/research/ https://statebox.org/research/
BigDataDave 5y ago
I get what you're saying which is why in the past two years (part of my MSc) I've been developing https://github.com/plume-oss/plume https://github.com/plume-oss/plume which exports CPGs with a pluggable graph database backend. The idea is that there is an interface that accepts the DiffGraph objects that build the AST, CFG, etc. and an implementing class would write the graph database specific approach to storing these results. We have one for TinkerGraph, Neo4j, TigerGraph, and Neptune which compared to OverflowDb, the rest are way too slow. We implemented the ODB driver in the same way to avoid bias. It is important to note that Plume runs Scala 2.13/3.1.1 (since this is what ODB and the CPG project use) and Neo4j in-mem was on 2.12 (until Nov 21) so I only measure remote Neo4j. As I've been developing I've approached the ShiftLeft team to assist and we are in the experimenting phase to write up our results with comparing how ODB does on different programs and versus other graph DBs. Currently my first write up is the approach for incremental CPG building and data flow querying and the second being this graph DB comparison. The TLDR of our multi-graph comparison is that remote DBs take way too long due to network overhead of moving data between one machine to the next. Another issue is that other databases use way too much memory and Neo4j/TinkerGraph are the worst offenders here. Simple programs produce multi-million edge graphs with a few hundred thousand nodes which is only "acceptable" in a couple of seconds if you think of a business use-case like analysing a program within a CI/CD pipeline for example. On the other hand, I do see the utility in having the other databases supported if time/memory constraints are not an issue e.g. I have one user of Plume using TinkerGraph backend for certain compatibility Tinker has with other tools and I can imagine Neo4j having similar third-party support. I think OverflowDB is a great database and the query language the team has extended on top of it is really useful and you should definitely give it a shot and/or contribute to it's development further to include other features other than speed/memory efficiency/query capabilities. If there is enough interest from the ideas that Plume has carried across then I'm sure the team may integrate some Plume's capabilities to keep the multi-graph database notion across while maintaining it for the latest changes.

by px43 5y ago

deleted 5y ago

[deleted]

woodruffw 5y ago

> It seems to have made a lot of progress since then, so I'll try to find some time to get back into it, but I'm really curious if anyone on this thread has any insight to why they made that switch. I've never worked on Joern, but I work on closely related research projects (including a multirepresentational CPG). My wild guess is that they ran into performance issues with traditional DBs: we've had lots of problems getting our backing DB to emit reasonable query plans on our (extremely interconnected) CPG. Our particular use case allows us to "power through" a lot of performance issues, but that might not be acceptable for any given Joern instance. > I have this grand vision of the entire global software supply chain being loaded into a massive distributed database as a CPG style graph, such that with any new software update, anyone can immediately determine any modifications in security properties. You and me both!

pizza 5y ago

Would be awesome if CPG graphs could get plugged into e.g. https://statebox.org/research/ https://statebox.org/research/

BigDataDave 5y ago

I get what you're saying which is why in the past two years (part of my MSc) I've been developing https://github.com/plume-oss/plume https://github.com/plume-oss/plume which exports CPGs with a pluggable graph database backend. The idea is that there is an interface that accepts the DiffGraph objects that build the AST, CFG, etc. and an implementing class would write the graph database specific approach to storing these results. We have one for TinkerGraph, Neo4j, TigerGraph, and Neptune which compared to OverflowDb, the rest are way too slow. We implemented the ODB driver in the same way to avoid bias. It is important to note that Plume runs Scala 2.13/3.1.1 (since this is what ODB and the CPG project use) and Neo4j in-mem was on 2.12 (until Nov 21) so I only measure remote Neo4j. As I've been developing I've approached the ShiftLeft team to assist and we are in the experimenting phase to write up our results with comparing how ODB does on different programs and versus other graph DBs. Currently my first write up is the approach for incremental CPG building and data flow querying and the second being this graph DB comparison. The TLDR of our multi-graph comparison is that remote DBs take way too long due to network overhead of moving data between one machine to the next. Another issue is that other databases use way too much memory and Neo4j/TinkerGraph are the worst offenders here. Simple programs produce multi-million edge graphs with a few hundred thousand nodes which is only "acceptable" in a couple of seconds if you think of a business use-case like analysing a program within a CI/CD pipeline for example. On the other hand, I do see the utility in having the other databases supported if time/memory constraints are not an issue e.g. I have one user of Plume using TinkerGraph backend for certain compatibility Tinker has with other tools and I can imagine Neo4j having similar third-party support. I think OverflowDB is a great database and the query language the team has extended on top of it is really useful and you should definitely give it a shot and/or contribute to it's development further to include other features other than speed/memory efficiency/query capabilities. If there is enough interest from the ideas that Plume has carried across then I'm sure the team may integrate some Plume's capabilities to keep the multi-graph database notion across while maintaining it for the latest changes.