Building a secure app in five steps

Use the Software Development Lifecycle (SDLC) as a template to secure your application

photo by Glenn Carstens-Peters to Unsplash

If you love to build software, you’ve probably heard of the Software Development Lifecycle (SDLC). The SDLC describes the five stages of application development: the requirements phase, the design phase, the coding phase, the test phase and the release phase.

  1. Requirements phase: You start by listing what you need to build, or the “requirements” for your application. So, if you are building a messaging app, you are probably going to need a way to allow users to sign up, log in, send private messages, etc. Understanding exactly what you need to build will help you design your application in the next phase.
  2. Design phase: In this phase, you take the application requirements from the last step and plan the structure of your application.
  3. Coding phase: In the coding phase, you actually build the functionality of the application.
  4. Testing phase: You test the application in terms of functionality, usability and security.
  5. Release phase: Finally, you release the app to users and maintain it over time.

What does this have to do with application security?

So what does all of this have to do with application security?

When we look at the SDLC, we also see five distinct chances of incorporating security measures into the development process, or five chances of making sure your application is as secure as possible!

Terms & Conditions

Let’s start with the requirements phase. When you identify the functional requirements for the application, you should also identify the security requirements for those features. For example, if you need to transport data, do you also need to store and transport sensitive data? Do you need to take user input into account and process it? If so, you might need to implement input validation. Will this app perform risky features like downloading files?


The next step is to plan the design of the application based on these security requirements. You can take the security requirements you listed in the requirements phase and find out how to design the application around those requirements. You usually ask yourself questions like: How should we implement authentication and authorization? How do we handle user input securely? What type of input validation should we use on different types of input? Where do we store data and code? What protocols or encryption should we use to store and transport data securely?

The key is to design the application in a secure manner taking into account the security requirements as well as its functional requirements.


For the coding phase, put measures in place to ensure that development is done safely. One of the first things to do is choose a secure programming language and framework. You can also implement policies and guidelines on how to handle unreliable data securely through validation, disinfection, and output encoding. Having a standardized policy on how to handle these situations will ensure that every potential weak point in the application is properly addressed.

During this step, you should also use a Static Analysis Tool (SAST) to continuously scan your code during development and eliminate security vulnerabilities as much as possible. Static analysis tools automatically identify signs of various vulnerabilities in your code so that you can fix them immediately. This will make things much easier during the testing phase.


And then, in the testing phase, run a wide variety of security tests to test your application’s implementations and make sure that no serious bugs are put into production. You can run dynamic analysis tools, perform a penetration test, or perform a manual security code review, for example.

You should also test your application against a software composition analysis (SCA) tool. SCA tools keep track of an application’s dependencies and alert you if any publicly disclosed vulnerabilities are found in your application.

Often times, we won’t start to consider security until the testing phase. But this phase shouldn’t be the starting point of your security effort. It should be security built-in to detect vulnerabilities that somehow escape the security protocols implemented earlier in your development cycle.


And finally, after release, you can integrate routine security testing, such as static scan and SCA scans, to monitor the application after deployment. You may also want to consider running a bug bounty or vulnerability disclosure program to allow third-party security researchers to safely report security bugs in your application.

Safety “shift to the left”

This whole process is what people mean when they say “go left”. Shift left security means performing security testing and verification sooner rather than later in the SDLC. Instead of incorporating security considerations only into later phases of software development, such as testing and release, we should incorporate them into the early stages of requirement, design, and coding.

By considering security during application requirements and design phases, you can plan your security measures before significant effort is wasted implementing unsecured designs and architectures. And by also performing security testing throughout the coding phase, you can spot security holes before a feature becomes more complicated and integrated with the rest of the app.

Security doesn’t kick in after you finish writing code, rather it should be a constant consideration before, during, and after your work in the IDE.

Thanks for reading! What’s the hardest part of developing secure software for you? I would like to know. Do not hesitate to connect on Twitter @ vickieli7.

Building a secure app in five steps was originally published in ShiftLeft Blog on Medium, where people continue the conversation by highlighting and responding to this story.

*** This is a Syndicated Security Bloggers Network blog by ShiftLeft Blog – Medium written by Vickie Li. Read original post on:—-86a4f941c7da—4

Source link

Margie D. Carlisle

Leave a Reply

Your email address will not be published. Required fields are marked *