Building a Secure Software Development Life Cycle: Beginner’s Guide to Success

27Aug, 2018

A traditional software development lifecycle (SDLC) often overlooks security testing and delays security verification and testing efforts until after the software has been created. However, vulnerabilities are an emergent property of software that appears throughout the design and implementation cycles. Gradually, the earlier a defect is uncovered, the cheaper it is to fix, which makes it important to employ many processes throughout the lifecycle.

This article discusses the importance of incorporating and addressing security issues early on in the lifecycle through a process called Secure Software Development Life Cycle, which ensures software quality from the early stages of the testing process. Such efforts engage the stakeholders early on as well as throughout analysis, design, and development of each software build, which is done in an incremental fashion.

The SSDL is geared toward ensuring successful implementation of secure software. The six primary components of SSDL are-

1. Security Guidelines, Rules, and Regulations

It is important to note that security guidelines, rules, and regulations must be considered during the project’s inception phase. This component of SSDL is the primary requirement. At this phase, a system-wide specification is created that defines the security requirements that apply to the system; it can be based on specific government regulations. In India, various corporate governance norms ensure that internal controls are put in place to curtail fraud and abuse. It is also important not only to document the security policy but also to continuously enforce it by tracking and evaluating it on an ongoing basis.

2. Attack Use Cases and related security requirements

A common mistake that testers usually make is to omit security requirements from any type of requirements documentation. However, it is important to document security requirements, since they aid in software design, implementation and test case development, apart from determining technology choices and areas of risk. The security engineer should insist that associated security requirements be described and documented along with each functional requirement. Defining a requirement’s specific quality measure also helps rationalize fuzzy requirements.

Attack use cases can also be developed that show behavioural flows that are not allowed or are unauthorized. They can help you understand and analyze security implications of pre and post- conditions. Some sample security requirements are-

  • The application sends private data over the network; therefore, communication encryption is a requirement.
  • The application takes user input and uses SQL. SQL injection mitigations are a requirement.
  • The application interfaces with other trusted applications, and these connections must be validated and protected.
  • The application manages sessions for a logged-in user, and session hijacking mitigations must be in place etc.
DevOps QA
Click here : Top 10 Industry Best Practices in Automation Testing: A Guide for Professionals

4. 3. Architectural and Design Reviews/Threat Modelling

Architectural and design reviews and threat modelling represent the third phase of the SSDL. In order to devise better and more complete security plans, strategies, procedures, designs and techniques, security practitioners often need an in-depth understanding of the product’s architecture and design. An initial security team involvement can also result in prevention of low-security designs and insecure architectures as well as ensure elimination of misperception relating to the application’s behaviour at later stages in the project lifecycle. In addition, early involvement allows the security expert to learn which aspects of the application are the most critical and which are the highest-risk elements from a security perspective.

The benefits of threat modelling are that it finds different issues than code reviews and testing, and it can find higher-level design issues versus implementation bugs. Since you can find security problems early, this helps you determine the ‘highest risk’ parts of the application—those that need the most scrutiny throughout the software development efforts.

4. Secure Coding Guidelines

A design vulnerability is a flaw in the design that precludes the program from operating securely no matter how perfectly it is implemented by the coders. Implementation vulnerabilities are caused by security bugs in the actual coding of the software. Static analysis tools can detect many implementation errors by scanning the source code or the binary executable. These tools are quite useful in finding issues such as buffer overflows, and their output can help developers learn to prevent the errors in the first place.

It is recommended that software developers and testers attend training sessions on how to develop secure code by adhering to these secure coding standards. Using the secure coding standards as baselines, testers can then develop test cases to verify that the standard is being followed.

KiwiQA iTunes
KiwiQA iTunes

5. Black/Gray/White Testing

Since the test environment setup is a part of the security test planning, it enables easy facilitation of planning, tracking and managing test environment set up activities, in cases where material procurements may have long lead times. The test team also needs to ensure tracking and scheduling of environment setup practices, installation of the test environment, software, hardware and network resources, integration and installation of test environment resources and refining/obtaining test databases as well as developing environment setup scripts.

This includes executing security test scripts and refining them, conducting evaluation activities to avoid false positives and/or false negatives, documenting security problems via system problem reports, supporting developer understanding of system and software problems and replication of the issue, performing regression tests and other tests, and tracking problems to closure.

6. Determining Exploitability

Ideally, every vulnerability discovered in the testing phase of the SSDL could be easily fixed. Depending on the cause of the vulnerability, whether it’s a design or implementation error, the effort required to address it can vary widely. A vulnerability’s exploitability is an important factor in gauging the risk it presents. You can use this information to prioritize the vulnerability’s remediation among other development requirements, such as implementing new features and addressing other security concerns.


Focusing on application security throughout the software development lifecycle is most efficient and is just as important as the focus on infrastructure security. After the process is completed, the process of deploying and maintaining the application securely occurs at the end of the lifecycle. Following these steps is important to ensure secure software.