Skip to content
Contact

How to take care of security in software development? Software Development Life Cycle

Recently security becomes a big thing. Finally! Unfortunately, there had to be a lot of spectacular failures for some people to notice that it might be a problem for their businesses as well.

After over a decade in software engineering and business, I gathered a bunch of my thoughts about the most common obstacles through which security is compromised.

Software Development Life Cycle

It is very easy to forget about security aspects as during development nothing will go very wrong to bring our attention and approach to development usually stays the same. There has been some changed and improved over time to Software Development Life Cycle, for example, moving from Waterfall to Agile methodologies, but one problem remains the same. It is a common practice to perform a security-related tasks at the end of the process, if at all.

This after-the-fact technique usually results in a high number of issues discovered way too late (or not found at all). It is a far better practice to integrate security-related activities across the SDLC to help detect and reduce vulnerabilities early, effectively building security in, and raising awareness throughout the whole team that it’s not something we will take care later on.

There are a lot of different reasons why such practices are widespread, especially in a startup world. Let me point out a few to give you a perspective, or maybe it is going to be a yellow flag sometimes to make sure that everything is going in the right direction.

Unrealistic deadlines

First and the most common bad practice is setting unrealistic deadlines to cut costs and stay ahead of the competition. Such an approach puts a lot of pressure on developers that need to try to find shortcuts to deliver features no matter at what cost. And even when they don’t, it’s still very easy to produce little coding mistakes that will come out at some point in such an environment. Especially when no tests are performed over the development time and before the release of the product to the market.

Lack of knowledge

Another thing is sometimes the lack of knowledge and awareness about security throughout developers. In big corporations, there are teams of developers working together in specific areas of software development. In smaller companies, developers usually have to have a broader knowledge to be able to fulfill feature requirements.

Security aspects are a whole another area of knowledge. It’s not that they don’t want to create great software, most of the time they do, but very often without even thinking about it. That’s why one of the CTO’s roles is to raise awareness of the importance of software security. On the other hand, it’s not smart to require 100% secure systems, that would be a waste of time and money. With a proper risk assessment, we only take care of the most crucial parts of our systems.

Development in isolation

It’s not a good idea to develop software in isolation. What I mean by that is that usually a system consists of several different parts — server, mobile, hardware, etc. — and each developer working on his part is not looking at the system holistically, and might not see threats that this brings, like validation, or limiting the number of requests to log in. Wrong assumptions that someone else is going to take care of that is usually false. And just because in a different project it was implemented in a certain way this doesn’t mean it will work this time. That is another role of CTO to make sure everyone understands the whole product and not just the parts of it. That can also lead to forgetting to cover specific scenarios which might get exploited by the attacker.

Of course, if developers don’t follow known excellent software development standards, it’s the whole another problem and our responsibility is to make sure that the quality of software used and created for our solution is on a right level.

No security review policy

Quite dangerous might be forgetting about security after our product is launched as well. Even if all tests and development processes went smoothly and according to current standards. Unfortunately sometimes, for example, with encryption algorithms, those might get outdated over time. Computing power is increasing every year, and sometimes bugs and security loopholes are discovered in “secure” in their times’ algorithms of frameworks. It’s essential to have a process in place requiring a review of our system once in a while.

Situations, where no QA or testing procedures are involved in the development, are unacceptable! It’s like jumping out from a plane without a parachute. Chances that we are going to land on a stack of pillows are close to zero.

What to do to care about security in software development?

  1. Think about your Software Development Life Cycle and find out what you can improve. Prepare a list of priorities and plan to implement changes.
  2. Set realistic deadlines because mistakes will come to light at the least expected time and will cost you dearly.
  3. Find one person responsible for security in your company because otherwise the responsibility could be blurred. Most often such a person should be a CTO.
  4. Don’t develop software in isolation. It’s really important to create an environment where there is a smooth knowledge flow between developers working on different aspects of the project.
  5. Don’t forget about the security review policy, because IT market is evolving constantly.
  6.  

Check my previous article Is your product or service secure? What makes you think that and who is responsible for it actually?

In my next articles I’ll tell you:

  • What is SSDLC and risk assessment? How to implement them?
  • Security issues in software development (policy, threat model, mechanisms) with examples.


If you share my ideas or have a question about security, please leave a comment.

If you have a project to discuss, contact us .


Here you can find my articles regarding code quality and building software development teams

By Bartek Hugo Trzciński

Head of Technology by day and software engineer by night. Recently solving more problems in business and mangement than in code - hard to tell which one is more fun. Local dev groups activist. Automotive enthusiast. Boosted Board shredding champ. The best companion to dance and to give you a ride.