The short answer
When a senior developer unilaterally imports an unmaintained open-source repository into a mission-critical system like your payment gateway, they are prioritizing personal convenience over corporate survival. The developer is proud that they saved three days of coding, completely ignoring the fact that they just introduced a massive, unvetted supply chain vulnerability into the company's financial infrastructure. You cannot allow speed to override security governance. As the Engineering Manager, your primary mandate is to protect the structural integrity and legal compliance of the codebase.
An unmaintained GitHub repository is a ticking time bomb. It contains unknown vulnerabilities, hidden malicious code, and restrictive licensing agreements that expose the company to severe legal liability. If you quietly accept this shortcut, you effectively surrender your deployment pipeline to anonymous internet contributors. You must reject this code injection immediately.
Your objective is to enforce the open-source governance framework with absolute rigidity. You will order the developer to rip the unvetted dependency out of the pull request. By mandating rigorous security vulnerability scans and formal architectural review for any external package, you prove that your department prioritizes secure systems over minor scheduling efficiencies. You must establish that security compliance is a non-negotiable prerequisite for engineering velocity.
Why this question is a trap
The trap relies entirely on the developer's seniority and the eternal pressure to ship code faster. The Senior Developer expects you to praise their cleverness for finding a shortcut. They are framing the unmaintained repository as a brilliant hack that accelerated the sprint timeline. They want you to weigh the three days of saved labor against a hypothetical security risk, hoping you will choose the immediate gratification of a faster release.
If you yield to this pressure and allow the dependency to remain, you assume total legal and technical liability for the inevitable disaster. When a malicious actor exploits a zero-day vulnerability in that forgotten repository and skims credit card data from your payment gateway, the company will face catastrophic fines, public humiliation, and massive lawsuits. The Senior Developer will not take the blame. They will point out that you approved the pull request and allowed the code into production. You will be terminated for gross negligence.
Capitulating to this behavior also destroys the discipline of your entire engineering organization. If junior developers see a senior engineer bypassing security protocols to save a few days of work, they will immediately copy the behavior. Your codebase will become a chaotic patchwork of unvetted, abandoned third-party libraries. You must break this dynamic immediately by proving that your security standards apply to everyone, regardless of their title or their perceived coding speed.
What most people say
Most frontline engineering managers panic when confronting a senior developer over code efficiency. They want to maintain a friendly relationship with their top talent, so they try to find a soft compromise. They say something like, "I really appreciate you saving us three days on the sprint, but I am a little worried about using an unmaintained repo in the payment system. Can you just double-check the code yourself to make sure it looks safe, and we will try to replace it with our own code next quarter when we have more time?"
This response is a complete failure of technical leadership. By praising them for saving time, you validate their reckless shortcut. Asking them to double-check the code themselves is functionally useless, as manual reviews cannot reliably detect complex supply chain vulnerabilities or licensing traps. Promising to rewrite it next quarter is a hollow guarantee that the developer knows you will forget. You have surrendered the security of the payment gateway for absolutely zero gain, making yourself an accomplice to the compliance violation.
What to say instead
"I am rejecting this pull request and ordering the immediate removal of that dependency. Injecting an unmaintained third-party repository into our financial infrastructure violates our open-source security compliance and exposes the company to catastrophic supply chain vulnerabilities. You must rewrite the required logic internally or submit a commercial, actively maintained alternative through our automated security vulnerability scanning protocol before this feature moves forward."
This script is a flawless execution of engineering defense and risk mitigation. You open with a direct, uncompromising command. Stating clearly that you are rejecting the pull request and ordering the immediate removal of the dependency stops the deployment instantly. You do not ask for permission to hold the line. You declare the operational reality of the codebase.
You then explicitly diagnose the exact technical and legal damage their shortcut will cause. By citing the violation of open-source security compliance, you raise the conversation from a minor coding dispute to a matter of strict corporate governance. You define the exact risk by naming catastrophic supply chain vulnerabilities. You force the Senior Developer to realize that they are asking you to put the entire corporation in legal and financial jeopardy.
Finally, you deliver the operational path forward. You do not simply leave them blocked. You dictate the exact process required to solve the problem securely. You mandate that they either rewrite the logic internally or find a commercial alternative that passes the automated security vulnerability scanning protocol. You solve the problem by forcing the developer to respect the boundary, leaving absolutely no room for unvetted code to reach production.
The phrase to anchor on
Violates our open-source security compliance.
How to deliver it
Deliver this response with the absolute, unshakable calm of a chief information security officer. Your tone must project complete professional detachment and total command of your infrastructure protocols. Do not sound angry that they took a shortcut, and do not sound intimidated by their senior title. Treat the interaction as a routine enforcement of software physics.
Maintain direct, unwavering eye contact with the Senior Developer. When you mention the catastrophic supply chain vulnerabilities, speak slowly and deliberately. You want the technical and legal weight of that concept to land heavily in the room. When you dictate the requirement for the vulnerability scanning protocol, keep your voice entirely neutral. You are making a literal business routing decision to solve their architectural problem, not delivering a dramatic threat.
Mistakes that cost you the room
The most fatal mistake is offering to manually review the repository yourself to approve it. If you spend your weekend reading thousands of lines of unmaintained third-party code to find vulnerabilities, you prove that you do not understand scalable security governance. Manual reviews miss complex exploits. You must rely on automated scanning tools and strict policy enforcement, not your personal ability to read code faster than a hacker.
Another critical error is debating the actual likelihood of a breach. Do not say that you doubt anyone is trying to hack this specific repo. You will lose a subjective argument about probability with a developer who just wants to merge their code. Anchor entirely on the governance policy and the lack of an active maintainer. The rules apply regardless of the perceived threat level.
Do not apologize for slowing down their sprint velocity. The delay is entirely the fault of the Senior Developer who chose to bypass the established workflow. You must project the attitude that the developer sabotaged their own timeline by breaking the rules. Security is a non-negotiable prerequisite for speed.
Practice plan
First, formalize your department's open-source usage policy in writing today. You cannot enforce a compliance standard if you do not have a documented corporate policy that clearly states the requirements for third-party dependencies. Ensure you have the structural backing to enforce your words when you reject the pull request.
Second, practice the transition from the hard rejection to the mandated internal rewrite. You must sound entirely comfortable telling a highly skilled developer that their work is rejected while smoothly offering the secure solution. Record yourself delivering the script until the cadence sounds effortless and entirely devoid of emotional friction.
Finally, run the drill in the Talk Rightly studio. Focus heavily on keeping your facial expression completely neutral. When a senior developer defends a reckless shortcut, any sign of anxiety or frustration will invite them to argue louder. You must train your body to remain perfectly still under pressure, projecting absolute certainty in your security boundaries.