Start by reading the RM, focusing on general overview and FLASH chapters, and try to understand the built-in mechanisms protecting against code readout. Understand, why are there multiple options, what are the tradeoffs and especially why are they made. Look at the evolution of these mechanisms across STM32 families ('G0/'G4/'L5/'U5 are newer and missing from there; there are also the wireless families which may have thier own bunch of issues in this regard).
Then look up known vulnerabilities, perhaps starting at the CVE database.
Note, that these are no dedicated security chips, and security against code readout is relatively low. You cannot do anything better to prevent the usual attacker with physical access (i.e. "the far-eastern guy who promises to extract firmware if you send him a couple of samples and some $$$"), without changing the chip itself. What you can then do is systems solution, i.e. encapsulation, tamper protection and tamper-evidence recording. That's something which can be investigated on a given device, too. There are some basic works out there, try to look around the cambridge uni security lab and their publications. There may be more there, I am not that interested.
Code readout is not the only security issue, there are broader issues related to security of data transmission (i.e. "what are ramifications of implementing xyz protocol on STM32"), handling of keys and similar "secrets", etc.
JW
