Helpdesk: 0207 100 3655
Support key
Enter your PIN-code to connect with one of our technicians
No PIN-code? Contact us


Website or software project


When does a Website become a software project ? In short when it uses a CMS ( Content Management System), such as WordPress, Drupal, Joomla, Umbraco or Sharepoint. The use of a database to generate dynamic content or pull data from other sources also indicates that software project methods need to be used to avoid future problems.

23% of websites are using the  Wordpress CMS in 2014 and this represents a very large install base and attractive target for hackers.  It is worth looking at the incentives and components in the online criminal economy, that contribute to these attacks, as the motivations of the attackers are often left without explanation, or thought to be either puckish humour or figments of the security industry’s paranoia.

The attackers of websites usually exploit a known vulnerability in the CMS to gain control of the web server. This means that the CMS provider has released an update to fix the vulnerability, but the server doesn’t have it applied. Having exploited the unpatched vulnerability, the attackers consolidate their control with new admin accounts and back doors (new ways to get back onto the server) and then upload further code to the website which turns it into a virus/malware distribution engine, attacking the websites visitors, your clients BTW, and trying to infect these visitors computers with viruses. Once infected these computers become the income generation entities for the criminals. They collect login credentials for website or banks and sell these for a few dollars a piece, they can use the machines to attack other computers or to participate in click fraud attacks to generate fake advertising revenue.This is  mostly nothing personal they have simply scanned the web server found it vulnerable and applied the software to attack the vulnerabilities.

The UK govt CERT ( Computer Emergency Response Team) have written a paper about these issues in relation to WordPress, but the principles apply to all CMS driven sites. The key quote being:

“In this case we are predominantly talking about individual users with personal blogs or SMEs with unpatched and/or outsourced websites. Organisations often tell us they have no idea whether, or assume, their website is secure because they have outsourced its design and management to a third party.”

Most SMEs outsource design and hosting of websites to 3rd parties and in the UK these are often small digital agencies and cloud hosting providers. Perfectly reasonable thing to do; provided that the 3rd party has some form of contract to maintain the website/code which they have produced and that they or someone else is patching the server to deal with the threats which emerge every month or so on all major CMS systems and hosting platforms.  The issue becomes one of incentives and responsibilities:

Quoting CERT again:

In August 2014, one of our members reported the compromise and defacement of a high profile customer

website using a customised version of WordPress. The customer’s site had been designed by a third party and

could not be updated or patched without “breaking” the site; meaning that 18 critical updates had not been


If the developer uses plugins ( 3rd party software used to extend the CMS, like commerce or shopping carts etc) or customises the CMS, then patches will most likely break the site, leaving the server maintainers with the Hobson Choice of; patch the server and break the site, or leave the server vulnerable. Most maintainers follow the ethical inactivity of the Trolley Problem not doing anything to actively cause harm.

Small web agencies often fall into two camps, front-end (UI/UX/Design) or Backend ( Databases/coding/dev) and they will frequently outsource the other aspect to another subcontractor.

This leads to a bind, if small changes are needed they need to get a quote and either store all the client design files or source code in some kind of version control systems. This generates ongoing costs and responsibilities to make changes at short notice and interrupts their normal work flow.

The other, and I think more serious issue, is that the web designers don’t want to bring up the subject of ongoing costs to  their clients.Bringing up costs, puts them at a disadvantage when quoting vs competitors who pretend that the problem doesn’t exist and once built, websites cost nothing.

The answers are budgets, contracts and  realism. Agreeing whose responsibility is what and getting this in an email is enough on a small site. If you fall out of contact with the web developer then a new one needs to be found who is prepared to take over the project and contract.  The website design project needs to have some basic conditions:

  1. Put the site and code into a source code control or version control system.
  2. To hand over the graphics files and materials used to generate the content.
  3. To know who owns the copyright to the images and content and what the restrictions of the use are.
  4. Have a process for testing updates to the site, CMS and server and releasing these to the live site, or just mandate that the CMS and server must auto-update with the latest software updates.
  5. Have a contract including a handover clause on termination.
  6. Know who is maintaining the web server and CMS, pay them for it!
  7. Backup the website and CMS config.

The glib statement that the servers should be patched by default hides an awkwardly complicated mess. A bit of rigour from a project management perspective can mean that the servers are patched and the site will stay live and even that a new developer or designer can take over the project without having to do a complete rewrite.

Next Article