SDLC: Secure Development Lifecycle, and why you should stick to it in Healthtech Development

Despite what your mom might have told you, failures are great. Sure! They allow us to progress faster and look for secure, stable, and working solutions. However, some areas are way more failure-tolerant than others, and you definitely can’t fail much in aviation and heart surgery. That’s why we stick with a secure development methodology – to prevent failure at the very beginning of any project and to overcome and learn from mistakes as fast as possible. The reason why we didn’t have critical mistakes in our projects is because we’ve been using the SDLC since the beginning of mankind. But things wouldn’t go as smoothly if we didn’t use it. Let’s take a general look at SDLC and its structure.

What is SDLC?

Secure Development Lifecycle, or SDLC- is a software development process with a focus on security at every stage of development, from the app’s early concept to its maintenance.

Usually, System Development Lifecycle (SDLC) consists of these phases:

• Planning and requirements 
• Architecture and design 
• Test planning 
• Coding 
• Testing the code and results 
• Release and maintenance

To avoid discovering critical bugs at the testing phase, SDLC introduces penetration testing, code review, and architecture analysis at all stages of the development process. The benefits are more obvious than a pimple on your cheek before the big date: this way developers can detect problems early in the development process, thus reducing business risks. It will also reduce costs by fixing issues at early development stages. Let’s take a closer look at each SDLC stage in the next section.

SDLC Stages

There are many stages of SDLC that must correspond with a phase in SDLC. They’re basically making every development step more secure by testing, estimating possible threats, creating backup plans, and providing security training for personnel. These stages are:

• SDLC Discovery. This is basically a preparation stage, whose goal is to determine possible threats, and the security and regulatory requirements. It must be engaged during the earliest phase possible, i.e. concept or planning phases; 
• Threat Modeling. This happens during the planning phase and helps to develop a recovery plan from the start, planning appropriate mitigation measures while the damage is still relatively easy to manage; 
• Third-Party Software Tracking. It’s better to track usage of any third-party tools used in the project during the planning phase, so in case any component requires upgrading or has licensing issues, the team will spend less time fixing it; 
• Security Design Review. Going to the Design and Development phase, the goal of the development team is to make sure the software is built with the most secure features possible. They need to provide a security design review thinking like an attacker to discover the feature vulnerabilities; 
• Security Testing. It happens during the testing phase and its goal is to test the product’s vulnerability to attacks. It’s a very complex stage that consists of:

• Static Analysis — analyzes software to identify the exact location of weakness without running it; 
• Dynamic Analysis — runs software to identify flaws, patch errors, and infrastructural imperfections; 
• Vulnerability Scanning — injects malicious inputs against running software to check how the program reacts; 
• Fuzzing — engages “human factor” by trying to input invalid, random data to a program, to check for access protocols and file formats; 
• Third-party penetration testing — an external tester or group of testers simulate an attack to find coding or system configuration issues, and discover vulnerabilities a real attacker could use.

This is what we meant by the phrase “failures are great”  the beginning. SDLC is constantly trying to make your product fail or break, so the development team could study and remove the point of failure.  In Healthcare software development it is very important that such vulnerabilities were found by developers, not users. Otherwise, it may lead to incorrect medical decisions and unnecessary treatment due to malfunctioning software.

How we use SDLC in our projects

So, we can finally look at our SDLC best practices. At GreenM we follow all phases of the SDLC. For example, while working on a technical design of a product, we think about the security requirements and how they will be implemented from the start. We pay great attention to testing the functionality, and ideally, resort to automated testing.

In the development phases, we use the “shift left” approach, i.e. develop product security as early as possible. Before SDLC, teams developed the product, then gave it to testing before release. In the case of receiving a response about security problems, the product was returned for revision. But thanks to SDLC, we have shifted over to short development iterations that help us detect and fix most problems before release. Thus, deadlines are not delayed and it takes less money to develop and refine the product.

It is very important to prepare the application to collect performance metrics because secure development does not end after the release, it flows into product monitoring and support. By collecting data from metrics, developers can identify weaknesses and correct the next development cycle. That’s why it’s called the lifecycle.

Conclusion

By sticking to SDLC principles, we have avoided many development mistakes in the past. It saved tons of time and costs, and made final products reliable in terms of security and stability which have always left our customers satisfied. If you want to develop secure and stable software for Healthcare, SDLC must be your chosen methodology. Because it allows to:

• Prevent critical bugs, system failures, and data vulnerability; 
• Fix most issues almost instantly; 
• Reduce development time and costs; 
• Create a product that both hospitals and patients will be confident about.