An issue I've been running into a lot is that me and colleagues are discussing how to do a certain thing in the field of software development, e.g. security. The team leans towards a certain approach that they think is secure. However, from experience I know this approach is not secure. Now I try to explain that it is in fact not secure, but fail to convince them about it not being secure. Often this is due to disbelief on their side ("if this isn't safe, then how does anyone make anything secure?"). It doesn't help much that the most vocal person in my team is also my senior by a longshot.

At this point, I feel like I only have 2 options (or a combination thereof):

  • Be stubborn and keep trying to explain it isn't secure.
  • 'Co-operate' in implementing the feature, only to immediately show it isn't secure by showing an actual exploit as soon as the security features that are supposed to secure the application are implemented.

I feel like the former option is a good way to get myself hated if I persist for too long, and people are just going to stop taking it seriously after some point. Meanwhile, the latter option feels like an inglorious waste of time, used only out of lack of an alternative.

This persuasion problem also occurs regularly with people other than my current colleagues (and with different subjects), so it is not strictly a 'compatibility issue' between me and them.

General tips to help explain things better or help persuade people are definitely appreciated, but I feel like I'm missing something fundamental here.

  • 8
    When you try to explain yourself, do you show some evidence or source to back up your claims or it's a "Trust me, I know this"
    – DarkCygnus
    Commented Apr 16, 2019 at 17:58
  • 5
    Get them to set up a sandbox system and crack it...
    – Solar Mike
    Commented Apr 16, 2019 at 18:00
  • 3
    Also, as a self-analysis, what tone do you use to explain yourself? Could it be that it may be sounding too arrogant or know-it-all, and thus discourages the listener to believe in you?
    – DarkCygnus
    Commented Apr 16, 2019 at 18:00
  • 4
    When you say it is "not secure", what do you mean by that? Security isn't a binary thing where something can be totally secure or not. It is a matter of dealing with vulnerabilities from threats to the point where you reach an acceptable level of risk (there will always be some risk). Have you tried discussing the vulnerabilities you are concerned about and how they could be exploited?
    – Seth R
    Commented Apr 16, 2019 at 18:15
  • 1
    At a certain point, if your input is consistently not being valued you are probably working somewhere that is not a fit for you. And that is true no matter who is "right". Commented Apr 16, 2019 at 21:44

3 Answers 3


Framing and approach is really important. Remember all those cheesy team building exercises where you had to practice "yes, and...."? It really is an important influence tactic. Make sure you're on the same side of the table, listen to what they're saying, and be persistent. It sounds like what you're dealing with is fairly technical, so consider laying it all out in an email, with links to discussion re: the known exploits or tools that will compromise your project. And be comfortable with losing the argument in the short term; it's still a team effort.

Long term, consider spending some time building your personal brand. Know that every interaction either builds it or doesn't. It sounds like your brand might be a little light on credibility. Focus less on you being right and others being wrong; focus more on providing proactive and ongoing education to your coworkers, never ever make stuff up or even stretch the truth, and always come prepared by educating yourself fully on the issue and anticipating objections or weak points in your argument. And when you're wrong, own up immediately and direct credit where credit is due.

I can say, without bragging, that when I weigh in on a topic, people listen. Part of that is demeanor and seniority and gravitas (which I still struggle with), but most of it is because I'm usually right and I always come prepared, and if I don't know, I keep it to myself until I do know.

  • 1
    I feel the same way in that this really is a communication issue on my end. I try to slowly educate people in this, but I feel like the senior doesn't like too much being schooled by me so I want to figure out some more subtle way of conveying this information that doesn't sound arrogant. Finding external sources to link helps, but often when I find something I feel like it doesn't quite apply exactly to our situation, leaving holes in my argument that I don't know how to fill. Finally, about those team building exercises that I supposed to remember? I never had any...
    – Epicnoob
    Commented Apr 17, 2019 at 16:47

I'm a "show me, don't tell me" kind of guy. If it's not secure then put a proof of concept together showing their method along with a proof of concept showing it breaking.

Years ago I had hired a dev team and gave them explicit instructions on how to handle security. During a code review I saw that they had ignored me and went with a different route. They claimed it was "standard practice" and gave me a list of services they used that had copied their implementation from.

Rather than arguing I set up a meeting for the following day. During that meeting I showed them the usernames and passwords they used to access those services. It was various things like external email accounts, banking passwords, social media, etc. In one case I wasn't able to capture clear text of their username/password but I was able to do a replay attack to log into that site as one of the team members.

They got the point and stopped arguing.

Now, I'm not saying that you're right and they are wrong. But I am saying that if you can prove it then that will go a long way towards swinging people to your way of thinking.

  • 3
    That is exactly what this question is about, I mainly have the problem that it takes me a really long time before I am able to convincingly prove it. I need an implementation first before I am able to prove that things can be circumvented. I am the one responsible for making that said implementation, so it costs me a lot of time to first make an implementation to break.
    – Epicnoob
    Commented Apr 17, 2019 at 16:34

You have two issues here.

  1. You have specific and relevant experience you believe should be considered. Can you explain this using actions and consequences? For example, "At my last job we did A. And then our penetration tester told us we needed to do B, right away, instead. That was an expensive lesson to learn."

  2. You're serving as an agent of change in an area that's changing insanely fast (infosec). People resist change: "How does anybody make anything secure?" is an example of that resistance. How to achieve change?

    • be patient.
    • be clear.
    • use evidence. OWASP is a good reference to start in this particular field. If you can point to a notorious security breach based your present choices, that's even better. "Equifax did the same thing" is a powerful argument, if you can make it. Read Troy Hunt and Brian Krebs.
    • did I mention, be patient?

These people aren't going to smack their foreheads and say "doh! you're right." But they are thinking about what you said.

If you do these things you've done your professional duty. Often people don't "get" infosec until they have to handle a security incident, sad to say.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .