Dangerous developers

Developers often want to make use of shareware to obtain code they would otherwise need to be spending a lot of time developing. The IT Ethics handbook (by By Stephen Northcutt, ISBN 1931836221) states:

Downloading shareware opens an entire box of ethical issues….the programmer and the Information Security Manager should set up a shareware standard in advance. If the Information Security Manager is too stringent, the programmer will have difficulty getting the job at hand done. This will consequently result in an uncooperative relationship between the programmer and the Information Security Manager

True enough that it’s standard practice for developers to download tools and code from numerous shareware libraries. The question I have is the extent to which I need to be bothered about it.

I’m worried about a number of things. Thing number one relates to my recollection of the day a production web site ceased to function. The cause was traced to a shareware component that had been implemented without a thought being given to its 30 day trial period expiry. Oops. I’m also concerned about the somewhat flippant disregard for safety that developers often have as they go blithely surfing the web looking for useful components.

Conversely I don’t want to be accused of standing in the way of short lead times and pressure to deliver. The solution might be to give the developers access to all the resources they need so long as it all remains in a segregated network. Fair enough but then I’m now worried about what’s going onto the production servers once the components are incorporated into the code.

Of course, one could question why a professional development team using enterprise platforms needs to resort to using shareware and free tools anyway. Maybe some-one could let me know?

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

A converse question is why would a professional development team using enterprise platforms need to resort to using proprietary software and tools which they are prevented from maintaining themselves when something fails? :-) Personally I think there should be very little difference between use of purchased software, freeware or open source. (I deliberately don't use the words "commercial software" as all the above can be commercial.) All should meet the same software policy requirements, including:- - do you have a licence to use it? - do you have support appropriate to business criticality? - is documentation appropriate for purpose? - do you do sufficient testing to see it functions as expected? (sometimes easier with open source as you can look inside and do white-box testing too) - have you ensured software lifecycle meets your needs - including development time? (Sometimes harder with open source if there are only a few developers, who might all just get bored and stop development; but easier in worst case as you can contract out the development yourself) - can it be integrated into your environment? (open source can be easier as minor tweaks are more feasible, avoiding complex workrounds) - do you have appropriate source escrow arrangements? (usually trivial with open source) So sometimes open source meets these requirements a little easier, sometimes harder. Much freeware may well be worse, with no source code and no support contract. And as an example of quality software, many leading security tools are open source or freeware.
Why would a professional development team use free/share/open tools? I am talking with an OWASP guy recently that is considering developing an input validation tool for formatted data (phone numbers, credit cards etc) for java. It would probably take a few months to code, and then all the testing you would want to see, then it could be available for the community. It probably doesn't make that much sense for every development team to buy or build such a tool. Sadly, it seems that much of the time finances are the primary driver in the open software, commercial purchased software decision. I know the big financial houses seemed to prefer commercial tools, and with 14% credit card rates they could afford such things. It will be interesting to see if the sub prime fallout leads to more open source in the financials!
Thanks Stephen - I don't disagree with you and the case that you cite is exactly the sort of scenario I come across. The main concern I had was the fact that the development folk in question didn't seem to have any plan or idea of what it was they were looking for. When I asked them what sources they would be getting their code from the answer given was simply "anywhere and everywhere". There are some very good sources for free code and tools, but also lots that probably need some more careful consideration before being utilised...