Secure Software Development Life Cycle

While we already know enough about SDLC,

As we have a context of DevSecOps too, let’s dive deep inn to know the practices been followed in Industry to inculcate the ‘security’ aspect as the must need in a product from earlier stages itself, → so we have ‘Secure Software Development Life Cycle’.

Secure Software Development Lifecycle (SSDLC)

During SDLC, security testing was introduced very late in the lifecycle. Bugs, flaws, and other vulnerabilities were identified late, making them far more expensive and time-consuming to fix. In most cases, security testing was not considered during the testing phase, so end-users reported bugs after deployment. Secure SDLC models aim to introduce security at every stage of the SDLC.

Why is Secure SDLC important?

A study conducted by the Systems and Sciences institute at IBM discovered that it costs six times more to fix a bug found during implementation than one identified as early as during the design phase. It also reported that it costs 15 times more if flaws are identified during testing and up to 100 times more costly if identified during the maintenance and operation phases. See the figure below:

Apart from faster development and reduction of costs, integrating security across the SDLC helps discover and reduce vulnerabilities early, reducing business risk massively.

Examples of introducing security at all stages are architecture analysis during design, code review and scanners during the development stage and conducting security assessments (e.g. penetration tests) before deployment.

‘Security By Design’ approach.

Implementing SSDLC :

• Risk Assessment during the early stages of SDLC, it is essential to identify security considerations that promote a security by design approach when functional requirements are gathered in the planning and requirements stages. For example, if a user requests a blog entry from a site, the user should not be able to edit the blog or remove unnecessary input fields.
• Threat Modelling - is the process of identifying potential threats when there is a lack of appropriate safeguards. It is very effective when following a risk assessment and during the design stage of the SDLC, as Threat Modelling focuses on what should not happen. In contrast, design requirements state how the software will behave and interact. For example, ensure there is verification when a user requests account information.
• Code Scanning / Review - Code reviews can be either manual or automated. Code Scanning or automated code reviews can leverage Static and Dynamic Security testing technologies. These are crucial in the Development stages as code is being written.