Securing the SDLC

Guide to help you design a secure Software Development Lifecycle

shilpy banerjee
7 min readFeb 13, 2023

Many security professionals might come across this task in their carrier to develop a secure SDLC framework for their organizations. Having years of experience in different areas in security field makes you feel that everything around it is extremely important, and nothing can be missed out. Infact that's absolutely true, however when one is asked to design a secure Software Development Lifecycle for their company it becomes absolutely important to keep the document crisp and in the correct order in which it can make best sense. Because believe it or not, no one likes reading lengthy documents specially developers as its time consuming and knowledge absorption rate reduces over time. In this blog, I have tried to summarize the important areas that you should focus when it comes to building security in the SDLC.

Before we start discussing in-depth of securing things lets first understand the phases of SDLC which the below image summarizes.

Image taken from Google (no credits taken)

Always start designing the Secure SDLC keeping in mind that it will be useful for anyone who can influence application security like product owners, project managers, developers, release management, operations etc. It is important that you consider security frameworks like NIST, OWASP, SANS to design with efficiency.

After understanding the phases of SDLC, lets identify what steps should we introduce to bring in security.

  1. Planning \ Requirement Gathering Phase:

In this phase, we try to understand the application portfolio. Once you understand the type of application, features, types of user base, technologies etc perform threat modelling and risk assessment. You can perform a user risk analysis and document the findings. You might also want to invest sometime in understanding whether any third-party components are involved in order to understand the risks around it. This could be a good phase to identify security champions (personnels who could be from different field like frontend developers, middleware team or product owners who are keen to learn about security and would be the responsible to make sure the secure SDLC framework is being followed for their application) to provide them with trainings and making them aware of security.

2. Design Phase:

Start by understanding the architecture diagrams. Define the security requirements once an architecture review has been performed. Apply the principle of “Defense in Depth” and “Zero Trust Model” (this depends on organization needs) and design your security requirements. Listing some of the areas that you might want to focus on for setting up security requirements (not an exhaustive list):

i) Access and authorization levels in different environments like production, pre-production, staging etc.

ii) Risks from third party component (like Saas) and management around that and reviewing them.

iii) If any outsourced development activities are involved, then setting principles and boundaries around that. What kind of access levels the contractors will need and what actions are they authorized to perform. What responsibilities will they have in terms of fixing vulnerabilities, upgrading systems, patch management etc.

iv) Securing the operations — Multi factor authentication, IAM policies, authentication to hosting environments, hardening your systems (application servers, webs servers, cloud environments, containers, runtime environments, CICD pipelines, secret management and the list goes on!!

v) Encryption mechanism that needs to be applied in various areas like setting up the requirement for data at rest, data in transit etc.

vi) Data classification — based on the use cases, classification of data is mandatory to understanding what is PII, confidential or sensitive data. Making sure that data privacy is in consideration all the times based on the regions/countries the data is residing or processed.

3. Deploy:

You must understand the steps that are being followed to deploy an application. There will be brainstorming needed to secure your deployment pipelines (thats another huge area of discussion). You must understand the deployment steps and plan.

Taken from OWASP

On another note, before a solution goes live in production there are several security assessments it is advised to undergo. It is always better to shift as much left as possible to reduce introducing security bugs at the later stages of SDLC. Some vendors like “Whitesource” even provide browser plugins for developers so that when they are downloading open-source components like libraries, frameworks etc they get notified that they are downloading a version which might have vulnerabilities. Similarly, you have IDE plugins which help you upgrade the libraries which might have vulnerabilities. Below is the list of assessment that an application team should undergo before going live in production (not all organizations mandate each step, however it is suggested as part of best practice)

i) Secure code reviews (SAST)- code reviews for identifying bugs in the solution. Some major tools that you might have heard about Checkmarx, Veracode, CodeQL, Synk etc. Certifications like OSWE majorly focus on this area as well.

ii) Static Code Analysis (SCA)\Dependency scans — It is important that open-source components are scanned for any known vulnerabilities existing in the code. Some tools that you might have heard about which provides you with this feature — Dependabot alerts by Github, JFrog, Synk, Whitesource, Blackduck, Debricked and Sontype. All these tools provide a wide variety of other features too along with dependency reviews.

iii) License Management — A very important but highly ignored assessment is keeping track of licenses in the open-source code that your organization is using. If individuals do not use correct license types, then it might so happen that the organizations might end up paying heftily under legal obligations. You might want to restrict some open-source licenses that might lead to legal risks (Open Source License Types — Detailed Guide l Scantist)

iv) Secret Scanning — sometimes secrets are unintentionally left in the code which might lead to secret leaks and compromises. It is always advised to scan for secrets in your code in addition to SAST.

v) Penetration testing- It is always important to get a thorough pentest conducted to cover all grounds for the applications. Aside from the usual testcase that covers OWASP Top 10, SANS 25 or standards like PCI-DSS etc you might also want to design testcases on some specific areas like around the cloud environment, secret management, clusters, infrastructure etc

4. Maintenance:

You must ensure to continuously monitor the applications by enabling proper logging and integration with your SIEM tools. You must have incident management and proper Business Continuity Plans(BCP) in place in case when the application goes down. Change management, configuration management and security reviews must be conducted continuously. Set proper decommissioning policies in place for when the time comes to sunset a solution.

Additional and very important points to remember.

  1. Creating a policy document isn't sufficient to say the SDLC is secure. One must publish this officially and train the employees around it for whom its relevant like developers, application managers, owners or anyone who can influence security.
  2. Creating a security champion’s network is one of the best ways to empower the developers and help them minimize the security risks.
  3. It's very important to document and register risks at every stage of SDLC. These risks should be owned by management and should be delegated to be fixed by product owners/teams.
  4. If there is a vulnerability disclosure program (VDP) in your organization, make sure to include the critical solutions as part of the scope for the VDP.
  5. Perform Business Impact Analysis( BIA) for your solutions to understand what kind of assests does a product/application have and how much attention/support it needs.
  6. Always keep Business Continuity Plans ready for critical applications. When the solution goes down due to unforeseen situations, it's important that business continuity plans are triggered otherwise the business will face financial or reputation loss.
  7. Along with all the secure SDLC principles it is highly recommended that you spend some time around your CICD pipelines to identify gaps there and secure it.
  8. Spend some time understanding your cloud environment and policies set around that for identifying gaps. Use Cloud Security Posture Mangement tools if needed.
  9. While setting decommissioning policies in your Secure SDLC document make sure to cover all grounds like — access management, user account deletion process, data retention, backups, cloud components removal, DNS entries removal, removal of firewall rules etc.
  10. A secure coding checklist helps the developers develop a bug free application. It is advised to spend some time around that as well.

One must remember that every organization has different portfolios and product catalogues which shifts focus areas. Like for example, your organization might be completely outsourcing all the code development so in that case you might have to have a better focus around setting up policies for the contractors. Or some organization might want to focus more on their usage of allowed and restricted licenses, so the focus areas change accordingly. Some might say we are new to cloud setup and Kubernetes environment (hypothetically) and so they might want to spend more time on setting up policies around that to avoid any security gaps there. However, setting up a bare minimum requirement covering all grounds helps you enforce security from the very beginning of the lifecycle.

I might have missed some points which you may feel is essential to have in a secure SLDC document. What I have tried to do is cover grounds holistically and not detail out areas in lengths. I hope this blog helps and gives you a starting point for setting up a secure Software Development Lifecycle for your organization.

References

Securing the SDLC (owasp.org)

Microsoft Security Development Lifecycle Practices

Open Source Licenses to Avoid — Steps to Prevent the Legal Risk (brainhub.eu)

Open Source License Types — Detailed Guide l Scantist

What is the secure software development life cycle (SDLC)? | Synopsys

--

--