5 ms·

Ask HN: Does My Company Think I'm a Cybersecurity Risk?

23 points by lovatsofa 2y ago

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.

deleted 2y ago
[deleted]
lovatsofa 2y ago
{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.
- readyplayernull 2y ago
  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.
  - lovatsofa 2y ago
    If you’re willing to elaborate, I’m curious about what they cited as evidence for your supposed lack of transparency?

ecshafer 2y ago

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.

atoav 2y ago
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.
comprev 2y ago
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.
- lovatsofa 2y ago
  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://ieeexplore.ieee.org/document/10599432 - https://psycnet.apa.org/buy/2021-77825-003 https://psycnet.apa.org/buy/2021-77825-003 - https://tmb.apaopen.org/pub/nonverbal-overload/release/2 https://tmb.apaopen.org/pub/nonverbal-overload/release/2 - https://www.tandfonline.com/doi/full/10.1080/13678868.2022.2047380#abstract https://www.tandfonline.com/doi/full/10.1080/13678868.2022.2... - https://www.mdpi.com/2673-8104/3/1/10 https://www.mdpi.com/2673-8104/3/1/10
- codingdave 2y ago
  Over the last few decades? So you've been around long enough to remember prior to 5 years ago, when video calls were not the norm, and voice-only conference calls were. We all got by just fine that way, for a long time. I'd say that yes - video gives more info and context. But that additional info is not required for effective communication. And it can really lag people with slower internet connections, which makes it more difficult for the conversations to go smoothly. I'd rather have a lag-free voice conversation any day.

raincom 2y ago

Are same restrictions applied to your quality engineer colleagues? An answer to that question will explain you better.

lovatsofa 2y ago
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?
- cr2032Spoof 2y ago
  [dead]
- alephnerd 2y ago
  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.
- csomar 2y ago
  Start looking for a new job.
- justinclift 2y ago
  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).
  - oxwave 2y ago
    Is the legal council for help with severance negotiations or do you think they might need it for other reasons? I agree with justinclift that it sounds like you're on the chopping block.
    - justinclift 2y ago
      I'm thinking legal council is probably required so they have someone that knows employment law on their side, and can be ready to advise them of their rights (and things to do/avoid). The idea of having them around for help with severance negotiations sounds potentially worthwhile too. That hadn't occurred to me. :)

cowsup 2y ago

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.

lovatsofa 2y ago
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?
- oxwave 2y ago
  [dead]
- xwolfi 2y ago
  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".