Secure Software Development: There is More to it Than Just Writing Code!

In recent years we have seen several technological and software advancements. This has led to a new age made up of various asymmetric cyber attacks, fast paced and ever changing threat landscape. The ever increasing use of the internet as a business and social tool has seen the demand of applications and software to be developed at the speed of thought and time.

However, most of the applications or software being developed are vulnerable to all sorts of attacks and threats due to poor software security development procedures/culture applied by the programmers. This has proven costly for organisations world over. For example when poorly developed and insecure systems are put into production and are hacked (reputation and financial costs) or incurring extra costs due to project reworks (re-designing/programming the system).

Before we go any further, any developer should understand the tao of securing their end product i.e.  The security, reliability, integrity and safety of any application must be built in from the early stages of the development lifecycle. Security seems to be an afterthought for most organisations (and hence the developers) mainly due to lack of secure software development policies and training for the developers. The driving force to attain a culture of effective secure development practices is hinged on educating those involved in the software development lifecycle.


Vulnerabilities in software that are introduced by mistake or poor security practices are a serious problem today. Here are some quotes expressing the level of concern:

“Our universities are letting us down.” In the vast majority of universities developers are taught that the highest-value principles for good software are functionality and performance; security, if taught at all, is characterised as an “optional” principle that runs a distant third in importance behind functionality and performance, or it is marginalised as applicable only in specialty software written for cryptosystems and network security protocols. Brian Cohen in Security in the software lifecycle

However, delegates were told that much of the problem with online security lies with poorly written software.
“The real problem is that we’re putting software on the market that is as vulnerable as it was 20 years ago,” said Cristine Hoepers, general manager of the Brazilian National Computer Emergency Response Team.

“If you see the vulnerabilities that are being exploited today, they are still the same. Universities are not teaching students to think about that. We need to change the workforce. We need to go to the universities. We need to start educating our..International Telecomm Union Conference 2009

“Secure Software Development requires a combination of knowledge, basic skills and practice so that defending applications through secure coding is done instinctively.” Microsoft SDL

The forgotten Principles:

The tao and basic philosophy of secure coding/programming practices focuses on easy, re-usable and repeatable coding techniques. These techniques are so basic and do not require developers to become security experts. Instead the approach focuses on using the right tools, standards, techniques and principles to guide developers to create secure applications that can be efficiently implemented, maintained and withstand security breaches.

Most developers lack the know-how of recognising and understanding the security implications of how they specify and design software, write code, integrate/assemble components, test, and package, distribute, and maintain software. In order for them to gain the knowledge they need to be trained and be equipped with the right skill, practices and techniques so that they do things more securely.

Security Training Basics for Developers:

The secure Software development training should target all staff involved in the development lifecycle. Senior staff members, business analysts, System Analysts/Administrators, Programmers, Testers etc… The training is independent of the language used. It does not matter if you are an old dog developer (Basic, VB6, LISP Cobol, C) or the new age kiddo (Java, .Net, Ajax, php….you name it all).

The training program should include at least the following topics:

  • Security basics, understanding the problem (Integrating Security into SDLC);
  • Fundamentals of Risk management/Software Assurance
  • Threat modelling (designers, program managers, architects, testers, business analysts);
  • Secure design/architecture principles (designers, program managers, architects, testers);
  • Implementing threat mitigations (developers);
  • Fuzz testing (testers);
  • Security code reviews and Penetration testing (developers, testers);
  • Cryptography basics (all personnel involved in software development);
  • Defensive programming[1](the basics);
  • Critiquing programs and documentation
  • Technical and Functional Specifications (Security components)
  • Authentication strategies(Trust boundary  rules)

What wise developers watch for:

Developers should endeavour to make sure that all code is secure and that they are aware of the various secure coding practices to ensure that they minimise the risks associated with some of the following most common programming mistakes:

  • Input Validation
  • Improper Encoding or Escaping output
  • SQL Injection
  • OS Command Injection
  • Clear text Transmission of Sensitive Information
  • Race Condition
  • Error Message Information Leak
  • Memory Buffer Overflows
  • Resource Shutdown or Release Risks
  • Improper Initialisation
  • Improper Access Control (Authorisation)
  • Hard-Coded Password
  • Code Comments


I have had my fair share of developing applications (shhhhhhh) with little or no security considerations…that’s back then, years ago, before I ventured into security) and now  I see things differently…from a security perspective of course.

The responsibility is with both the organisations and developers to foster a culture of secure development practices. Organisations should provide the policies and resources whilst the developers should endeavour to learn and implement security techniques at all the stages of the development life cycle.

Finally, if the secure development standards and baselines are followed and implemented properly throughout the development stages they can help reduce the overall chances of developing and deploying unsecured systems/applications and thus protecting the organisations critical applications

[1] Defensive programming teaches developers how to look for hidden assumptions in their programs, and how to defend against attempts to exploit those assumptions to cause their programs to behave in unexpected or undesirable ways.

Quick NetOne, Telecel, Africom, And Econet Airtime Recharge

If anything goes wrong, click here to enter your query.

11 thoughts on “Secure Software Development: There is More to it Than Just Writing Code!

  1. Secure Software Development is OWASP (’s raison d’etre. What’s more ALL of their high quality resources are FREELY available from their website. Any developer who wants to get to grips with A to Z of Secure Software Development should at the very minimum familiarise themselves with OWASP’s Top 10 Application Security Vulnerabilities

  2. To say “universities are letting us down” is a downright lie. I think insecure software is a product of a lax corporate culture/ a culture that puts deadlines before security. When a developer is running out of time – guess what’s the first thing to go out of the window (hint – it’s not something that’s immediately visible). Code review helps a bit, as does automated source checking (such as checking for unsafe memcopy() operations). The most effective way, however, is to instill the ‘secure by design’ mentality into the developers, so that security is a consideration from the ground up.

    As a web developer, I would like to add a web-specific threat – Cross-Site Scripting (XSS). It might fall under “Improper Encoding or Escaping output” – but I feel it deserves a mention in its own right

  3. Tapiwa,
    Great response. As per brian Cohen, he is not blaming the universities outrightly but we have to agree courses tought in in programming at Unis do not set a sound bases on Security.You also highlighted a vital point about the corporate culture being the greatest drawback….100% correct. I think organisations need to set policies and baselines for all software.

    In the Article i did put a link that point to XSS as a major threat. It is listed under Software Error Category: Insecure Interaction Between Components.


  4. Good article. I think IT Risk management and security should a module or course as part of IT degrees….

  5. Kuda,
    The process of changing University/College Ciricula is lengthy. However, the immediate thing to ensure SSD is for organisation to change their culture and adopt security and risk management principles

  6. Here is something cool on SSD that I came across:
    Laugh & Learn: Using COBIT to Improve the Software Development Life Cycle
    By Corjan Bast

    Improving IT governance or implementing COBIT can seem very easy on paper, but the actual exercise usually is not. Part of the difficulty is that many people do not understand the COBIT concepts or, when they do, they find it difficult to explain to someone what COBIT provides. Fortunately, humor can help a great deal in helping someone “understand.” The anecdotal example included here builds on this to explain how COBIT can be used to improve the software development life cycle, one of the many aspects in which COBIT can be used to enhance IT governance.
    Anecdotal Example

    1. Programmer produces code that is believed to be bug-free.
    2. Product is tested. Twenty-six bugs are found.
    3. Programmer fixes 16 of the bugs and explains to the testing department that the other 10 are not really bugs.
    4. Testing department finds that five of the fixes did not work and discovers 14 new bugs.
    5. Repeat step 3.
    6. Repeat step 4.
    7. Due to pressure from the business and an extremely premature product announcement based on an overly optimistic programming schedule, the product is released.
    8. Users find 139 new bugs.
    9. Original programmer is no longer with the company.
    10. Newly assembled programming team fixes almost all of the 139 bugs, but introduces 567 new ones.
    11. Original programmer sends underpaid and overworked testing department a postcard from Hawaii. Entire testing department quits.
    12. Company is bought in a hostile takeover by competitor using profits from its latest release, which had 687 bugs.
    13. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.
    14. Programmer produces code that is believed to be bug-free…

    Learning Point

    Obviously something goes wrong during the software development life cycle, but unfortunately, nothing is changed for the better. Although the situation in the example is, of course, a bit exaggerated, the nature of the example is applicable to many organizations: Things go wrong and will go wrong, but finding the correct improvements and driving the change is another story.

    COBIT can be used to improve the situation in the example. COBIT’s Acquire and Implement (AI) domain provides guidance so that the business objectives/goals linked to the software development projects will be successfully met. The COBIT AI5 Procure IT resources process, for example, will help ensure that the correct IT skills are available, while AI7 Install and accredit solutions and changes minimizes errors creeping into live production due to incomplete testing. In turn, these COBIT processes can be supported by IT Infrastructure Library (ITIL) processes, such as release management, deployment management and change management, for greater detail.

    According to COBIT, executives and the board of directors are ultimately responsible for the governance of IT. It is essential that they provide leadership, organizational structures and processes to enable IT to deliver value and support the organization’s strategies and objectives. This is clearly not the case in the example.

    To help organizations implement COBIT and be able to change the organization, ISACA released the guide Implementing and Continuously Improving IT Governance in late 2009. The guide not only focuses on implementing COBIT, but it also talks a great deal about enabling a change in culture, which is necessary throughout any implementation. Perhaps after reading the implementation guide, changing the organization to use COBIT will not be too hard after all.

  7. I do agree with those who say the blame dznt lie with the universities or colleges. Academic curricula usually give you starting points before you decide to specialise. Unless you have specific degrees like purely Software Engineering as opposed to the more generic Computer Science, it is nearly impossible for you to exhaust secure coding. At our university, we did brush through the topics. Those with interest or whose career paths dictated so, learnt more on the topic. It is extremely important. Things like credit card fraud and violation of privacy have had a lot of blame on programming laxity. Testing, unfortunately is hardly given attention, especially by non-technical decision makers who do not appreciate or acknowledge the danger in skipping this crucial test. People are chasing money. In the process, applications are not presented with test cases that could otherwise help identify flaws that make the software vulnerable.

    Funny that buffer overflow exploits are still reported. Best approach as a programmer is to treat all input from users as malicious, and code around catching and filtering out any harmful input

  8. I agree that we should not totally blame the Universities/Colleges.But I feel that the basics of security(101 basics) should be introduced to scholars, this will help them to carry the awareness to indusrty. Industry will never train Developers, they are there to make money as quickly as they can thus the vicious cylcle continues.
    Thats why as you mentioned …..Old vulnerabilities such as Buffer overflows are still going on..

  9. Ih this magazine there is a great piece of the basics of threat modelling. For those developers looking forward to foster their code threat analysis and modeling skills , this is a good point to start

    In the world of software, security is thrown into a system somewhere at the end of the project. For many developers adding security to a system is using a login with SSL/TLS; but sadly, these two are not the security silver bullet developers are led to believe.

Comments are closed.