I'd say talk to someone who is above both of you if you can, and explain your worries, then let the people responsible handle the problem. You should not need to worry about this if it's not you responsibility.

Why are they able to put security at risk? Why is a person catching a lot of these problems?

I'd start with introducing static and dynamic analysis tools into your build pipeline. Some of these - especially the static analysis tools - could be incorporated into your editor or IDE for near-real-time local feedback. If you have IDE integration and build pipeline notification of issues, not only will you be shifting the feedback to a tool that is designed for such a purpose, but shifting at least some of the burden from looking for security vulnerabilities away from people and letting people focus on things that they are better at, like assessing readability and maintainability of changes.

This is also a good way to start a conversation about security being everyone's responsibility and wanting to make it easier for people to see and fix errors earlier. It's a way to open the door to conversations about additional training and tooling to promote building security in without mentioning anyone in particular.

Depending on the nature of the security vulnerabilities being introduced, though, it may be worth having conversations with more senior leaders in the organization. This is especially true if user data is at risk. It's not just technical errors. These are the types of vulnerabilities that can cause serious problems for an organization should they be exploited - beyond harm to customers and users, you could be looking at reputational damage to the organization which translates into financial damage which could have repercussions for employees.

I would say try to write a blog post, run a lunch-and-learn or share a document where you explain the issues and how to solve them first. Don't play the bad guy role. Instead of saying "you're wrong", say "I have found security experts that signal this is a problem. Here's how they recommend fixing it" or something among those lines...

I hope that you work in a culture that allows for open communication. As it's important.

Ask questions. not in a condescending way, but in a leading way.

Present some ways that you think might open the work to malicious intent. Try to make it a collaborative process and not someone sitting in an ivory tower.

Does your org have an infosec team? If so, report the behavior there. That's it, it is infosec's responsibility to draft policy and then enforce it.

There may be different approaches based on the severity of the security problem:

For minor things (e.g. too much information being logged) then look at raising tickets (presuming you have a ticketing system in place) and tag it as a security fix. Multiple tickets might be required to remedy the situation, e.g. one to clean the logs, and another to clean the code that is doing the logging.

More serious matters (such as a security vulnerability which could allow access to a production server, or anything that might feature on the OWASP top 10) then it needs an immediate fix, and this you should take to your security team or a manager. If you're concerned about the more senior colleague, you don't have to mention their name, just highlight the code responsible for the possible issue. Then it's up to your manager to decide what needs to happen, but from experience it is likely to be just further security training.

With all of these problems, see if it's something that can be raised earlier on in code reviews. You should never have to be worried about commenting on pull requests of a more senior developer, as everyone can have valid input. I lead a team myself, and am a senior developer, but I welcome input on pull requests because I know I don't know everything. Try to provide solid examples of why you feel the code might be insecure, either with a small test case of code or a link out to best practices documentation (internal or external).