10 ms·

> If you are an iOS developer, however, a lot can be done to secure your development system:... Separate your development system with your everyday system. Deve

> If you are an iOS developer, however, a lot can be done to secure your development system:... Separate your development system with your everyday system. Development systems should be used solely for development and not for browsing random sites. If physical separation presents too much of a problem for developers, at the very least, a dedicated user account for development should be used. I'm not an application developer, but I haven't seen this recommended before and it sounds a bit extreme. Is it a standard, recommended best practice for development environments that must sign code?

tjohns 11y ago
It's often good practice to have a dedicated build server responsible for producing your release builds and owning the release key. That machine should be kept as secure as possible, along with your source control server. However, isolating machines used solely for development is not common. A leaked development key is typically not very useful. The resulting code is usually not run anywhere other than the developer's own hardware. (A compromised dev machine in this scenario could still be used to push malicious code to source control, which would be bad. So it's still good to keep security in mind. But at least that's potentially detectable compared to a compromised compiler. This is also where mandatory code review prior to commit can be useful.)
zhte415 11y ago
Standard (I've mainly worked with IT in financial companies). But usually implemented not as a physically separate network, but an extremely locked-down one. No USB activated ports (data, mice are OK), instant reporting of unexpected devices, white-listed website access (if lucky) and often no email privileges to email out of the organization. This gets relaxed (apart from USB access) with seniority. I know companies where mobile phones have to be left in lockers on entering/leaving the building, and paper free environments meaning no one unless a bit senior has printing rights. Does this make a difference? Against a malignant party, no. Against careless staff member, yes. Against a lucky/fluky outside actor (in the story link), yes.

tjohns 11y ago

It's often good practice to have a dedicated build server responsible for producing your release builds and owning the release key. That machine should be kept as secure as possible, along with your source control server. However, isolating machines used solely for development is not common. A leaked development key is typically not very useful. The resulting code is usually not run anywhere other than the developer's own hardware. (A compromised dev machine in this scenario could still be used to push malicious code to source control, which would be bad. So it's still good to keep security in mind. But at least that's potentially detectable compared to a compromised compiler. This is also where mandatory code review prior to commit can be useful.)

zhte415 11y ago

Standard (I've mainly worked with IT in financial companies). But usually implemented not as a physically separate network, but an extremely locked-down one. No USB activated ports (data, mice are OK), instant reporting of unexpected devices, white-listed website access (if lucky) and often no email privileges to email out of the organization. This gets relaxed (apart from USB access) with seniority. I know companies where mobile phones have to be left in lockers on entering/leaving the building, and paper free environments meaning no one unless a bit senior has printing rights. Does this make a difference? Against a malignant party, no. Against careless staff member, yes. Against a lucky/fluky outside actor (in the story link), yes.