This examines prerequisites; it's not a comprehensive answer, but outgrew a comment.
It's necessary to define if one wants to evaluate the security of the homomorphic scheme(s) implemented by SEAL, HElib and libScarab; or/and the security of the implementations of such scheme(s) that these libraries provide.
It's necessary to define the legitimate user's goals; the assets to be protected. These can usually be discovered by writing down the use cases.
One must define the threat model: assumed goals and capabilities of adversaries; in particular, exactly what data (including, keys) they can read, write or otherwise alter. If implementation is in scope, what's the level of access they have to the computers running the code and holding the data: can they run code on the same CPU as the implementations? With what accuracy can they time the execution result? What resources can it be expected that the adversary use (computing power, available thru funding or otherwise; that might influence a choice of key size, and some libraries might not be flexible on that)?
Note: some fine-grained security analysis, especially of physical devices, consider the level of expertise/knowledge of adversaries. But that's against Kerckhoffs principle and should be avoided from a pure cryptographic standpoint. Plus, digital attacks can relatively easily be commoditized: script kiddies can mount complex (but generic) attacks.
Credit to Maarten Bodewes for large portions borrowed from his comment.