Mixing
![Pressured into doing a role I despise [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
Concerned with third party quality of work. Do I say anything?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
9
down vote
favorite
I'm the lead developer of a startup that deals with deliveries and pickups for various companies. One of these partner companies has had a website and API built for them, and with 10 years of development experience I can say that the quality is far, far below par. They sent over the API details and one of the first things I noticed was that the API doesn't use HTTPS, which is an obvious no-no. Having raised it with the "CEO and project manager" of the development firm, I got the following response:
No, right now it's transferring via HTTP not HTTPS. You can hit these URL's via cURL. It will be more secure and fast.
Now, not everyone here will know that this response is ridiculous, but it is, and also outright wrong and dangerous. This is literally the equivalent of your bank telling you that you don't need the green padlock in your browser. We'll be sending our customer details to this API and vice-versa, so this is a massive security hole. Amongst other things that are clearly wrong with their implementation, I have serious concerns about their attitude towards security, the overall storage of the data and how they will maintain and back up this information.
So, what do I do? Our partner who has commissioned this website is valuable to our company, so we don't want to upset them or rock the boat, but on the other hand, their data (and ours!) is being handled improperly and they're not getting a good quality product. My instinct is to contact our partner and expose all the issues that is wrong with the implementation of their new and fancy API and to insist that they get resolved. Is it right for me to get involved in this?
I've discussed this with my boss and he agrees that although we should tread carefully, it is a good opportunity to strengthen our ties with this partner and help them out of what could potentially be a tight spot in the near future when their data goes bye-bye.
Is it right to bring up the bad practices of fellow professionals in your industry to a third-party like this?
software-industry tech-industry
asked May 17 '16 at 11:46
dKen
8222612
 |Â
show 3 more comments
up vote
9
down vote
favorite
I'm the lead developer of a startup that deals with deliveries and pickups for various companies. One of these partner companies has had a website and API built for them, and with 10 years of development experience I can say that the quality is far, far below par. They sent over the API details and one of the first things I noticed was that the API doesn't use HTTPS, which is an obvious no-no. Having raised it with the "CEO and project manager" of the development firm, I got the following response:
No, right now it's transferring via HTTP not HTTPS. You can hit these URL's via cURL. It will be more secure and fast.
Now, not everyone here will know that this response is ridiculous, but it is, and also outright wrong and dangerous. This is literally the equivalent of your bank telling you that you don't need the green padlock in your browser. We'll be sending our customer details to this API and vice-versa, so this is a massive security hole. Amongst other things that are clearly wrong with their implementation, I have serious concerns about their attitude towards security, the overall storage of the data and how they will maintain and back up this information.
So, what do I do? Our partner who has commissioned this website is valuable to our company, so we don't want to upset them or rock the boat, but on the other hand, their data (and ours!) is being handled improperly and they're not getting a good quality product. My instinct is to contact our partner and expose all the issues that is wrong with the implementation of their new and fancy API and to insist that they get resolved. Is it right for me to get involved in this?
I've discussed this with my boss and he agrees that although we should tread carefully, it is a good opportunity to strengthen our ties with this partner and help them out of what could potentially be a tight spot in the near future when their data goes bye-bye.
Is it right to bring up the bad practices of fellow professionals in your industry to a third-party like this?
software-industry tech-industry
asked May 17 '16 at 11:46
dKen
8222612
1
This is part of due diligence. My experience has taught me that if something looks fishy, then I need to dig deeper. Just adding HTTPS doesn't fix any underlying security issues, and in fact, I've just found an even more serious security flaw that makes all the data publicly available to anyone. HTTPS would not have prevented this. Anyway, my question was really about if I should put pressure on the relationship with our partner my highlighting the inadequacies of their developers.
– dKen
May 17 '16 at 12:58
1
FWIW you may also want to peruse security.stackexchange.com and see if there is anything there that is relevant.
– Peter M
May 17 '16 at 13:05
1
One of the security reports I read recently showed third-party vulnerabilities as being a significant factor in the breaches in certain sectors last year. If you choose to try to get it corrected (which I think you should), I would grab a report like the Verizon DBRI (verizonenterprise.com/verizon-insights-lab/dbir/2016) and focus on fixing the security issue, not the quality of the work. Someone at your partner accepted that website work as good enough, so insulting it insults your partner as well.
– ColleenV
May 17 '16 at 13:30
1
@dKen The question you should ask is whether you take the risk of putting your data on the service which you know has problems. Don't "insult" the company. Just state why it doesn't work for you using hard facts. (No HTTPS, known security issues, etc.). Avoid mentioning things like which country the developers come from, or whether you think the code is pretty or not.
– Brandin
May 17 '16 at 15:02
2
@dKen Depending on your country, you may be required by law to protect sensitve customer information, so you may not even have a choice and must reveal these problems to your client about the third-party implementation.
– xxbbcc
May 17 '16 at 22:15
 |Â
show 3 more comments
up vote
9
down vote
favorite
up vote
9
down vote
favorite
I'm the lead developer of a startup that deals with deliveries and pickups for various companies. One of these partner companies has had a website and API built for them, and with 10 years of development experience I can say that the quality is far, far below par. They sent over the API details and one of the first things I noticed was that the API doesn't use HTTPS, which is an obvious no-no. Having raised it with the "CEO and project manager" of the development firm, I got the following response:
No, right now it's transferring via HTTP not HTTPS. You can hit these URL's via cURL. It will be more secure and fast.
Now, not everyone here will know that this response is ridiculous, but it is, and also outright wrong and dangerous. This is literally the equivalent of your bank telling you that you don't need the green padlock in your browser. We'll be sending our customer details to this API and vice-versa, so this is a massive security hole. Amongst other things that are clearly wrong with their implementation, I have serious concerns about their attitude towards security, the overall storage of the data and how they will maintain and back up this information.
So, what do I do? Our partner who has commissioned this website is valuable to our company, so we don't want to upset them or rock the boat, but on the other hand, their data (and ours!) is being handled improperly and they're not getting a good quality product. My instinct is to contact our partner and expose all the issues that is wrong with the implementation of their new and fancy API and to insist that they get resolved. Is it right for me to get involved in this?
I've discussed this with my boss and he agrees that although we should tread carefully, it is a good opportunity to strengthen our ties with this partner and help them out of what could potentially be a tight spot in the near future when their data goes bye-bye.
Is it right to bring up the bad practices of fellow professionals in your industry to a third-party like this?
software-industry tech-industry
asked May 17 '16 at 11:46
dKen
8222612
I'm the lead developer of a startup that deals with deliveries and pickups for various companies. One of these partner companies has had a website and API built for them, and with 10 years of development experience I can say that the quality is far, far below par. They sent over the API details and one of the first things I noticed was that the API doesn't use HTTPS, which is an obvious no-no. Having raised it with the "CEO and project manager" of the development firm, I got the following response:
No, right now it's transferring via HTTP not HTTPS. You can hit these URL's via cURL. It will be more secure and fast.
Now, not everyone here will know that this response is ridiculous, but it is, and also outright wrong and dangerous. This is literally the equivalent of your bank telling you that you don't need the green padlock in your browser. We'll be sending our customer details to this API and vice-versa, so this is a massive security hole. Amongst other things that are clearly wrong with their implementation, I have serious concerns about their attitude towards security, the overall storage of the data and how they will maintain and back up this information.
So, what do I do? Our partner who has commissioned this website is valuable to our company, so we don't want to upset them or rock the boat, but on the other hand, their data (and ours!) is being handled improperly and they're not getting a good quality product. My instinct is to contact our partner and expose all the issues that is wrong with the implementation of their new and fancy API and to insist that they get resolved. Is it right for me to get involved in this?
I've discussed this with my boss and he agrees that although we should tread carefully, it is a good opportunity to strengthen our ties with this partner and help them out of what could potentially be a tight spot in the near future when their data goes bye-bye.
Is it right to bring up the bad practices of fellow professionals in your industry to a third-party like this?
software-industry tech-industry
asked May 17 '16 at 11:46
dKen
8222612
edited May 18 '16 at 8:27
asked May 17 '16 at 11:46
dKen
8222612
asked May 17 '16 at 11:46
dKen
8222612
asked May 17 '16 at 11:46
dKen
8222612
8222612
1
This is part of due diligence. My experience has taught me that if something looks fishy, then I need to dig deeper. Just adding HTTPS doesn't fix any underlying security issues, and in fact, I've just found an even more serious security flaw that makes all the data publicly available to anyone. HTTPS would not have prevented this. Anyway, my question was really about if I should put pressure on the relationship with our partner my highlighting the inadequacies of their developers.
– dKen
May 17 '16 at 12:58
1
FWIW you may also want to peruse security.stackexchange.com and see if there is anything there that is relevant.
– Peter M
May 17 '16 at 13:05
1
One of the security reports I read recently showed third-party vulnerabilities as being a significant factor in the breaches in certain sectors last year. If you choose to try to get it corrected (which I think you should), I would grab a report like the Verizon DBRI (verizonenterprise.com/verizon-insights-lab/dbir/2016) and focus on fixing the security issue, not the quality of the work. Someone at your partner accepted that website work as good enough, so insulting it insults your partner as well.
– ColleenV
May 17 '16 at 13:30
1
@dKen The question you should ask is whether you take the risk of putting your data on the service which you know has problems. Don't "insult" the company. Just state why it doesn't work for you using hard facts. (No HTTPS, known security issues, etc.). Avoid mentioning things like which country the developers come from, or whether you think the code is pretty or not.
– Brandin
May 17 '16 at 15:02
2
@dKen Depending on your country, you may be required by law to protect sensitve customer information, so you may not even have a choice and must reveal these problems to your client about the third-party implementation.
– xxbbcc
May 17 '16 at 22:15
 |Â
show 3 more comments
1
This is part of due diligence. My experience has taught me that if something looks fishy, then I need to dig deeper. Just adding HTTPS doesn't fix any underlying security issues, and in fact, I've just found an even more serious security flaw that makes all the data publicly available to anyone. HTTPS would not have prevented this. Anyway, my question was really about if I should put pressure on the relationship with our partner my highlighting the inadequacies of their developers.
– dKen
May 17 '16 at 12:58
1
FWIW you may also want to peruse security.stackexchange.com and see if there is anything there that is relevant.
– Peter M
May 17 '16 at 13:05
1
One of the security reports I read recently showed third-party vulnerabilities as being a significant factor in the breaches in certain sectors last year. If you choose to try to get it corrected (which I think you should), I would grab a report like the Verizon DBRI (verizonenterprise.com/verizon-insights-lab/dbir/2016) and focus on fixing the security issue, not the quality of the work. Someone at your partner accepted that website work as good enough, so insulting it insults your partner as well.
– ColleenV
May 17 '16 at 13:30
1
@dKen The question you should ask is whether you take the risk of putting your data on the service which you know has problems. Don't "insult" the company. Just state why it doesn't work for you using hard facts. (No HTTPS, known security issues, etc.). Avoid mentioning things like which country the developers come from, or whether you think the code is pretty or not.
– Brandin
May 17 '16 at 15:02
2
@dKen Depending on your country, you may be required by law to protect sensitve customer information, so you may not even have a choice and must reveal these problems to your client about the third-party implementation.
– xxbbcc
May 17 '16 at 22:15
1
1
This is part of due diligence. My experience has taught me that if something looks fishy, then I need to dig deeper. Just adding HTTPS doesn't fix any underlying security issues, and in fact, I've just found an even more serious security flaw that makes all the data publicly available to anyone. HTTPS would not have prevented this. Anyway, my question was really about if I should put pressure on the relationship with our partner my highlighting the inadequacies of their developers.
– dKen
May 17 '16 at 12:58
This is part of due diligence. My experience has taught me that if something looks fishy, then I need to dig deeper. Just adding HTTPS doesn't fix any underlying security issues, and in fact, I've just found an even more serious security flaw that makes all the data publicly available to anyone. HTTPS would not have prevented this. Anyway, my question was really about if I should put pressure on the relationship with our partner my highlighting the inadequacies of their developers.
– dKen
May 17 '16 at 12:58
1
1
FWIW you may also want to peruse security.stackexchange.com and see if there is anything there that is relevant.
– Peter M
May 17 '16 at 13:05
FWIW you may also want to peruse security.stackexchange.com and see if there is anything there that is relevant.
– Peter M
May 17 '16 at 13:05
1
1
One of the security reports I read recently showed third-party vulnerabilities as being a significant factor in the breaches in certain sectors last year. If you choose to try to get it corrected (which I think you should), I would grab a report like the Verizon DBRI (verizonenterprise.com/verizon-insights-lab/dbir/2016) and focus on fixing the security issue, not the quality of the work. Someone at your partner accepted that website work as good enough, so insulting it insults your partner as well.
– ColleenV
May 17 '16 at 13:30
One of the security reports I read recently showed third-party vulnerabilities as being a significant factor in the breaches in certain sectors last year. If you choose to try to get it corrected (which I think you should), I would grab a report like the Verizon DBRI (verizonenterprise.com/verizon-insights-lab/dbir/2016) and focus on fixing the security issue, not the quality of the work. Someone at your partner accepted that website work as good enough, so insulting it insults your partner as well.
– ColleenV
May 17 '16 at 13:30
1
1
@dKen The question you should ask is whether you take the risk of putting your data on the service which you know has problems. Don't "insult" the company. Just state why it doesn't work for you using hard facts. (No HTTPS, known security issues, etc.). Avoid mentioning things like which country the developers come from, or whether you think the code is pretty or not.
– Brandin
May 17 '16 at 15:02
@dKen The question you should ask is whether you take the risk of putting your data on the service which you know has problems. Don't "insult" the company. Just state why it doesn't work for you using hard facts. (No HTTPS, known security issues, etc.). Avoid mentioning things like which country the developers come from, or whether you think the code is pretty or not.
– Brandin
May 17 '16 at 15:02
2
2
@dKen Depending on your country, you may be required by law to protect sensitve customer information, so you may not even have a choice and must reveal these problems to your client about the third-party implementation.
– xxbbcc
May 17 '16 at 22:15
@dKen Depending on your country, you may be required by law to protect sensitve customer information, so you may not even have a choice and must reveal these problems to your client about the third-party implementation.
– xxbbcc
May 17 '16 at 22:15
 |Â
show 3 more comments
3 Answers
3
active
oldest
votes
up vote
14
down vote
accepted
Where the issue concerns the security of data and the public integrity of your partner/client and their clients or users, yes you should absolutely raise these concerns with your partner company. But keep it professional and fact-based. Don't get into any judgemental evaluations of their chosen development partner, just state the facts as you see them and point out the actual security risks.
Give your partners the factual information they need and let them make their own security decisions including, if they see fit, bringing these up with their development partner. It is their responsibility not yours.
Obviously if your company is being expected to pass sensitive data over an unsecured connection, which is not in the best interests of your company or your users/clients, then you are quite within your rights to decline to use the connection until it has been secured.
answered May 17 '16 at 12:00
Marv Mills
4,3831729
In addition I'd say that a part of this factual information would be demonstrating a proof of concept attack on the API showing how vulnerable it actually is. But done in a manner that won't be stepping on anyone's toes. EG Don't hack the details of the CEO of your partner company.
– Peter M
May 17 '16 at 12:46
Personally I think that's over the top, you don't have to physically prove they are vulnerable, the partner site can do their own security testing for that, the issues just need to be raised with them. If they ask for more detailed assistance then so be it. However there are a range of such responses that might be appropriate in this situation depending on the companies and the personalities involved.
– Marv Mills
May 17 '16 at 12:52
1
From what I read the OP has already made the reasonable approach and pointed out the insecurity, to which the partner company either a) Stuck their head in the sand or b) Doesn't have a clue about security. Given that the security appears well and truly broken the OP will need to raise his response to the next level and I think that demonstrating something concrete rather than abstract would be beneficial at this stage.
– Peter M
May 17 '16 at 12:57
1
@MarvMills Yep .. I misread the connection between the companies. But still, going to the partner company with a concrete example won't hurt.
– Peter M
May 17 '16 at 13:06
4
When you send the documentation to your supervisor and/or project manager, use the phrase: "Obviously the potential legal liabilities and damage to our company's reputation would be significant if a breach were to occur and our lack of diligence came to light." You'll be amazed how fast priorities change.
– Wesley Long
May 17 '16 at 22:42
 |Â
show 3 more comments
up vote
5
down vote
Definitely record the problem and mention it to your boss, this is your job as the subject expert. You point out the security issues and what you see as a resolution. Then your boss should take it from there.
Do it in writing and when you compose it, assume that the other side will be reading it, so keep it clean, factual and professional. Do not make judgements like (tripe) in writing. Always leave them a way to resolve it without conflict. Conflict may come later but that's another issue.
You can move forwards from whatever eventuates after that.
answered May 17 '16 at 18:17
Kilisi
94.5k50216376
suggest improvements |Â
up vote
2
down vote
In this case, having that kind of security hole could potentially lead to your company being put out of business due to an actual security breach. If you see something grossly deficient, and you value your position where you're at, speak up! Then document what you've shared (for your own record-keeping. CYA) and move on.
answered May 17 '16 at 16:52
Xavier J
26.3k104797
If you see something grossly deficient, and you value your position where you're at, speak up! This is what the OP has already decided to do. The stated question is, how to do that without rocking the boat
– rath
May 18 '16 at 8:51
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
14
down vote
accepted
Where the issue concerns the security of data and the public integrity of your partner/client and their clients or users, yes you should absolutely raise these concerns with your partner company. But keep it professional and fact-based. Don't get into any judgemental evaluations of their chosen development partner, just state the facts as you see them and point out the actual security risks.
Give your partners the factual information they need and let them make their own security decisions including, if they see fit, bringing these up with their development partner. It is their responsibility not yours.
Obviously if your company is being expected to pass sensitive data over an unsecured connection, which is not in the best interests of your company or your users/clients, then you are quite within your rights to decline to use the connection until it has been secured.
answered May 17 '16 at 12:00
Marv Mills
4,3831729
In addition I'd say that a part of this factual information would be demonstrating a proof of concept attack on the API showing how vulnerable it actually is. But done in a manner that won't be stepping on anyone's toes. EG Don't hack the details of the CEO of your partner company.
– Peter M
May 17 '16 at 12:46
Personally I think that's over the top, you don't have to physically prove they are vulnerable, the partner site can do their own security testing for that, the issues just need to be raised with them. If they ask for more detailed assistance then so be it. However there are a range of such responses that might be appropriate in this situation depending on the companies and the personalities involved.
– Marv Mills
May 17 '16 at 12:52
1
From what I read the OP has already made the reasonable approach and pointed out the insecurity, to which the partner company either a) Stuck their head in the sand or b) Doesn't have a clue about security. Given that the security appears well and truly broken the OP will need to raise his response to the next level and I think that demonstrating something concrete rather than abstract would be beneficial at this stage.
– Peter M
May 17 '16 at 12:57
1
@MarvMills Yep .. I misread the connection between the companies. But still, going to the partner company with a concrete example won't hurt.
– Peter M
May 17 '16 at 13:06
4
When you send the documentation to your supervisor and/or project manager, use the phrase: "Obviously the potential legal liabilities and damage to our company's reputation would be significant if a breach were to occur and our lack of diligence came to light." You'll be amazed how fast priorities change.
– Wesley Long
May 17 '16 at 22:42
 |Â
show 3 more comments
up vote
14
down vote
accepted
Where the issue concerns the security of data and the public integrity of your partner/client and their clients or users, yes you should absolutely raise these concerns with your partner company. But keep it professional and fact-based. Don't get into any judgemental evaluations of their chosen development partner, just state the facts as you see them and point out the actual security risks.
Give your partners the factual information they need and let them make their own security decisions including, if they see fit, bringing these up with their development partner. It is their responsibility not yours.
Obviously if your company is being expected to pass sensitive data over an unsecured connection, which is not in the best interests of your company or your users/clients, then you are quite within your rights to decline to use the connection until it has been secured.
answered May 17 '16 at 12:00
Marv Mills
4,3831729
In addition I'd say that a part of this factual information would be demonstrating a proof of concept attack on the API showing how vulnerable it actually is. But done in a manner that won't be stepping on anyone's toes. EG Don't hack the details of the CEO of your partner company.
– Peter M
May 17 '16 at 12:46
Personally I think that's over the top, you don't have to physically prove they are vulnerable, the partner site can do their own security testing for that, the issues just need to be raised with them. If they ask for more detailed assistance then so be it. However there are a range of such responses that might be appropriate in this situation depending on the companies and the personalities involved.
– Marv Mills
May 17 '16 at 12:52
1
From what I read the OP has already made the reasonable approach and pointed out the insecurity, to which the partner company either a) Stuck their head in the sand or b) Doesn't have a clue about security. Given that the security appears well and truly broken the OP will need to raise his response to the next level and I think that demonstrating something concrete rather than abstract would be beneficial at this stage.
– Peter M
May 17 '16 at 12:57
1
@MarvMills Yep .. I misread the connection between the companies. But still, going to the partner company with a concrete example won't hurt.
– Peter M
May 17 '16 at 13:06
4
When you send the documentation to your supervisor and/or project manager, use the phrase: "Obviously the potential legal liabilities and damage to our company's reputation would be significant if a breach were to occur and our lack of diligence came to light." You'll be amazed how fast priorities change.
– Wesley Long
May 17 '16 at 22:42
 |Â
show 3 more comments
up vote
14
down vote
accepted
up vote
14
down vote
accepted
Where the issue concerns the security of data and the public integrity of your partner/client and their clients or users, yes you should absolutely raise these concerns with your partner company. But keep it professional and fact-based. Don't get into any judgemental evaluations of their chosen development partner, just state the facts as you see them and point out the actual security risks.
Give your partners the factual information they need and let them make their own security decisions including, if they see fit, bringing these up with their development partner. It is their responsibility not yours.
Obviously if your company is being expected to pass sensitive data over an unsecured connection, which is not in the best interests of your company or your users/clients, then you are quite within your rights to decline to use the connection until it has been secured.
answered May 17 '16 at 12:00
Marv Mills
4,3831729
Where the issue concerns the security of data and the public integrity of your partner/client and their clients or users, yes you should absolutely raise these concerns with your partner company. But keep it professional and fact-based. Don't get into any judgemental evaluations of their chosen development partner, just state the facts as you see them and point out the actual security risks.
Give your partners the factual information they need and let them make their own security decisions including, if they see fit, bringing these up with their development partner. It is their responsibility not yours.
Obviously if your company is being expected to pass sensitive data over an unsecured connection, which is not in the best interests of your company or your users/clients, then you are quite within your rights to decline to use the connection until it has been secured.
answered May 17 '16 at 12:00
Marv Mills
4,3831729
edited May 18 '16 at 11:48
answered May 17 '16 at 12:00
Marv Mills
4,3831729
answered May 17 '16 at 12:00
Marv Mills
4,3831729
answered May 17 '16 at 12:00
Marv Mills
4,3831729
4,3831729
In addition I'd say that a part of this factual information would be demonstrating a proof of concept attack on the API showing how vulnerable it actually is. But done in a manner that won't be stepping on anyone's toes. EG Don't hack the details of the CEO of your partner company.
– Peter M
May 17 '16 at 12:46
Personally I think that's over the top, you don't have to physically prove they are vulnerable, the partner site can do their own security testing for that, the issues just need to be raised with them. If they ask for more detailed assistance then so be it. However there are a range of such responses that might be appropriate in this situation depending on the companies and the personalities involved.
– Marv Mills
May 17 '16 at 12:52
1
From what I read the OP has already made the reasonable approach and pointed out the insecurity, to which the partner company either a) Stuck their head in the sand or b) Doesn't have a clue about security. Given that the security appears well and truly broken the OP will need to raise his response to the next level and I think that demonstrating something concrete rather than abstract would be beneficial at this stage.
– Peter M
May 17 '16 at 12:57
1
@MarvMills Yep .. I misread the connection between the companies. But still, going to the partner company with a concrete example won't hurt.
– Peter M
May 17 '16 at 13:06
4
When you send the documentation to your supervisor and/or project manager, use the phrase: "Obviously the potential legal liabilities and damage to our company's reputation would be significant if a breach were to occur and our lack of diligence came to light." You'll be amazed how fast priorities change.
– Wesley Long
May 17 '16 at 22:42
 |Â
show 3 more comments
In addition I'd say that a part of this factual information would be demonstrating a proof of concept attack on the API showing how vulnerable it actually is. But done in a manner that won't be stepping on anyone's toes. EG Don't hack the details of the CEO of your partner company.
– Peter M
May 17 '16 at 12:46
Personally I think that's over the top, you don't have to physically prove they are vulnerable, the partner site can do their own security testing for that, the issues just need to be raised with them. If they ask for more detailed assistance then so be it. However there are a range of such responses that might be appropriate in this situation depending on the companies and the personalities involved.
– Marv Mills
May 17 '16 at 12:52
1
From what I read the OP has already made the reasonable approach and pointed out the insecurity, to which the partner company either a) Stuck their head in the sand or b) Doesn't have a clue about security. Given that the security appears well and truly broken the OP will need to raise his response to the next level and I think that demonstrating something concrete rather than abstract would be beneficial at this stage.
– Peter M
May 17 '16 at 12:57
1
@MarvMills Yep .. I misread the connection between the companies. But still, going to the partner company with a concrete example won't hurt.
– Peter M
May 17 '16 at 13:06
4
When you send the documentation to your supervisor and/or project manager, use the phrase: "Obviously the potential legal liabilities and damage to our company's reputation would be significant if a breach were to occur and our lack of diligence came to light." You'll be amazed how fast priorities change.
– Wesley Long
May 17 '16 at 22:42
In addition I'd say that a part of this factual information would be demonstrating a proof of concept attack on the API showing how vulnerable it actually is. But done in a manner that won't be stepping on anyone's toes. EG Don't hack the details of the CEO of your partner company.
– Peter M
May 17 '16 at 12:46
In addition I'd say that a part of this factual information would be demonstrating a proof of concept attack on the API showing how vulnerable it actually is. But done in a manner that won't be stepping on anyone's toes. EG Don't hack the details of the CEO of your partner company.
– Peter M
May 17 '16 at 12:46
Personally I think that's over the top, you don't have to physically prove they are vulnerable, the partner site can do their own security testing for that, the issues just need to be raised with them. If they ask for more detailed assistance then so be it. However there are a range of such responses that might be appropriate in this situation depending on the companies and the personalities involved.
– Marv Mills
May 17 '16 at 12:52
Personally I think that's over the top, you don't have to physically prove they are vulnerable, the partner site can do their own security testing for that, the issues just need to be raised with them. If they ask for more detailed assistance then so be it. However there are a range of such responses that might be appropriate in this situation depending on the companies and the personalities involved.
– Marv Mills
May 17 '16 at 12:52
1
1
From what I read the OP has already made the reasonable approach and pointed out the insecurity, to which the partner company either a) Stuck their head in the sand or b) Doesn't have a clue about security. Given that the security appears well and truly broken the OP will need to raise his response to the next level and I think that demonstrating something concrete rather than abstract would be beneficial at this stage.
– Peter M
May 17 '16 at 12:57
From what I read the OP has already made the reasonable approach and pointed out the insecurity, to which the partner company either a) Stuck their head in the sand or b) Doesn't have a clue about security. Given that the security appears well and truly broken the OP will need to raise his response to the next level and I think that demonstrating something concrete rather than abstract would be beneficial at this stage.
– Peter M
May 17 '16 at 12:57
1
1
@MarvMills Yep .. I misread the connection between the companies. But still, going to the partner company with a concrete example won't hurt.
– Peter M
May 17 '16 at 13:06
@MarvMills Yep .. I misread the connection between the companies. But still, going to the partner company with a concrete example won't hurt.
– Peter M
May 17 '16 at 13:06
4
4
When you send the documentation to your supervisor and/or project manager, use the phrase: "Obviously the potential legal liabilities and damage to our company's reputation would be significant if a breach were to occur and our lack of diligence came to light." You'll be amazed how fast priorities change.
– Wesley Long
May 17 '16 at 22:42
When you send the documentation to your supervisor and/or project manager, use the phrase: "Obviously the potential legal liabilities and damage to our company's reputation would be significant if a breach were to occur and our lack of diligence came to light." You'll be amazed how fast priorities change.
– Wesley Long
May 17 '16 at 22:42
 |Â
show 3 more comments
up vote
5
down vote
Definitely record the problem and mention it to your boss, this is your job as the subject expert. You point out the security issues and what you see as a resolution. Then your boss should take it from there.
Do it in writing and when you compose it, assume that the other side will be reading it, so keep it clean, factual and professional. Do not make judgements like (tripe) in writing. Always leave them a way to resolve it without conflict. Conflict may come later but that's another issue.
You can move forwards from whatever eventuates after that.
answered May 17 '16 at 18:17
Kilisi
94.5k50216376
suggest improvements |Â
up vote
5
down vote
Definitely record the problem and mention it to your boss, this is your job as the subject expert. You point out the security issues and what you see as a resolution. Then your boss should take it from there.
Do it in writing and when you compose it, assume that the other side will be reading it, so keep it clean, factual and professional. Do not make judgements like (tripe) in writing. Always leave them a way to resolve it without conflict. Conflict may come later but that's another issue.
You can move forwards from whatever eventuates after that.
answered May 17 '16 at 18:17
Kilisi
94.5k50216376
suggest improvements |Â
up vote
5
down vote
up vote
5
down vote
Definitely record the problem and mention it to your boss, this is your job as the subject expert. You point out the security issues and what you see as a resolution. Then your boss should take it from there.
Do it in writing and when you compose it, assume that the other side will be reading it, so keep it clean, factual and professional. Do not make judgements like (tripe) in writing. Always leave them a way to resolve it without conflict. Conflict may come later but that's another issue.
You can move forwards from whatever eventuates after that.
answered May 17 '16 at 18:17
Kilisi
94.5k50216376
Definitely record the problem and mention it to your boss, this is your job as the subject expert. You point out the security issues and what you see as a resolution. Then your boss should take it from there.
Do it in writing and when you compose it, assume that the other side will be reading it, so keep it clean, factual and professional. Do not make judgements like (tripe) in writing. Always leave them a way to resolve it without conflict. Conflict may come later but that's another issue.
You can move forwards from whatever eventuates after that.
answered May 17 '16 at 18:17
Kilisi
94.5k50216376
answered May 17 '16 at 18:17
Kilisi
94.5k50216376
answered May 17 '16 at 18:17
Kilisi
94.5k50216376
answered May 17 '16 at 18:17
Kilisi
94.5k50216376
94.5k50216376
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
In this case, having that kind of security hole could potentially lead to your company being put out of business due to an actual security breach. If you see something grossly deficient, and you value your position where you're at, speak up! Then document what you've shared (for your own record-keeping. CYA) and move on.
answered May 17 '16 at 16:52
Xavier J
26.3k104797
If you see something grossly deficient, and you value your position where you're at, speak up! This is what the OP has already decided to do. The stated question is, how to do that without rocking the boat
– rath
May 18 '16 at 8:51
suggest improvements |Â
up vote
2
down vote
In this case, having that kind of security hole could potentially lead to your company being put out of business due to an actual security breach. If you see something grossly deficient, and you value your position where you're at, speak up! Then document what you've shared (for your own record-keeping. CYA) and move on.
answered May 17 '16 at 16:52
Xavier J
26.3k104797
If you see something grossly deficient, and you value your position where you're at, speak up! This is what the OP has already decided to do. The stated question is, how to do that without rocking the boat
– rath
May 18 '16 at 8:51
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
In this case, having that kind of security hole could potentially lead to your company being put out of business due to an actual security breach. If you see something grossly deficient, and you value your position where you're at, speak up! Then document what you've shared (for your own record-keeping. CYA) and move on.
answered May 17 '16 at 16:52
Xavier J
26.3k104797
In this case, having that kind of security hole could potentially lead to your company being put out of business due to an actual security breach. If you see something grossly deficient, and you value your position where you're at, speak up! Then document what you've shared (for your own record-keeping. CYA) and move on.
answered May 17 '16 at 16:52
Xavier J
26.3k104797
answered May 17 '16 at 16:52
Xavier J
26.3k104797
answered May 17 '16 at 16:52
Xavier J
26.3k104797
answered May 17 '16 at 16:52
Xavier J
26.3k104797
26.3k104797
If you see something grossly deficient, and you value your position where you're at, speak up! This is what the OP has already decided to do. The stated question is, how to do that without rocking the boat
– rath
May 18 '16 at 8:51
suggest improvements |Â
If you see something grossly deficient, and you value your position where you're at, speak up! This is what the OP has already decided to do. The stated question is, how to do that without rocking the boat
– rath
May 18 '16 at 8:51
If you see something grossly deficient, and you value your position where you're at, speak up! This is what the OP has already decided to do. The stated question is, how to do that without rocking the boat
– rath
May 18 '16 at 8:51
If you see something grossly deficient, and you value your position where you're at, speak up! This is what the OP has already decided to do. The stated question is, how to do that without rocking the boat
– rath
May 18 '16 at 8:51
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f67272%2fconcerned-with-third-party-quality-of-work-do-i-say-anything%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
This is part of due diligence. My experience has taught me that if something looks fishy, then I need to dig deeper. Just adding HTTPS doesn't fix any underlying security issues, and in fact, I've just found an even more serious security flaw that makes all the data publicly available to anyone. HTTPS would not have prevented this. Anyway, my question was really about if I should put pressure on the relationship with our partner my highlighting the inadequacies of their developers.
– dKen
May 17 '16 at 12:58
1
FWIW you may also want to peruse security.stackexchange.com and see if there is anything there that is relevant.
– Peter M
May 17 '16 at 13:05
1
One of the security reports I read recently showed third-party vulnerabilities as being a significant factor in the breaches in certain sectors last year. If you choose to try to get it corrected (which I think you should), I would grab a report like the Verizon DBRI (verizonenterprise.com/verizon-insights-lab/dbir/2016) and focus on fixing the security issue, not the quality of the work. Someone at your partner accepted that website work as good enough, so insulting it insults your partner as well.
– ColleenV
May 17 '16 at 13:30
1
@dKen The question you should ask is whether you take the risk of putting your data on the service which you know has problems. Don't "insult" the company. Just state why it doesn't work for you using hard facts. (No HTTPS, known security issues, etc.). Avoid mentioning things like which country the developers come from, or whether you think the code is pretty or not.
– Brandin
May 17 '16 at 15:02
2
@dKen Depending on your country, you may be required by law to protect sensitve customer information, so you may not even have a choice and must reveal these problems to your client about the third-party implementation.
– xxbbcc
May 17 '16 at 22:15