My specific situation is that I am working as tester for a web application project, and after some low level security tests I realized the application has lots of vulnerabilities. I would normally report these as part of my job.

However, one of the lead Developers is "begging" me not to explore further the issue because he fears that the results will change his vacation plans.

How do I deal with a colleague who is asking me to keep issues "secret"?

  • 26
    Is he asking you to keep a secret forever, or perhaps to change the order in which you test things so he can get on a plane the day after tomorrow (for example)? The answers might be different depending on this. Commented May 30, 2012 at 18:02
  • 9
    Are there other developers capable of handling the problems you've found? Since you've implied there is more than lead developer I assume the answer is yes. Under those circumstances, I'd expect that management would task someone else (or multiple other people if there are a number of independently fixable problems) instead of ruining the original author's vacation plans. If this isn't how management would respond, I'd question if it's a place you want to continue working for because it's only a matter of time before they ruin your plans as well. Commented May 30, 2012 at 19:37
  • 12
    "...he fears that the results will change his vacation plans" - the results may change his career plans, if management discovers that he's trying to get you to hide the problem! Commented May 31, 2012 at 2:11
  • 26
    Many years ago, there was a problem in Avionics at GD/FW. The key engineer had previously made plans for vacation, and had cleared the plans and schedule with his management. Now, his immediate supervisor wanted him to postpone his vacation. Knowing he needed upper-management buyin for such a step, he went to the Director of Avionics, Gordon England. Gordon heard him out, looked him straight in the eye, and asked "What would you do if he was in the hospital?" The guy's answer is not known, but nobody at GD/FW EVER raised that subject again. Commented May 31, 2012 at 19:22
  • 8
    @AlbrahimZ I hope you're not a manager and you'll never be, with such attitude to people and their personal priorities
    – user1023
    Commented Jun 1, 2012 at 8:49

11 Answers 11


Saying "no" is a very useful skill in the workplace.

I would simply tell him that it is your responsibility to report such issues, and that this responsibility does not extend to his vacation plans. You can, of course, make that statement as diplomatic as you like, but make it clear that you take your job responsibilities seriously, and you don't intend to shirk them just because it is inconvenient for him.

  • 46
    Saying "no" is a very useful skill in the workplace. Should be in The Workplace FAQ.
    – yannis
    Commented May 30, 2012 at 17:36
  • 37
    @YannisRizos no
    – Rarity
    Commented May 30, 2012 at 18:09
  • You said it nicer than I did
    – HLGEM
    Commented May 30, 2012 at 18:31
  • This holdiay guy could throw the the op under the bus with ease. He could easily blame the op for not doing his job on time. I have seen seen poeple of this type. If he can throw the project under the bus, then he might not hesitate to do it to the op. Commented Aug 10, 2014 at 19:28

If you keep the issues secret and it comes out, your job is at risk. He is asking you to take a risk to protect him from one. This is inherently wrong and unfair of him to put you in such a position and you you should not keep the secret. It is your job to find software issues and you cannot be concerned that reporting them might negatively affect developers. All issues reported might negatively affect developers, particularly the more serious ones. Finding them is the whole reason for your job. Don't compromise your integrity to protecct someone who has no problem at all with throwing you under the bus.

  • You are right this is a potential risk to my Job, how ever I believe that it's the responsibility of every worker in a firm or a project to handle such issues before they are presented to the according manager, What I am trying to find is a " mid cut" to keep the "peace" in the workspace. I know that you cant always make every one happy but there is always a mid section
    – Theo
    Commented May 30, 2012 at 17:34
  • 7
    There is not alawys a middle ground. He asked you to risk your own livlihood to protect him. This isnot a person you want to protect in any way shape or form. YOu found a securioty vuinerability, those are pretty crititcal. He will have to love with the problems he created. If you giove in on this, he willwant to hide everything you find from now on. THis guy is a user (And abuser really, he probably doesn't feel guilty about risking your job for you), don't enable him.
    – HLGEM
    Commented May 30, 2012 at 18:31
  • 3
    @HLGEM He will have to love with the problems he created That's the funniest typo I've seen in a while ;)
    – yannis
    Commented May 30, 2012 at 19:54
  • @YannisRizos, oops!
    – HLGEM
    Commented May 30, 2012 at 19:58

My specific situation is that I am working as tester for a web application project, and after some low level security tests I realized the application has lots of vulnerabilities. I would normally report these as part of my job.

You've already answered your question there. From a job responsibility standpoint this is a clear cut decision, you should go for it, and it's the developers' job to fix any issues you identify.

However, one of the lead Developers is "begging" me not to explore further the issue because he fears that the results will change his vacation plans.

I'm guessing that's part of a casual conversation. Well, it's summertime, and a security audit is a long and painful process, so I completely understand where your colleague is coming from. That said, it's a necessary process, and probably an urgent one, since you've already identified some issues, and the developer did everything but outright admit that there are further issues.

If you doing your job creates friction between the two of you, well, then it's probably time for management to intervene. However, I strongly believe that a team fails as a team, and really don't appreciate the blame game. Before you do anything you really need to be absolutely certain that you aren't overreacting over something that was more of a casual and possibly humorous comment than an actual request for you to postpone / dismiss the security tests.

  • 1
    I would argue there is already friction among them. It is unfair for the developer to request this.
    – Donald
    Commented May 31, 2012 at 16:35

In addition to the other answers saying "no don't do this" (which I 100% agree with), I will also suggest a more diplomatic route (this might be tricky and might not work in all situations), because sometimes (but not always) it's worth the effort:

Assuming that these discoveries were not a part of a formal test plan on a test matrix, give the person who's "begging" you the chance to make it right on their own. You could tell them that you won't be formally reporting the issues until $someDate (that could be after or immediately before their vacation, depending on when dates are and how long they are away and how far away that date is) though if he'd like to report the issue before that, then he can and you won't raise it. At the same time, I'd also suggest sending a message to your supervisor/team lead saying you have found some potential problems but you want a bit more time for testing and you will send a detailed report when ready.

This strategy gives the developer a chance to save some face and report them at a time that might not ruin their plans (and if they've made long-term plans to visit family in a far-away land, it would suck to have those plans ruined, but that's also not really your problem - it's a problem the Developer needs to sort out with management) and also relieves you from the problem of keeping secrets. If the Developer doesn't report by $someDate, you send in your report. If they do report, at least you still get credit for having discovered it first.

I don't know the true nature of these problems. If you feel that these vulnerabilities are currently exploitable by any random attackers and you can demonstrate a proof-of-concept of this (on a TEST machine, not production, without getting in trouble) then you should report it immediately, or make the Developer report it immediately (with your test data as proof - don't let him take your credit).

Think how much trouble you'd be in if it is discovered that you had knowledge about the issue and said nothing.

  • This only works if the OP's job doesn't require him to report before $someDate. Commented May 30, 2012 at 18:31
  • Trouble with this is that it is a security issue. Those are critical and should not be held back for even a short time.
    – HLGEM
    Commented May 30, 2012 at 18:33
  • 3
    Only the OP knows the nature and severity of the problem (is it exploitable in the wild, or only by people on the internal network who have detailed knowledge of the application's architecture?). Only the OP can decide how long to give the Developer to do the right thing, if any time at all. Commented May 30, 2012 at 18:38
  • @HLGEM: it wasn't clear to me from the question whether the app in question was being tested prior to launch, or if it was already live on a website. Commented Jun 6, 2012 at 6:42
  • You're still lying to your employer regardless of intentions or workplace conditions If you don't report the situation as is in the required/expected manner. The best and the worst companies would both react very negatively to you if this was found out. Commented Oct 10, 2012 at 14:35

Explain your role in the life cycle of the issues

Explain to the developer, that it is your job to find these things early as possible and before other people find them.

  • You doing your job well makes the entire development team look good externally.

  • You not doing your job makes everyone look incompetent, and puts all the risk you yourself if anyone finds out you knew about something serious and didn't report it in a timely manner.

If you are looking for a middle ground, then offer a compromise.

Offer a date for the developer to fix this issue before you report it. If they don't get that fixed by that date, then you officially log it as a an issue with your manager and lets the chips fall where they may. Get this exchange in an email conversation so you can CYA appropriately. Do not back down on reporting the issue on the deadline as agreed upon

Practical Anecdote

In a SCRUM environment, many times an embedded tester will find something, tell a developer and it will get fixed before the tester can get around to filing it in an official system. And when they do, the developer can mark resolved and can be retested immediately, and it can get closed quickly with little fanfare.

( personally I would just log the issue, an get back to doing my job, this is the kind of office politics I avoid like the plague! )

  • 4
    I don't agree about the compromise. It is not the tester's job to make compromises with developers. If any compromises should be made, it should be between the developer and his boss. If the tester reports it to his boss, the developer can try to make a compromise with his boss. From your point of view, it might seem like the e-mail will help CYA. From your boss's point of view, that e-mail will only seem like you were going behind his back, should it ever come out.
    – kba
    Commented May 30, 2012 at 23:14
  • @KristianAntonsen see my person note at the end, the OP was looking for a soft solution to the problem, this is about as far as I would stick my neck out.
    – user718
    Commented May 31, 2012 at 13:52
  • 1
    I would simply report it and be done with it. There is really only one outcome that results in the bug being fixed before the vaction plans.
    – Donald
    Commented May 31, 2012 at 16:38

You should make the problems visible as soon as possible!

Your job as a team is to create a product. You have someone that sets priorities on what to focus on so you can deliver the best possible product on date X. The best thing you can do for everyone involved is to make all problems you find with the product known to the person setting the priorities. That way he/she can make the team focus on the most important/critical stuff right away to avoid working nights right before the release. Maybe it's possible to skip that "nice to have feature" instead.

You're not in a position to "delay reporting" or anything like that. You did a good job helping the team by finding a flaw so it can be fixed it before it causes any harm. Now it's time for the right person (the person most informed on the bigger picture) do decide how to handle it.

  • Care to comment on the downvote? Commented May 31, 2012 at 8:46
  • 1
    +1 It's not up to the OP to decide someones workload. Commented May 31, 2012 at 9:22
  • I cannot agree with this more. The fact the developer can or cannot fix the problem before his vaction is not the author's concern. Of course I would argue that his vaction has already been approved so the developer should be allowed to go no matter what.
    – Donald
    Commented May 31, 2012 at 16:38

Firstly, you are not being paid to keep this guy happy. You are being paid to find vulnerabilities, and so there is absolutely no shame in you doing the thing you are paid to do, and it would be dishonest to knowingly underperform in this regard. Let him know that you need to do your job, despite the inconvenience it may cause him.

Secondly, there seems to be an implication that your company puts pressure on people to cancel vacation plans under certain circumstances. Depending on the situation, you should either encourage this guy to talk with management and try to take the vacation anyways, or reprimand him for making plans when the situation obviously wasn't permissive of this.

This guy is possibly devastated, and the last thing he needs is for you to be holier-than-thou about the situation. Make it clear that you won't keep the issue secret, and then show some compassion; try to talk it out with him a little bit to resolve his dilemma. As appropriate, bring the issue to the attention of your manager and/or his. Consider jokingly making a "deal" with the management that you will disclose this vulnerability if they promise not to interrupt vacation plans that are already in place, but don't be too serious about it, and certainly don't actually withhold the information under any circumstances. You are in a unique position that may allow you to help this guy out; think carefully about how you can best aid him without compromising your own work ethic.

  • I cannot agree with this. Production schedules slip and butt up against vaction plans. It would be unethical ( on a professional level ) to not report this as any other problem discovered.
    – Donald
    Commented May 31, 2012 at 16:45
  • 1
    @Ramhound perhaps you missed the part where I said "certainly don't actually withhold the information under any circumstances"? Every workplace is different, and OP will have to determine for himself whether it is appropriate to report this differently than other problems. I am merely suggesting that this particular situation may present a way for OP to help the other guy in an ethical manner.
    – Dan Burton
    Commented May 31, 2012 at 17:50

You know what, I'm going to take this a step further. You tell management about the vulnerability. Period. That's your job and it's a very important one.

Your real dilemma should be whether to tell them he wanted it covered up because that's a seriously messed up set of engineering priorities. After all, how do you know he didn't know about the issue in the first place? If this is the first time he's exhibited such behavior pose your dilemma to him in those terms to give him a reality check.

"You're risking not just my job or your job but everybody's jobs for your vacation plans? Forget keeping the vulnerability a secret. Why shouldn't I tell them we have an engineer whose priorities are so broken they represent an ongoing company liability that threatens all of our livelihoods here?"

But if he's pulled stuff like this before, it's time for management to know before everybody gets hurt. Vacation cancellations can be compensated and plans can get re-made. That's hardly a good reason to put everybody at risk.


Like pretty much everyone else said you really shouldn't hide the situation even for minutes especially because it's your job to test the application... and especially since it is such a serious topic as vulnerabilities. Since your colleague's request is on personal level, what you could do is help them on the same level I guess. If this person is so much worth helping that you considered to put their interests ahead of your employer's maybe you can help them by fixing the vulnerabilities for them on your own time if possible. If you can't or not willing to, the best you can do for the person is to tell them as soon as possible that you are going to report the vulnerabilities, so that they can figure something out and change their plans if they have to. Imagine if you let this slip, what are the chances that the code will get fixed after they get back from the vocation?

That was the ethical(and obvious) part, now the real world answer is just decide for yourself if you are willing to take the blame and gamble your job for the guy (definitely not worth it), consider the chances, no one here knows exactly how things work at your workplace.


It sounds from your question like he is not just asking you to delay your findings until after his vacation, but to 'avoid' finding them altogether. By doing this you are not just putting yourself at risk, but the whole company - including all of your co-workers. Releasing software with security vulnerabilities could damage the company's reputation beyond repair. If this person believes his team's software is not fit for purpose then he needs to stand up and so - not put you in a difficult position.


I would go to your manager or director and say that you feel bad. You're in a really bad situation. You've uncovered this stuff. But you don't want to get X into trouble. But you don't want to work with secrets. I really don't want to get X into trouble, what should I do.

So let management deal with this. That's why they get the big bucks. They are often more likely to take a diplomatic approach, considering the big picture that they care about and how this matter relates to that. In the same way that management often need to let their workers do their thing without micro-management, workers also need to let management do their job in this matter.


You must log in to answer this question.

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