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?
Is it your first job ? If it is, don't worry, it's way worse everywhere else. Sometimes you have committees eating many man-hours, every day, to green light releases with non-technical people having the last word, asking no question, and always, always approving.
When I do a release as a dev, I don't do it myself: someone in another country presses the buttons I ask them to press, type the linux commands I ask them to type, and accept my answer when I say it looks good. Because I am, and all my colleagues are, considered a security risk, and it's better we dictate everything to someone who has no idea what we're releasing, for security reason. We call that segregation in duty, instead of "complete waste of time".
[dead]
If I had to guess:
They think you're a poor performer in your assigned role and it's because you're too interested in the code. They assume you can do the job if they remove the distraction.
Or:
Your manager knows you want to go over to software engineering and if you appear to know and understand the codebase you could be poached to the other team.
Either way it looks like your manager wants you to fit the role you have been given and to stay there. The anxiety about linkedin points to this. You expressed preferences to be doing something else. You're a flight risk and they are trying to limit your options.
Edit in some unsolicited advice:
You don't need to quit over this but you should quit your job if it's not leading you to where you want your career to be, which it obviously isn't. The first 10 years of experience sets you up for your career beyond that and if it's going in a direction you don't enjoy you're going to be miserable in your job. Find a development job if that's where you want your career to go, there is no time to waste.
Thank you gghoop
{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.
Not exactly what you are talking about. But I strongly prefer cameras on during meetings for everyone (unless its some huge meeting, demo, townhall etc). It gives more social feedback, easier to read cues, and makes a more enjoyable process. Its a good default for a company. If its only you then something weird might be going on.
From my experience working in tech over the last few decades it's often been the "difficult" developers who refuse to switch their webcams on during meetings (excluding larger company town hall, demos, etc).
People don't realise quite how much communication is done through body language.
OP - what privacy concerns do you have using a webcam with colleagues? Functionality like blurring backgrounds and having "wallpaper" via software is very good these days.
While it's not explicitly stated, I would like to respectfully disagree with the notion that developers who avoid webcam use in virtual meetings are being "difficult" or impairing communication by omitting visual cues. Although non-verbal signals can enhance interactions, the insistence on webcam use neglects deeper issues of psychological comfort and privacy, which are particularly pertinent for individuals from minority groups or those with lower social status. For some, not displaying their environment might actually level the playing field.
Your point about body language is well-taken, but it’s crucial to recognize that much of human communication is rooted in biological signals that webcams simply cannot capture. These include oscillatory patterns in our nervous systems, pheromones, and pupil dilation—subtle cues that are crucial for face-to-face interactions but are lost in digital communication. If we find ourselves overly concerned about body language in pixelated, compressed, and inherently artificial digital formats, we might need to reconsider if remote work is suitable for us.
Moreover, it’s important to acknowledge that not everyone interprets social cues in the same way. Neurodivergent individuals, for example, may struggle more with deciphering body language, suggesting that the capacity to do so is not universal but rather a privilege.
Have you had a chance to watch We Live in Public? This documentary delves into an early internet experiment where constant surveillance led to significant stress and self-censorship among participants. Though not a direct analogue to virtual meetings, the film highlights the psychological toll of persistent observation—a toll that does not necessarily foster better communication or collaboration.
In my own experience, I've worked with several developers who prefer to keep their cameras off, and I've observed no detrimental impact on the quality of their work or on team dynamics. If you've noticed that developers who disable their cameras tend to be problematic, it might be worth revisiting hiring practices to ensure they align more closely with the diverse preferences and needs of tech talent.
As for my personal preference to keep the camera off, I prefer not to share too many details, but I've included links to several studies that discuss the broader implications of webcam use along with a more recent study about a potential camera alternative, biosignal data.
- https://ieeexplore.ieee.org/document/10599432 - https://psycnet.apa.org/buy/2021-77825-003 - https://tmb.apaopen.org/pub/nonverbal-overload/release/2 - https://www.tandfonline.com/doi/full/10.1080/13678868.2022.2... - https://www.mdpi.com/2673-8104/3/1/10
As an educator the worst times I had were during Covid talking into the void of black squares. I am all for privacy and students should not be forced to show their private spaces, but I guess the seminars suffered due to the lack of feedback.
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.
If you’re willing to elaborate, I’m curious about what they cited as evidence for your supposed lack of transparency?
That's what I meant with "silently accused", they said nothing about it. I noticed my team mates changed their behavior, a manager started bringing things-you-do-wrong, and there were several strange events before they laid me off, like (fictional) products about to be released. Then I was suddendly disconnected and let go. I didn't actually cared and quickly got another job, but ofcourse that was a bad ending and I had to makeup my resume to avoid reference contamination. When I realized the products were fake and did a retrospection of all the events and behaviors, I understood what was all that about.
They knew I have different skills on electronics and hacking. I'm sure they looked for mics and cameras literally everywhere. Once I took care of a stalker that called my wife by hacking a political reporter's email and planting his phone number, so I didn't waste time with the police. Telling stories doesn't help, it's better to hide certain skills.
I'm sorry, that sounds both difficult and disconcerting.
"It's better to hide certain skills."
This perspective hadn't occurred to me, and it's likely a more pragmatic approach than my own, which is to sing my interests from the rooftops and scribble them in chalk, hoping to find other like-minded individuals. A paradoxical approach, driven by the harsh effects of loneliness on well-being, one that might need reconsideration.
They don't trust you. You should go and look for a new job.
Please trace where the cybersecurity requirement comes from. The answer is usually either a contract with a "special" customer whose industry is affected by regulations and who must pass these requirements onto contractors, or the fact that regulations apply to your company directly.
If you can trace it to a particular unusual customer, be vocal about the consequences. If it is due to regulations, sorry, there is nothing you can do. Otherwise, if there is no external reason for the "security" tightening, complain to the person who made this wrong decision and to his manager.
In any case, giving you the tools that are necessary for your work (and by "work", I mean not just being a glorified messenger), like a separate test environment, must be a priority for your manager, even if those tools cost 100000 USD.
Is there anyone in the company that you can just ask these questions of?
Not as a complain but to genuinely ask why these things may have happened and how it is making your job challenging, furthermore how it is also making you feel that you are being siloed.
You aren't going to get a solid answer here, but only from the people you work for.
I appreciate the point about directing these questions to the source, and you are likely right that I'm unlikely to find any concrete answers here. To answer your question, it feels like I did ask why the decision was being made but the response was vague- essentially, I was told to focus on testing. I'm wary of pressing further, as it risks being interpreted as pushback rather than a legitimate concern about efficiency. This would be a non-issue if I were communicating with technical leadership but given the lack of technical understanding from those making the decision, there’s a real possibility that further questions would be dismissed or viewed negatively.
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?
Start looking for a new job.
Oh crap. Placing those restrictions just on yourself is an incredibly bad sign for any kind of ongoing employment there.
It's likely they have some processes working their way through their system(s) now to terminate you. :(
Might be a good idea to contact your own legal counsel, and/or an employment law specialist, (etc) and definitely start heavily looking for employment elsewhere (depending on your savings and personal runway).
[dead]
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]
[dead]