Ask HN: Does My Company Think I'm a Cybersecurity Risk?
I work as a quality engineer at a mid-sized firm, where I was recently instructed to remove the repository from my machine and avoid accessing the codebase altogether. Until this point, I had relied on local copies of our repo to run the front-end for testing pull requests and handling bug fixes—bread-and-butter QE tasks like bug classification (logical, UI, etc.), testing scope (where else the code is used), and other typical quality engineering responsibilities. But now, I'm barred from accessing the very tools that make these processes efficient.
I will refrain from passing judgment on the decision itself, but given the project’s architecture, I suspect it is a costly one. Here are some reasons why:
- It severely hampers my ability to debug, troubleshoot, reverse-engineer, scope, reproduce, and isolate issues—essential functions in QE. - Additional layers of communication are now required to manage shared resources, which translates into time wasted asking developers to check things in the codebase. - Given our continuous integration pipeline, testing pull requests will now necessitate either competing for limited resources or sinking thousands of dollars annually into securing my own dedicated testing environment. - Front-end deployments take about 10 minutes; the back-end, 40 minutes. - When our CI pipeline breaks down, there are no backup methods for testing.
Thus, the question arises: why would a company, explicitly aiming to reduce expenses, introduce what seems like an arbitrary increase in operational costs? I don't believe they would, at least not without reason. Below are some additional breadcrumbs that might help in contextualizing this decision. To maintain confidentiality for both myself and the company, I’ve deliberately omitted identifying details, though it would likely be transparent to any colleague who reads this. This is not driven by any malicious intent, nor do I believe anything expressed here is defamatory. On the contrary, my aim is to clarify the situation, assess my understanding, and solicit broader input to better inform my decisions and prepare for possible outcomes. I acknowledge that, by omitting certain specifics, I may risk an incomplete representation of the scenario—but for now, it should suffice to provide enough of a framework for discussion.
{MOVED TO COMMENTS}
The question remains: Why was this decision made? Is it:
A. A misguided perception on my part—this is standard procedure and nothing unusual. B. A decision made by someone lacking technical knowledge. C. An early sign the company is preparing to let me go. D. A precaution because the company perceives me as a cybersecurity risk. E. Some combination of the above. F. Another reason entirely.
Any and all thoughts, suggestions, and comments are welcome and greatly appreciated.
Non-tech managements making decisions impacting upon a tech-focused cost center rarely makes sense to tech folks.
From the details you do provide, I can see how a non-tech person would interpret many of your actions as "concerning".
But the key issue remains: Do you have a technically competent CTO you directly report to? If so, that person should be responsible for resolving your issue. On the other hand, if you have a tech team without a competent technical manager overseeing operations, then things are likely to get screwy from time to time. Misguided attempts at cost saving being just one of many.
Given what you wrote, it's hard to tell one way or another what they think about you personally. Was the code stored on your personal device, or a company-issued one? If it's company-issued, it's probably nothing to worry about, since, if they were to terminate you, they could immediately restrict your access to the codebase.
I view it vastly more likely that this isn't anything personal, it's just a new corporate decision to limit who has access to the code. If someone's job is a bit more complicated, but they can still do their work, while the company is far more protected, that is a good trade-off for lots of folks.
Also, your company "looking to reduce expenses" doesn't mean anything. Every company is. You will hear that, in some form or another, in almost any organization. If they have to increase spend for cybersecurity, they will.
I see your points, and I genuinely hope you're correct—if this is merely a new policy aimed at limiting access to the code, then I can understand the broader motivations behind it. That said, given my concerns about cost and efficiency, the question becomes whether it's worth the effort to try and get leadership to reconsider. From a practical perspective, the restriction makes my job notably more difficult. The Inefficiencies introduced directly translate into lost time, hindering my ability to troubleshoot, test and debug efficiently. Over time, this could affect my productivity, or at least the appearance of it, which in turn could be detrimental when my output is closely scrutinized. The indirect, long-term impact on the product is another rabbit hole entirely.
TL;DR If due to policy changes and my concerns are valid, do I pursue raising my concerns to leadership?
[dead]
{MOVED TO COMMENTS}
1. I’ve been asked to keep my camera on in most meetings. 2. Like many in the tech world, I generally prefer to keep it off. 3. I was pulled aside over concerns that my LinkedIn profile "looked suspicious." 4. Admittedly, my LinkedIn does look suspicious to anyone who doesn’t communicate with me regularly or hasn't met me recently. 5. As with many developers, I place a premium on privacy, and some of my actions to safeguard it might appear suspect. 6. I’m involved in the cybersecurity community, participating in conferences and learning platforms. 7. The individual who asked me to remove the repository is non-technical. 8. The company I work for is not a tech company. 9. My direct supervisors and decision-makers are also non-technical. 10. I maintain strong relationships with technical team members. 11. I’ve had difficulties navigating remote work dynamics with non-technical colleagues. 12. I speak up less than I used to—this could be interpreted as disengagement. 13. In the past, I struggled to make measurable progress or explain setbacks, which hasn’t reflected well on me. 14. I’ve made no secret of the fact that Quality Engineering is not my passion, preferring development work instead—a comment that’s occasionally thrown back at me: "I know you’d rather be doing X, but..." 15. I have fewer than 10 years of experience in the industry and appear quite young. 16. I’ve been with the company for several years. 17. I work remotely. 18. I attempted to explain our CI/CD pipelines, the importance of QE, and why I believe I need access to the repo.
I was once silently accused of industrial espionage, it took me some time to understand the reasons why they laid me off and it's mostly about them not finding me "transparent." They set different traps, and they couldn't find proof of me spying, but I simply didn't align with the behaviour of a trusted employee. Start looking for a new job.
Are same restrictions applied to your quality engineer colleagues? An answer to that question will explain you better.
Good question. No, the same restrictions do not apply to my colleagues, though they are technically part of a different "team"—emphasis on the quotes. The work we do is largely identical. Do you think the disparity in treatment, despite the similarity in roles, suggests that the restriction is less about the actual work being done and more about other, unstated factors specific to my situation?
Do the same policies applied on you apply to other QEs in your org?
Who does a QE like you report to - the same EM as for SWEs or a separate Manager for QE?
At first glance, I'd assume they most likely want to restrict code access only to those who directly make code changes. This is a common hardening tactic after Snowflake's meltdown due to QEs in Ukraine getting hacked, and then moving laterally into customer environments.
[dead]
[dead]