ASAN builds disable the crash reporter, so ASAN failures are directly indicated only by ASAN's log messages, which mozharness doesn't recognize as errors. The process also exits, but if it's a child process and it fails in this way at a time that doesn't cause a test failure (if the test script is insufficiently strict, or if it's on a shutdown path after the test considers itself finished, or something like that) then the test run will be green on Treeherder/TBPL despite containing evidence of what could be a security issue. I don't know if it would be appropriate to add this kind of thing to the "harness_error" regexp in TinderBoxPrintRe in mozharness/mozilla/testing/errors.py, alongside the regexp alternatives for LSAN messages, or if there's some other place that makes more sense.
Apparently this sort of works? e.g., https://treeherder.mozilla.org/ui/logviewer.html#?job_id=2490777&repo=try flags a line "INFO - SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??", but in that case there was also a test failure. (Maybe bug 1081251 was unintentionally fixed?) Also, that "??:0" looks like something tried to use addr2line, but misparsed the log and supplied an incorrect address (or used a stripped binary, or something like that).