The short answer is “As safe as you need them to be”. Web based issue tracking systems replaced proprietary and ‘server centric’ issue tracking tools in the late 1990s and early 2000s because they provided greater convenience. It was possible to have users report their issues through web based forms rather than call a technician and explain over the phone, then have the tech enter things into a proprietary database.This resulted in more technician time being used to manage issues and less time spent on record keeping, and has been a boon to development shops the world over ever sense. However, one of the chief concerns people have before making the switch is one of security.Part of this question stems from a very odd aspect of business – the need to treat every kind of data about their product as proprietary or secret. As the old chestnut goes, having an issue tracking database that’s on the web means that your competitors can use it to steal your customers away. Or, when software is in development, it’s possible for source code to be smuggled out through a web based bug tracking tool.Interestingly enough, when exposed as such, a lot of these concerns evaporate when compared to the increased customer responsiveness that an open architecture creates. Once businesses realize that it’s the customer’s experience after the sale that they’re selling, not the contents of a shrink wrapped box, this attitude tends to evaporate.All that said, security issues are important – you will want user authentication on whatever web based issues tracking system you implement, if only to authenticate privileged users from unprivileged ones, and you’ll need to be able to track issues from their point of origin (the original submitter) to the final resolution.If the data that’s being tracked is proprietary, you’ll need to ensure that your vendor for web based issue tracking is able to handle HTTPS traffic as well as straight HTTP; this, fortunately, is a standard feature for most web based issue tracking tools and many internal bug tracking tools.If you’re using an internal bug tracking tool that doesn’t support HTTPS, you can restrict the number of IP addresses that can access it, or, if your organization already uses it, utilize virtual private networking (VPN) to allow users to get at it securely.
issue tracking,issue tracking software,defect management,software defect management,help desk