implement more robust incident handling about cwe_checker HOT 4 CLOSED

I have to admit that this is not a pressing matter for us as we are moving away from symbolic execution (in favor of more dataflow analysis) right now anyway. But we will gladly switch to a library interface if you provide one. :-) Until then we should address the incident duplication by smarter parsing on the cwe_checker side.

PS: I will write some Issues for BAP with feature requests the next time i find time for it.

from cwe_checker.

Speaking of the dataflow.... right now, like a second ago, I've just implemented liveness analysis for subroutines (because our Sub.free_vars are still... let's say it straight broken), so I'm thinking now, should I publish it in the interface or not. My decision was ... meh, let's postpone it. But if you guys need liveness right now, I can publish it right now. Your call)

from cwe_checker.

We don't need liveness analysis right now. But it would still be a nice thing to have and could be useful for us in the future.

from cwe_checker.

We have rewritten the incident parsing for the emulation based checks (PR #52 ), so that all incidents pointing to the same target are summarized as one CWE hit (containing all paths found by BAP in the description).

For the time being, this solves the issue on the cwe_checker side. We may revisit the parsing when the current improvements on BAP Primus hit the stable branch.

from cwe_checker.