4 ms·

Having developers deploy the code to production is a security concern. You need permissions separated to ensure they do not sneak extra code into production aft

Having developers deploy the code to production is a security concern. You need permissions separated to ensure they do not sneak extra code into production after QA does their part. Our SOX audit was adamant about us changing this.

oldmanhorton 3y ago
Is this sarcasm? What's stopping whoever does have the permissions from "sneaking code into production?" This seems like something pretty easily addressed by a combination of code signing and time-gated permissions. A small dev team may not have the time or energy to stand those systems up, but a blanket statement that it's a security concern seems like a bit much.
- klooney 3y ago
  SOC II and other audits tend to come with the same baggage- they want strict roles and separation of duties between operations and engineering.
- bob1029 3y ago
  > What's stopping whoever does have the permissions from "sneaking code into production?" In our arrangement, the ability to push code to production is gated by the GitHub/Azure integration path. The QA or project person who is rotating the production deployment slots (azure functions) is not granted access in GitHub to deploy to those same functions. So, the developers pushing code and those deploying code are mutually exclusive groups. You could still defeat this with collaboration between employees or screwing with AAD records, but that's why we have a ton of audit logging turned on too.
- isbvhodnvemrwvn 3y ago
  Having worked at companies like that - usually utter incompetence of 'release engineers'.
lolinder 3y ago
On the flip side, giving more people permissions increases the surface area for a social engineering or disgruntled employee attack. If your solution to sneaking code in is to delegate deployment to another team, now you have two teams that could sneak code in—one has to be sneaky and get around QA (not hard at most places), the other can just put the code in before deployment. Making the organization bigger isn't a great solution for lack of trust, it tends to exacerbate it.
idkyall 3y ago
Developer credentials should not be able to deploy to production, only CICD system credentials should. Absolutely, you need proper controls in the system to control and authorize deployments with appropriate responsibilities in place, but fundamentally if your deployments are fully hands-off, it shouldn't matter who clicks the 'deploy' button

oldmanhorton 3y ago

Is this sarcasm? What's stopping whoever does have the permissions from "sneaking code into production?" This seems like something pretty easily addressed by a combination of code signing and time-gated permissions. A small dev team may not have the time or energy to stand those systems up, but a blanket statement that it's a security concern seems like a bit much.

klooney 3y ago
SOC II and other audits tend to come with the same baggage- they want strict roles and separation of duties between operations and engineering.
bob1029 3y ago
> What's stopping whoever does have the permissions from "sneaking code into production?" In our arrangement, the ability to push code to production is gated by the GitHub/Azure integration path. The QA or project person who is rotating the production deployment slots (azure functions) is not granted access in GitHub to deploy to those same functions. So, the developers pushing code and those deploying code are mutually exclusive groups. You could still defeat this with collaboration between employees or screwing with AAD records, but that's why we have a ton of audit logging turned on too.
isbvhodnvemrwvn 3y ago
Having worked at companies like that - usually utter incompetence of 'release engineers'.

lolinder 3y ago

On the flip side, giving more people permissions increases the surface area for a social engineering or disgruntled employee attack. If your solution to sneaking code in is to delegate deployment to another team, now you have two teams that could sneak code in—one has to be sneaky and get around QA (not hard at most places), the other can just put the code in before deployment. Making the organization bigger isn't a great solution for lack of trust, it tends to exacerbate it.

idkyall 3y ago

Developer credentials should not be able to deploy to production, only CICD system credentials should. Absolutely, you need proper controls in the system to control and authorize deployments with appropriate responsibilities in place, but fundamentally if your deployments are fully hands-off, it shouldn't matter who clicks the 'deploy' button