66

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"?

yannis
  • 5,314
  • 7
  • 41
  • 70
Theo
  • 763
  • 1
  • 5
  • 7
  • 2
    Clarification: Are the security issues identified in new code the developer is working on, or in production code? Because if you're talking about production code, then you are facing a bigger issue (as the tester): How did they escape you in the first place? – yannis May 30 '12 at 17:58
  • 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. – Monica Cellio May 30 '12 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. – Dan Is Fiddling By Firelight May 30 '12 at 19:37
  • 1
    If you haven't worked at your employer long enough to know how management is likely to react, I'd suggest discussing the issue as a hypothetical with another coworker who's been there longer to see if your first coworker is being justifiably paranoid or likely overreacting. – Dan Is Fiddling By Firelight May 30 '12 at 19:39
  • 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! – Steven A. Lowe May 31 '12 at 02:11
  • @YannisRizos The security issues mainly exist in production, You would be right if my job description was white box testing. instead I originally started working for the specific project as a Black Box tester. It was my initiative to upgrade my tests to white box but even now I perform both black and white box tests since the management considers me as a black box tester . So the responsibility still remains in the original Developer. – Theo May 31 '12 at 08:16
  • @MonicaCellio He is not asking me to keep it for ever... just to present my results after September – Theo May 31 '12 at 08:17
  • @DanNelly Ofcourse there are more developers in the project but only 2 ( the Developer in question and one more ) have the required skills to fix this, also the "marketing dept" keeps assigning new projects at them so no one really has the time to work on this. As far as changing working place... I live in Hellas where the unemployment rate is about 23% and rising... so changing working places is a bit hard @ the moment – Theo May 31 '12 at 08:17
  • @StevenALowe That's the problem The last thing I want is to make him lose his job he is the only Developer who "accepts" his bugs with out to much of complains – Theo May 31 '12 at 08:18
  • 2
    What's the deadline for the project? Is this part of a phase of testing? Could you report your finds but suggest that the bugs found can be fixed after his vacation? To me the issue is not whether you can keep your colleague happy but rather keeping the company who PAYS you to test and report those tests. If the bug fixes coincide with his vacation I'm afraid it's just tough. – Carl Winder May 31 '12 at 08:33
  • Also is this project for a customer? If it is, what if the customer finds these bugs out, and pulls their contract? Then you have a much bigger problem than upsetting someones vacation plans. – Carl Winder May 31 '12 at 08:34
  • 2
    If any of the vulnerabilities are exploited? Who is hurt? The users? Is any of their personal information at risk? If so, your coworker is asking you to put his pleasure above their pain. I would not do this. – Ian Dalton May 31 '12 at 04:14
  • Hello Ian and welcome ;) Your answer is essentially re-iterating what almost every earlier answer says, please avoid posting answers that don't add much to the discussion. Or expand your answer to differentiate from the existing answers, if you wish. – yannis May 31 '12 at 04:40
  • 1
    @Theo Please move what information you feel is essential from the comments to the answer, so we can purge them. Long comment threads are generally considered noise, any relevant and valuable information should be in the question itself. – yannis May 31 '12 at 12:41
  • 1
    Well according to me, he doesn't deserve a vacation, especially if he is asking you to hide a problem. That show that he is not suited for his role and doesn't deserve to be the lead Developer. A technical Leader/Head Developer should have learned from his previous experiences that a good vacation is a vacation where you don't leave any work problems behind. Probably for him, his vacation is more important than his work. I don't believe that's a smart way to resolve problems(he is going to have many more in the future if he acts like this). Part of your Job is to report these problems. Well if – AIbrahimZ May 31 '12 at 13:39
  • 1
    @Theo Have you confirmed that your employer can legally cancel your coworkers vacation for something like this? If your labor laws are protective enough the coworker might be panicking over nothing. – Dan Is Fiddling By Firelight May 31 '12 at 18:59
  • 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. – John R. Strohm May 31 '12 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 –  Jun 01 '12 at 08:49
  • The fundamental problem here is not the security failings of the app. Nor is it the fact that the programmer is asking you to hide them (though that's a bad thing). The fundamental problem here is someone in management thinking that there's any valid reason to cancel or postpone someone's vacation. –  Jul 05 '12 at 03:55
  • @Kyralessa - of course there can be valid reasons to cancel a vacation. Losing a major client or failure to comply with a regulatory agency could mean there's no job or company to come back to. –  Oct 10 '12 at 11:45
  • @JeffO, I see more clarity is needed. OK, then: The fundamental problem is running a place in such a way that specific individuals are indispensable, such that they can have vacations cancelled to handle something at work. What if it weren't vacation? What if that person were hit by a bus and killed? What if that person won the lottery and quit tomorrow? It's easy to imagine situations in which the person definitely wouldn't be available. A good workplace will treat vacation as that kind of event. –  Oct 10 '12 at 13:44

11 Answers11

110

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.

Robert Harvey
  • 3,078
  • 2
  • 19
  • 30
  • 46
    Saying "no" is a very useful skill in the workplace. Should be in The Workplace FAQ. – yannis May 30 '12 at 17:36
  • 37
    @YannisRizos no – Rarity May 30 '12 at 18:09
  • You said it nicer than I did – HLGEM May 30 '12 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. – Erran Morad Aug 10 '14 at 19:28
46

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.

HLGEM
  • 142,324
  • 26
  • 258
  • 516
  • 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 May 30 '12 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 May 30 '12 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 May 30 '12 at 19:54
  • @YannisRizos, oops! – HLGEM May 30 '12 at 19:58
23

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.

yannis
  • 5,314
  • 7
  • 41
  • 70
  • 1
    I would argue there is already friction among them. It is unfair for the developer to request this. – Donald May 31 '12 at 16:35
14

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.

FrustratedWithFormsDesigner
  • 12,401
  • 5
  • 50
  • 60
  • This only works if the OP's job doesn't require him to report before $someDate. – Robert Harvey May 30 '12 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 May 30 '12 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. – FrustratedWithFormsDesigner May 30 '12 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. – Carson63000 Jun 06 '12 at 06: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. – Joshua Aslan Smith Oct 10 '12 at 14:35
7

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 May 30 '12 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. –  May 31 '12 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 May 31 '12 at 16:38
6

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.

AndSoYouCode
  • 166
  • 5
  • Care to comment on the downvote? – AndSoYouCode May 31 '12 at 08:46
  • 1
    +1 It's not up to the OP to decide someones workload. – Carl Winder May 31 '12 at 09: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 May 31 '12 at 16:38
5

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.

Dan Burton
  • 466
  • 3
  • 4
  • 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 May 31 '12 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 May 31 '12 at 17:50
1

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.

Erik Reppen
  • 3,268
  • 2
  • 18
  • 17
0

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.

m0s
  • 193
  • 2
  • 6
-1

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.

Paulski73
  • 11
  • 2
-1

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.

gnat
  • 3,068
  • 10
  • 41
  • 77
Michael Durrant
  • 11,266
  • 4
  • 36
  • 60