This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough posts to write. Email sloan@dev.to if you'd like to leave an anonymous comment or if you want to ask your own anonymous question.
How do I flag a coworker who doesn’t have good security practices to management in a way that doesn’t get them fired? I’ve mentioned this to them directly before and I still see them putting our security at risk on a regular basis (poor logging practices, insecure storage, etc). It's wild to me that they don't see the way they handle security as an issue, but they're a more senior team member than me, and I don't know how to go about it without reaping my own consequences.
Top comments (6)
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'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.
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...
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).
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.