|
|
|
|
|
|
by ac
1199 days ago
|
|
|
First of all, thank you for making and sharing this. I have a few technical questions, if I may. Does Bearer perform data-flow analysis? If so: 1. Is the analysis inter-procedural? 2. Is it sound? (Does it only report findings that it’s absolutely certain in but missing others; or does it report all possible findings even if some of them report false positives) 3. How are sources and sinks of information specified? 4. I see it supports JavaScript and Ruby. Any plans on adding other languages? Is the current analysis implementation amenable to adding support for other languages? 5. What’s the analysis behavior around dynamic language constructs (e.g. eval)? 6. What’s the analysis behavior around missing symbols/dependencies? |
|
|
1. Not yet but we are exploring ways to support that
2. The analysis part is sound. False +ves (mainly) come from limitations with what you can specify in the rule language. We're working on this however.
3. We don't make that distinction in the rules language currently. Sensitive data detection (which is built-in) is effectively treated as a source. But we need to allow rules to specify sources. I don't think the limitation matters to finding issues, but more to how well they are reported (you effectively only get the sinks reported at the moment).
4. We plan to add other languages but are mindful of the balance of depth vs breadth of support. Is there a particular language you'd like to see support for?
5. There is no support for these currently unfortunately.
6. As it's intra-procedural, we take quite a basic approach to these (with some special cases in the engine). In terms of dataflow, we treat unknown function calls as identity functions (assume the output is somehow influenced by all the inputs). Obviously this is not ideal in terms of false +ves, but we need to work on inter-procedural support first to do a good job of this. In terms of type analysis, we will try to infer unknown types locally from field/property access.