Security Dependencies Follow-up

Someone asked how dependencies should be handled if you're depending on another team at the same company. As you may well imagine, this is a very common issue here – for example, a bunch of apps we ship use SharePoint as a platform, which in turn uses IIS as a platform, which in turn depends on the OS. The first thing to consider is whether the other team is aware of your needs and agrees to do something. As a trivial example, if I'm using a documented API, read all the comments, then I should be able to depend on it doing what it says.

The next issue is whether the other component can do whatever it says reliably. You're always accountable for your choice of things to build on top of, and if something isn't reliable, then maybe you need to strengthen it, make it redundant, or find something that does meet your needs. For example, IE sorts things out into zones and makes trust decisions on that basis. It isn't a perfect system, but it works well enough for a lot of things. If you needed to do something really high security, maybe requiring some form of server auth would be needed, and just assuming something's in the intranet zone isn't good enough.

What's really key is communicating so that everyone understands what the contract is between the teams. Where this can get to be a problem is when you don't have any alternatives to solve your problem other than asking the team you depend on to make changes – now we're getting into the political layer, and I'm not going to pretend to be an expert there.