markdown guide
 

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 Feb 10

Is Haskell bad for FP?

After reading a few frustrated posts from people trying to learn FP through Has...

Pavan Belagatti profile image
A DevOps Enthusiast.