I'm a software engineer with experience across the software development lifecycle. My primary interest is software development methodologies and software process improvement.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.