I found literally everything I need on github! What a resource! The contracts I looked up are the latest versions of solidity as well. Anything I should potential look for in security risks as far as reentrancy to an escrow goes? Is its as simple as using {ReentrancyGuard}? Any other security risk to an escrow that would need to be looked at before deployment?

Security in solidity mostly consists of watching out for re-entry vulnerabilities and making sure the math assumptions hold true in every possible case. >=0.8.0 helps with the math issues since overflow checking is added to compiled code. You can often avoid having to use a re-entry lock (or guard) by just properly ordering your statements. For example, if there is a function like withdraw(amount), you would first require(amount <= balance[msg.sender], "amount exceeds balance"), then IMMEDIATELY subtract amount from the balance balance[msg.sender] -= amount, and only after this, allow transfers or external calls. If you implement in this order, you wouldn't need a guard (for a relatively simple contract). But there are probably some situations where using a mutex lock is the only safe solution.

reentrancy is (now) easy to spot, i.e. by using static analysis tools such as slither. things get difficult when it involves bugs in typo, logic, or communication between functions.