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:

  • job title
  • internal team
  • seniority/tenure
  • training that individual has received

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.

Classic DEV Post from Aug 2 '18

Changelog for developers?

Potential way to help teams work together on projects

Pavan Belagatti
A DevOps Enthusiast.

dev.to is where software developers stay in the loop and avoid career stagnation.

Sign up (for free)