For further actions, you may consider blocking this person and/or reporting abuse
Read next
Understanding the Differences Between Blue-Green Deployment and Canary Deployment
Joshua Muriki -
High-Performance Storage Solution for Virtual Environment on Xinnor RAID Engine and Kioxia PCIe 5.0 Drives
Sergey Platonov -
How to Manage Kubernetes App Storage Like a Pro 📁
Hamdi KHELIL -
a mock introduction for ReactJS 19!
Kamlesh Gupta -
Top comments (2)
Depending on how big your company is, there's a balance to achieve "least privilege" and trust.
As an example, with Git, you could provide read-only permissions to every member of the software dev team. Once you've done that, then you have to manage who should have write or admin privileges. CI/CD software can have a similar challenge. Everyone should be able to view test plans, but who should be able to change them?
You could delegate permissions by:
The list is longer, but those are a few themes I've seen. Next, you have to ask if the software you are using supports those permission strategies. Can you do permission group nesting? How do you handle offboarding?
Permissions aren't the only concern. You may also have homegrown tools that need audit trails. Is there a unified login system? How are pull request workflows enforced?
It can get a step more complicated with PCI-DSS or a publicly traded company. You may not legally be able to give some folks access, but you CAN tell them why.
I think this is a decent read on the subject, but there's probably more.
Nice perspective. Even I think homegrown tools are more vulnerable to security issues.